28. Abuse Prevention and Mitigation
We have engaged ARI Registry Services (ARI) to deliver services for this TLD. ARI provide registry services for a number of TLDs including the .au ccTLD. For more background information on ARI please see the attachment ‘Q28 – ARI Background & Roles.pdf’.
1 INTRODUCTION
The efforts that will be undertaken in this TLD to minimise abusive registrations and other activities that have a negative impact on Internet users are described below. This includes a discussion of the registry operator’s internal processes as well as aspects of the ARI Managed Registry Service as this relates to abuse prevention and mitigation.
We intend to request an exemption from clause 1b of the Registry Operator Code of Conduct (Specification 9) pursuant to clause 6 of the Code of Conduct to enable us to register domain names in our own right in this TLD. Registrations will not be made commercially available; all domain name registrations in the TLD will be registered to and maintained by us in our capacity as the registry operator, for our own exclusive use. We will not sell, distribute or transfer control or use of any registration in the TLD to any third party that is not our Affiliate.
For clarification and to reflect the unique roles of the stakeholders in our TLD, the following terms, where used in this response, have the following meaning:
“Registry operator” means the entity submitting an application to ICANN for the operation and management of a TLD. All references to “us”, “we” or “our” are to be taken as references to the registry operator.
“Affiliate” means, as defined in Clause 2.9(c) of the Registry Agreement, “a person or entity that, directly or indirectly, through one or more intermediaries, controls, is controlled by, or is under common control with, the person or entity specified, and (ii) ‘control’ (including the terms ‘controlled by’ and ‘under common control with’) means the possession, directly or indirectly, of the power to direct or cause the direction of the management or policies of a person or entity, whether through the ownership of securities, as trustee or executor, by serving as an employee or a member of a board of directors or equivalent governing body, by contract, by credit arrangement or otherwise.”
“Registrant” means the registered holder of a domain name, in this case the Registry Operator, consistent with the eligibility restrictions in our TLD as described in our response to Question 18.
Our comprehensive Acceptable Registration and Use Policy, developed in consultation with ARI, clearly defines abusive behaviour, identifies particular types of abusive behaviour and the mitigation response that ARI will initiate when abusive behaviour is determined. ARI will, owing to their extensive industry experience and established anti-abuse operations, implement and manage on our behalf various procedures and measures adopted through this policy. This robust policy and procedure framework, which will be continually improved, updated and rigidly enforced, will preclude abusive registrations from being made.
Despite utilisation of ARI’s anti-abuse service we are nonetheless cognisant of our responsibility to minimise abusive registrations and other activities that have a negative impact on Internet users in our TLD. In recognition of this responsibility, we will play an instrumental role in overseeing the implementation of the anti-abuse service by ARI. As well as having contractual commitments in the form of SLA’s in place to ensure that ARI’s delivery of the anti-abuse service is aligned with our strong commitment to minimise abuse in our TLD.
That strong commitment is further demonstrated by our adoption of many of the requirements proposed in the ‘2011 Proposed Security, Stability and Resiliency Requirements for Financial TLDs’ (at http:⁄⁄www.icann.org⁄en⁄news⁄correspondence⁄aba-bits-to-beckstrom-crocker-20dec11-en.pdf) (the ‘BITS Requirements). We acknowledge that these requirements were developed by the financial services sector in relation to financial TLDs, but nevertheless believe that their adoption in this TLD (which is not financial-related) results in a more robust approach to combating abuse.
Consistent with Requirement 6 of the BITS Requirements, we will certify to ICANN on an annual basis our compliance with our Registry Agreement.
Please note that the various policies and practices that we will implement to minimise abusive registrations and other activities that affect the rights of trademark holders, are specifically described in the response to Question 29.
2 ACCEPTABLE REGISTRATION AND USE POLICY
In consultation with ARI we have developed a comprehensive Acceptable Registration and Use Policy, which is the main instrument that captures our strategy in relation to identifying and handling abuse in our TLD. This is consistent with Requirements 3 and 4 of the BITS Requirements. Because all domain names will be registered to and maintained by us in our capacity as registry operator, the Acceptable Registration and Use Policy applies solely to us. However, the mitigation response described in the policy will be implemented by ARI. Any breach of the Acceptable Registration and Use Policy by an employee will be considered as a breach of the relevant employee’s employment conditions. Any breach by an Affiliate will be handled in accordance with the Acceptable Registration and Use Policy. The mitigation of any such breach, as described by the policy, will be implemented by ARI.
2.1 Definition of Abuse
Defining abusive behaviour by reference to the stage in the domain name lifecycle in which the behaviour occurs presents difficulty because a particular type of abuse may occur at various stages of the life cycle.
With this in mind, we have fully adopted the definition of abuse developed by the Registration Abuse Policies Working Group (Registration Abuse Policies Working Group Final Report 2010, at http:⁄⁄gnso.icann.org⁄issues⁄rap⁄rap-wg-final-report-29may10-en.pdf), which does not focus on any particular stage in the domain name life cycle.
Abusive behaviour in a TLD may be defined as an action that:
– Causes actual and substantial harm, or is a material predicate of such harm; or
– Is illegal or illegitimate, or is otherwise considered contrary to the intention and design of the mission⁄purpose of the TLD.
In applying this definition the following must be noted:
(1) The party or parties harmed, and the severity and immediacy of the abuse, should be identified in relation to the specific alleged abuse.
(2) The term ʺharmʺ is not intended to shield a party from fair market competition.
(3) A predicate is a related action or enabler. There must be a clear link between the predicate and the abuse, and justification enough to address the abuse by addressing the predicate (enabling action).
For example, WhoIs data can be used in ways that cause harm to domain name registrants, intellectual property (IP) rights holders and Internet users. Harmful actions may include the generation of spam, the abuse of personal data, IP infringement, loss of reputation or identity theft, loss of data, phishing and other cybercrime-related exploits, harassment, stalking, or other activity with negative personal or economic consequences. Examples of predicates to these harmful actions are automated email harvesting, domain name registration by proxy⁄privacy services to aid wrongful activity, support of false or misleading registrant data, and the use of WhoIs data to develop large email lists for commercial purposes. The misuse of WhoIs data is therefore considered abusive because it is contrary to the intention and design of the stated legitimate purpose of WhoIs data.
It should be noted that this definition of abuse serves to inform us and clarify certain behaviours, specific to domain names that may cause harm. However malicious conduct of any kind relating to the use of IT resources, which includes the TLD, is strictly against company policy and does not rely on the wording contained herein. Put simply, an abusive or malicious act is against our organisation’s documented standard of acceptable behaviour and will be dealt with technically within the registry and directly with any employee or Affiliate.
2.2 Aims and Overview of the Acceptable Registration and Use Policy
Our Acceptable Registration and Use Policy will put those registering and using domain names on notice of the ways in which abuse will be identified and responded to, and serve as a deterrent to those seeking to register and use domain names for abusive purposes.
Consistent with Requirements 15 and 16 of the BITS Requirements, our policy:
– Defines abusive behaviour in our TLD.
– Identifies types of actions that constitute abusive behaviour consistent with our adoption of the RAPWG definition of “abuse”.
– Classifies abusive behaviours based on the severity and immediacy of the harm caused.
– Identifies how abusive behaviour can be notified to ARI and the steps that ARI will take to determine whether the notified behaviour is abusive.
– Identifies the actions that may be taken in response to behaviour determined to be abusive.
The planned single registrant⁄single user model of this TLD will enable a close working relationship between registry operator and Registrar and full Registrar awareness of and compliance with our Acceptable Registration and Use Policy. This will be contractually enforceable through our RRA, which will oblige all Registrars to comply with the Acceptable Registration and Use Policy. Our RRA will additionally incorporate the following proposed BITS Requirements:
– Requirement 7: Registrars must certify annually to ICANN and us compliance with ICANN’s Registrar Accreditation Agreement (RAA) our Registry-Registrar Agreement (RRA).
– Requirement 9: Registrars must provide and maintain valid primary contact information (name, email address, and phone number) on their website.
– Requirement 14: Registrars must notify us immediately regarding any investigation or compliance action, including the nature of the investigation or compliance action by ICANN or any outside party (eg law enforcement, etc.) along with the TLD impacted.
We will re-validate our RRA at least annually, consistent with Requirement 10.
2.3 Acceptable Registration and Use Policy
Our Acceptable Registration and Use Policy is as follows:
Acceptable Registration and Use Policy
Introduction:
The abusive registration and use of domain names in the TLD is not tolerated given that the inherent nature of such abuses creates security and stability issues for all participants in the Internet environment.
Definition of Abusive Behaviour:
Abusive behaviour is an action that:
– Causes actual and substantial harm, or is a material predicate of such harm; or
– Is illegal or illegitimate, or is otherwise considered contrary to the intention and design of the mission⁄purpose of the TLD.
A ‘predicate’ is an action or enabler of a harm.
‘Material’ means that something is consequential or significant.
Examples of abusive behaviour falling within this definition:
– Spam: the use of electronic messaging systems to send unsolicited bulk messages. The term applies to email spam and similar abuses such as instant messaging spam, mobile messaging spam, and the spamming of web sites and Internet forums. An example, for purposes of illustration, would be the use of email in denial-of-service attacks.
– Phishing: the use of a fraudulently presented web site to deceive Internet users into divulging sensitive information such as usernames, passwords or financial data.
– Pharming: the redirecting of unknowing users to fraudulent websites or services, typically through DNS hijacking or poisoning, in order to deceive Internet users into divulging sensitive information such as usernames, passwords or financial data.
– Wilful distribution of malware: the dissemination of software designed to infiltrate or cause damage to devices or to collect confidential data from users without the owner’s informed consent.
– Fast Flux hosting: the use of DNS to frequently change the location on the Internet to which the domain name of an Internet host or nameserver resolves in order to disguise the location of web sites or other Internet services, or to avoid detection and mitigation efforts, or to host illegal activities. Fast flux hosting may only be used with prior permission of the registry operator.
– Botnet command and control: the development and use of a command, agent, motor, service or software which is implemented: (1) to remotely control the computer or computer system of an Internet user without their knowledge or consent, (2) to generate direct denial of service (DDOS) attacks.
– Distribution of pornography: the storage, publication, display and⁄or dissemination of pornographic materials.
– Illegal access to other computers or networks: the illegal accessing of computers, accounts, or networks belonging to another party, or attempt to penetrate security measures of another individual’s system (hacking). Also, any activity that might be used as a precursor to an attempted system penetration.
Detection of Abusive Behaviour:
Although we do not anticipate abusive behaviour in the TLD, it may be detected in the following ways:
– By the Marketing Manager through ongoing monitoring of all domain name transactions.
– By ARI through their on-going monitoring activities and industry participation.
– By third parties (general public, law enforcement, government agencies, industry partners) through notification submitted to the abuse point of contact on our website or industry alerts.
Reports of abusive behaviour will be notified immediately to the Registrar of record.
Handling of Abusive Behaviour:
When ARI detects or receives notification of abusive behaviour by the registry operator or a third party, a preliminary assessment will be performed to determine whether the notification is legitimately made. Applying the definitions of types of abusive behaviours identified in this policy, ARI will classify each incidence of legitimately reported abuse into one of two categories based on the probable severity and immediacy of harm to registrants and Internet users. These categories are provided below and are defined by reference to the action that may be taken by ARI. The examples of types of abusive behaviour falling within each category are illustrative only.
Category 1:
Probable Severity or Immediacy of Harm: Low
Examples of types of abusive behaviour: Spam, Malware
Mitigation steps:
1. Investigate
2. Notify registrant
Category 2:
Probable Severity or Immediacy of Harm: Medium to High
Examples of types of abusive behaviour: Fast Flux Hosting, Phishing, Illegal Access to other Computers or Networks, Pharming, Botnet command and control
Mitigation steps:
1. Suspend domain name
2. Investigate
3. Restore or terminate domain name
In the event that we receive specific instructions regarding a domain name from a law enforcement agency, government or quasi-governmental agency utilising the expedited process for such agencies, our mitigation steps will be in accordance with those instructions provided that they do not result in the contravention of applicable law. In addition, we will take all reasonable efforts to notify law enforcement agencies of abusive behaviour in our TLD which we believe may constitute evidence of a commission of a crime, eg, distribution of child pornography.
Note that these expected actions are intended to provide a guide to our response to abusive behaviour rather than any guarantee that a particular action will be taken.
The identification of abusive behaviour in the TLD, as defined above, shall give us the right, but not the obligation, to deny, cancel or transfer any registration or transaction, or place any domain name(s) on registry lock, hold or similar status or instruct Registrars to take such an action as we deem necessary, in our discretion to:
1. Protect the integrity and stability of the registry.
2. Comply with any applicable laws, government rules or requirements, requests of law enforcement, or dispute resolution process.
3. Avoid any liability, civil or criminal, on the part of the registry operator, as well as its Affiliates, subsidiaries, officers, directors, and employees.
4. Correct mistakes made by the registry operator or any Registrar in connection with a domain name registration.
We reserve the right to place upon Registry Lock, Hold or similar status a domain name during resolution of a dispute. We may amend or otherwise modify this policy to keep abreast of changes in consensus policy or new and emerging types of abusive behaviour in the Internet.
3 ABUSE PREVENTION AND MITIGATION BY THE REGISTRY OPERATOR
This section of the response describes abuse related processes implemented by the registry operator regarding:
– Building awareness of the Acceptable Registration and Use Policy
– Mitigating the potential for abusive behaviour
– Identifying abusive behaviour
Due to the complete control of all registrations made in the TLD that is provided by an exemption to clause 1b of the Registry Operator Code of Conduct, these processes are anticipated to will form the bulk of our efforts to minimise abusive registrations, as they function to control the behaviour of those in a position to engage in such behaviour.
3.1 Awareness of the Acceptable Registration and Use Policy
As mentioned above, the Acceptable Registration and Use Policy will govern the manner in which domain names may be used. Efforts will be undertaken to ensure that all those registering and using in this TLD within the registry operator’s organisation are made aware of the Acceptable Registration and Use Policy. Awareness will be generated by requiring relevant employees and Affiliates of the registry operator to attend compulsory information sessions which describe the Acceptable Registration and Use Policy and the ramifications of breaching the policy. Following the attendance of the information session, all attendees will be required to execute documentation which states that the employee or Affiliate has read, acknowledged and understood the policy. The Acceptable Registration and Use Policy will be published on the registry operator’s intranet as well as on the abuse page of our registry website, which will be accessible and have clear links from the home page.
It is anticipated that these efforts will place all employees and Affiliates on notice of the applicability of the Acceptable Registration and Use Policy to all domains in the TLD and furthermore emphasise and evidence our commitment to combating abusive registrations by clearly identifying what our policy on abuse is and what effect our implementation of the policy may have on those registering and using domain names. We anticipate that the clear message, which communicates our commitment to combating abusive registrations, will serve to minimise abusive registrations in our TLD.
3.2 Pre-emptive – Mitigating the Potential for Abuse
The following practices and procedures will be adopted by the registry operator to mitigate the potential for abusive behaviour in the TLD.
3.2.1 Mitigating the Potential for Abusive Registrations that Affect the Legal Rights of Others
Many of the examples of abusive behaviour identified in our Acceptable Registration and Use Policy may affect the rights of trademark holders. While our Acceptable Registration and Use Policy addresses abusive behaviour in a general sense, we have additionally developed specific policies and procedures to combat behaviours that affect the rights of trademark holders at start-up and on an ongoing basis. These include the implementation of a trademark claims service and a sunrise registration service at start-up and implementation of the UDRP, URS and PDDRP on an ongoing basis. Additionally, our registration policy will involve internal procedures to identify and address potential conflicts with others’ trademarks before such names are registered. The implementation of these policies and procedures serves to mitigate the potential for abuse in the TLD by ensuring that domain names are allocated to those who hold a corresponding trademark. These policies and procedures are described in detail in our response to Question 29.
3.2.2 Increasing Security Awareness
In accordance with our commitment to operating a secure and reliable TLD, we will attempt to improve awareness amongst those registering and using domain names of the threats of domain name hijacking, registrant impersonation and fraud, and emphasise the need to keep registration information accurate. Awareness will be raised by:
– Conducting biannual information sessions describing new and emerging threats and manners in which they may be mitigated.
– Publishing relevant information on our intranet in the form of videos, presentations and FAQ’s.
– Developing and providing to those registering and using domains in this TLD Best Common Practices that describe appropriate use and assignment of domain auth Info codes and risks of misuse when the uniqueness property of these codes are not preserved.
The increase in awareness renders us, as the only eligible registrant in the TLD, less susceptible to attacks on our domain names owing to the adoption of the recommended best practices that mitigate the potential for abuse in the TLD.
3.2.3 Registry Operator’s Internal Processes that Mitigate the Potential for Abuse
Eligibility, naming and use restrictions will be imposed in this TLD, consistent with proposed Requirements 1, 3 and 4 of the BITS Requirements, and enforced through internal processes that require approvals within established reporting lines and the use of username and password to verify eligibility to register domain names. As described in detail in our response to Question 18, we will be the only eligible registrant in this TLD.
This arrangement grants us a high degree of control and facilitates the implementation of measures to minimise abuse by significantly decreasing the number of individuals capable of registering and using a domain name and thus having the potential to engage in abusive behaviour. This is in contrast to the inherent decrease in control associated with granting multiple and varied individuals the capability to register and use domain names as demonstrated by many existing TLDs. Our planned single registrant⁄single user operating model precludes the abusive registration and use of domains in this TLD by unauthorised individuals not within our organisation, whilst also providing no incentive for those within our organisation to engage in abusive behaviour given that our brand is inherently intertwined with all uses of domains in this TLD.
Internal processes regarding the registration and use of domains in this TLD are aimed at maintaining the integrity of this arrangement by ensuring that the registration and use of domains in this TLD is restricted to authorised individuals whose use complies with the Acceptable Registration and Use Policy. These internal processes, which include safeguards against allowing for unqualified registration and use of domains in this TLD, are described below.
The primary safeguard against allowing for registrations in violation of eligibility restrictions is the technical incapability of those not authorised by the registry operator to register domain names in the TLD. We will only authorise the Marketing Manager to be the Administrative Contact and the Domain Administrator to be the Technical Contact for all domains in this TLD. The registry operator will provide and keep current the contact details of the Marketing Manager and the Domain Administrator to the Registrar, who will grant these individuals access to an authenticated web portal to register and manage domain names in the TLD. Individual credentials for accessing this portal will be provided to the Marketing Manager and the Domain Administrator by the Registrar via alternative sources. In the event that these credentials are compromised, direct communication with the account manager on the Registrar’s end is available. Various security measures will be implemented to ensure that only those personnel authorised to register and update domain names have access to the web portal. These measures are further described in our response to Question 30.
We will review the level of access that personnel have to the web portal, ensuring account permissions are relevant to the employee’s role as well as removing permissions of an employee promptly upon termination of employment. All domain name registrations will require the approval of the Marketing Manager who will ensure that the Domain Administrator is authorised to create the domain name. In addition, the Marketing Manager will perform a monthly audit of all domain name transactions to verify that all transactions and the use of domains complies with the Acceptable Registration and Use Policy.
This arrangement effectively mitigates the potential for abuse by restricting the capability to register domain names to a small number of trusted and authorised employees under our direct control and establishing various internal controls to that effect.
3.2.4 Promoting WhoIs Accuracy
Inaccurate WhoIs information significantly hampers the ability to enforce policies in relation to abuse in the TLD by allowing the registrant to remain anonymous. In addition, LEAs rely on the integrity and accuracy of WhoIs information in their investigative processes to identify and locate wrongdoers. Restricting the ability to register domain names in this TLD to the Marketing Manager and the Domain Administrator means that a domain’s contacts are well known and accessible by clear and reliable contact details. These employees will be continually made aware of their responsibility to provide and maintain accurate WhoIs information and the potential ramifications of a failure to do so, including termination of their employment. There can only be two parties responsible for abusive registrations, thus identifying them will require little effort from LEA and the ARI Abuse and Compliance Team. ARI will maintain correspondence with multiple points of contact within the registry operator’s organisation including but not limited to the Marketing Manager, Domain Administrator and Legal Counsel in order to ensure that all relevant stakeholders are keep abreast of important issues as they occur. Published WhoIs information will thus accurately reflect the identity and contact information of the individual who created the domain name in the name of the registry operator.
In addition, the Marketing Manager will perform a monthly audit of all domain names registered in the TLD to ensure that WhoIs information is complete and accurate.
3.2.5 Prompt Notification following Mitigation of Abuse
Our contractual arrangement with ARI dictates that in the unlikely event that a domain name is suspended or cancelled due to the implementation of the Acceptable Registration and Use Policy, ARI will promptly notify us. This notification will allow us to amend internal processes to prevent such behaviour from re-occurring. This notification mitigates the potential for abuse by ensuring that we are responsive to internal breaches of the Acceptable Registration and Use Policy whilst simultaneously putting employees on notice of the ramifications of breach.
3.3 Identification of Abusive Behaviour
Although we do not anticipate the identification of abusive behaviour owing to our internal processes to mitigate the potential for abuse, we will rely on the monthly audit of all domain name transactions conducted by the Marketing Manager as well as notification of abuse to the Marketing Manager by third parties through alternate communication channels to identify abusive behaviour in our TLD. In the event that an audit reveals an unauthorised domain name transaction or other behaviour indicative of abuse, the Marketing Manager will notify ARI, who will take the appropriate mitigation response described below.
4 ABUSE PREVENTION AND MITIGATION BY ARI
This section of the response includes ARI’s description of the abuse related processes they will implement regarding:
– Mitigating the potential for abusive behaviour
– Identifying abusive behaviour
– Handling abusive behaviour
These processes form part of ARI’s standard anti-abuse service and are designed with a multi-registrant model in mind. We have elected to utilise ARI’s anti-abuse service to comply with the requirements of Question 28 and do not anticipate relying strongly on these processes owing to our effective internal abuse prevention and mitigation processes described above. Note, however, that the Registry Lock service described below – beneficial in preventing the unintentional transfer, modification or deletion of the domain name – is best provided by ARI as an independent third party to maintain the separation of parties, which underpins the benefit of the service.
4.1 Pre-emptive – Mitigating the Potential for Abuse
The following practices and procedures will be adopted by ARI to mitigate the potential for abusive behaviour in our TLD.
4.1.1 Registry Lock
Certain mission-critical domain names such as transactional sites, email systems and site supporting applications may warrant a higher level of security. Whilst we will take efforts to promote the awareness of security amongst those authorised to register domain names, it is recognised that an added level of security may be provided by ‘registry locking’ the domain name and prohibiting updates thereby preventing unintentional transfer, modification or deletion of the domain name. This service mitigates the potential for abuse by prohibiting any unauthorised updates that may be associated with fraudulent behaviour. For example, an attacker may update nameservers of a mission critical domain name, thereby redirecting customers to an illegitimate website without actually transferring control of the domain name.
Upon receipt of a list of domain names to be placed on Registry Lock by an authorised representative of the registry operator, ARI will:
1. Verify the identity of the authorised representative.
2. Set or modify the status codes for the names submitted to serverUpdateProhibited, serverDeleteProhibited and⁄or serverTransferProhibited depending on the request.
3. Record the status of the domain name in the Shared Registration System (SRS).
4. Provide a monthly report to the registry operator indicating the names for which the Registry Lock service was provided in the previous month.
4.1.2 ICANN Prescribed Measures
In accordance with our obligations as a registry operator we will comply with all requirements in the ‘gTLD Applicant Guidebook’. In particular, we will comply with the following measures prescribed by ICANN which serve to mitigate the potential for abuse in the TLD:
– DNSSEC deployment, which reduces the opportunity for pharming and other man-in-the-middle attacks. We will encourage Registrars and Internet Service Providers to deploy DNSSEC capable resolvers in addition to encouraging DNS hosting providers to deploy DNSSEC in an easy to use manner in order to facilitate deployment by registrants. DNSSEC deployment is further discussed in the context of our response to Question 43.
– Prohibition on Wild Carding as required by section 2.2 of specification 6 of the Registry Agreement.
– Removal of Orphan Glue records (discussed below in section 4.1.3).
4.1.3 Orphan Glue Record Management
The ARI registry SRS database does not allow orphan records. Glue records are removed when the delegation point NS record is removed. Other domains that need the glue record for correct DNS operation may become unreachable or less reachable depending on their overall DNS service architecture. It is the registrant’s responsibility to ensure that their domain name does not rely on a glue record that has been removed and that it is delegated to a valid nameserver. The removal of glue records upon removal of the delegation point NS record mitigates the potential for use of orphan glue records in an abusive manner.
4.2 Reactive – Identification
The methods by which abusive behaviour in our TLD may be identified are described below. These include detection by ARI and notification from third parties. These methods serve to merely identify and not determine whether abuse actually exists. Upon identification of abuse the behaviour will be handled in accordance with section 4.3 – Abuse Handling.
Any abusive behaviour identified through one of the methods below will, in accordance with Requirement 13 of the BITS Requirements, be notified immediately to relevant Registrars.
4.2.1 Detection – Analysis of Data
ARI will routinely analyse registry data in order to identify abusive domain names by searching for behaviours typically indicative of abuse. The following are examples of the data variables that will serve as indicators of a suspicious domain name and may trigger further action by the ARI Abuse and Compliance Team:
– Unusual Domain Name Registration Practices: practices such as registering hundreds of domains at a time, registering domains which are unusually long or complex or include an obvious series of numbers tied to a random word (abuse40, abuse50, abuse60) may when considered as a whole be indicative of abuse.
– Domains or IP addresses identified as members of a Fast Flux Service Network (FFSN): ARI uses the formula developed by the University of Mannheim and tested by participants of the Fast Flux PDP WG to determine members of this list. IP addresses appearing within identified FFSN domains, as either NS or A records shall be added to this list.
– An Unusual Number of Changes to the NS record: the use of fast-flux techniques to disguise the location of web sites or other Internet services, to avoid detection and mitigation efforts, or to host illegal activities is considered abusive in the TLD. Fast flux techniques use DNS to frequently change the location on the Internet to which the domain name of an Internet host or nameserver resolves. As such an unusual number of changes to the NS record may be indicative of the use of fast-flux techniques given that there is little, if any, legitimate need to change the NS record for a domain name more than a few times a month.
4.2.2 Abuse Reported by Third Parties
Whilst we are confident in our abilities to detect abusive behaviour in the TLD owing to our robust ongoing monitoring activities we recognise the value of notification from third parties to identify abuse. To this end, we will incorporate notifications from the following third parties in our efforts to identify abusive behaviour:
– Industry partners through ARI’s participation in industry forums which facilitate the sharing of information.
– Law enforcement agencies (LEA) through a single abuse point of contact (our Abuse page on the registry website, as discussed in detail in ‘4.3 Abuse Handling’) and an expedited process for LEA.
– Members of the general public through a single abuse point of contact (our Abuse page on the registry website).
4.2.2.1 Industry Participation and Information Sharing
ARI is a member of the Registry Internet Safety Group (RISG), whose mission is to facilitate data exchange and promulgate best practices to address internet identity theft, especially phishing and malware distribution. In addition, ARI coordinates with the Anti-Phishing Working Group (APWG) and other DNS abuse organisations and is subscribed to the NXdomain mailing list. ARI’s strong participation in the industry facilitates collaboration with relevant organisations on abuse related issues and ensures that ARI is responsive to new and emerging domain name abuses.
The information shared as a result of this industry participation will be used to identify domain names registered or used for abusive purposes. Information shared may include a list of registrants known to partake in abusive behaviour in other TLDs. While presence on such lists will not constitute grounds for registrant disqualification, ARI will investigate domain names registered to those listed registrants and take action in accordance with our Acceptable Registration and Use Policy. In addition, information shared regarding practices indicative of abuse will facilitate detection of abuse by our own monitoring activities.
4.2.2.2 Single Abuse Point of Contact on Website
In accordance with section 4.1 of specification 6 of the Registry Agreement, we will establish a single abuse point of contact (“SAPOC”) responsible for addressing and providing a timely response to abuse complaints concerning all names registered in the TLD. Complaints may be received from members of the general public, other registries, Registrars, LEA, government and quasi-governmental agencies and recognized members of the anti-abuse community.
The SAPOC’s accurate contact details (email and mailing address as well as a primary contact for handling inquiries related to abuse in our TLD) will be provided to ICANN and published on the Abuse page of our registry website, which will also include:
– All policies in relation to the TLD including the Acceptable Registration and Use Policy.
– Registrant Best Practices.
As such, the SAPOC may receive complaints regarding a range of matters including but not limited to violations of the Acceptable Registration and Use Policy.
The SAPOC will be the primary method by which ARI and the registry operator will receive notification of abusive behaviour from third parties. It must be emphasised that the SAPOC will be the initial point of contact following which other processes will be triggered depending on the identity of the reporting organisation. Accordingly, separate processes for identifying abuse exist for reports by LEA⁄government and quasi-governmental agencies and members of the general public. These processes will be described in turn below.
4.2.2.2.1 Notification by Agencies of Abuse
We recognise that LEA, governmental and quasi-governmental agencies may be privy to information beyond the reach of others which may prove critical in the identification of abusive behaviour in our TLD. As such, we will provide an expedited process which serves as a direct channel of communication with the registry operator for LEA, government and quasi-governmental agencies to, amongst other things, report illegal conduct in connection with the use of the TLD.
The process will involve prioritisation and prompt investigation of reports identifying abuse from those organisations. The steps in the expedited process are summarised as follows:
1. We will publish contact details on the Abuse page of the registry website for the SAPOC to be utilised by only those taking part in the expedited process;
2. All calls to this number will be responded to by the registry operator’s Legal Counsel within 24 hours and handled according to the process outlined in 4.3.4 below;
3. Should ARI be notified by LEA of abuse, ARI will request that the notifying agency contact directly the registry operator’s Legal Counsel. ARI will promptly notify the registry operator’s Legal Counsel of its having been contacted by LEA regarding abuse.
4.2.2.2.2 Notification by General Public of Abuse
Abusive behaviour in the TLD may also be identified by members of the general public including but not limited to other registries, Registrars or security researchers. The steps in this notification process are summarised as follows:
1. We will publish contact details on the Abuse page of the registry website for the SAPOC (note that these contact details are not the same as those provided for the expedited process).
2. All calls to this number will be responded to by the ARI Service Desk on a 24⁄7 basis. All calls will result in the generation of a ticket in ARI’s case management system (CMS).
3. The details of the report identifying abuse will be documented in the CMS ticket using a standard information gathering template.
4. Tickets will be forwarded to ARI’s Abuse and Compliance Team to be dealt with in accordance with section 4.3 – Abuse Handling.
4.2.2.2.3 Notification by the Marketing Manager
It is anticipated that notification by the Marketing Manager of abuse or potential abuse will serve as the primary method by which ARI identifies abuse in the TLD given that such behaviour is likely to be detected by the Marketing Manager. In the event that the monthly audit of domain name transactions by the Marketing Manager reveals an unauthorised domain name transaction or other behaviour indicative of abuse, the Marketing Manager will notify ARI’s Service Desk. All such calls will result in the generation of a CMS ticket, which will be forwarded to ARI’s Abuse and Compliance team to be dealt with in accordance with section 4.3 – Abuse Handling, below.
4.3 Abuse Handling
Although we do not anticipate the occurrence of abusive behaviour in our TLD owing to the high degree of control inherent in restricting domain name registrations to authorised employees within our organisation, ARI has processes in place to handle abuse once identified. Upon being made aware of abuse in the TLD, whether by ongoing monitoring activities or notification from third parties, ARI’s Abuse and Compliance Team will perform the following functions.
4.3.1 Preliminary Assessment and Categorisation
Each report of purported abuse will undergo an initial preliminary assessment by ARI’s Abuse and Compliance Team to determine the legitimacy of the report. This step may involve simply visiting the offending website and is intended to weed out spurious reports. This will not at this stage involve the in-depth investigation needed to make a determination as to whether the reported behaviour is abusive.
Where the report is assessed as being legitimate, the type of activity reported will be classified as one of the types of abusive behaviour falling within the scope of the Acceptable Registration and Use Policy by the application of the definitions provided in that policy. In order to make this classification, ARI’s Abuse and Compliance Team must establish a clear link between the activity reported and the alleged type of abusive behaviour such that addressing the reported activity will address the abusive behaviour.
While we recognise that each incident of abuse represents a unique security threat and should be mitigated accordingly, we also recognise that prompt action justified by objective criteria are key to ensuring that mitigation efforts are effective. With this in mind, we have categorised the actions that ARI may take on our behalf in response to various types of abuse by reference to the severity and immediacy of harm. This categorisation will be applied to each validated report of abuse and actions will be taken in accordance with the table below. It must be emphasised that the actions to mitigate the identified type of abuse in the table are merely intended to provide a rough guideline and may vary upon further investigation.
Category 1:
Probable Severity or Immediacy of Harm: Low
Examples of types of abusive behaviour: Spam, Malware
Mitigation steps:
1. Investigate
2. Notify registrant
Category 2:
Probable Severity or Immediacy of Harm: Medium to High
Examples of types of abusive behaviour: Fast Flux Hosting, Phishing, Illegal Access to other Computers or Networks, Pharming, Botnet command and control
Mitigation steps:
1. Suspend domain name
2. Investigate
3. Restore or terminate domain name
The mitigation steps for each category will now be described.
4.3.2 Investigation – Category 1
Types of abusive behaviour that fall into this category include those that represent a low severity or immediacy of harm to registrants and Internet users. These generally include behaviours that result in the dissemination of unsolicited information or the publication of illegitimate information. While undesirable, these activities do not generally present such an immediate threat as to justify suspension of the domain name in question. We will contact the Marketing Manager, Domain Administrator and Legal Counsel of the registry operator’s organisation to instruct that the breach of the Acceptable Registration and Use Policy be rectified. If the investigation by ARI’s Abuse and Compliance Team reveals that the severity or immediacy of harm is greater than originally anticipated, the abusive behaviour will be escalated to Category 2 and mitigated in accordance with the applicable steps. These are described below. The assessment made and actions taken will be recorded against the relevant CMS ticket.
4.3.3 Suspension – Category 2
Types of abusive behaviour that fall into this category include those that represent a medium to high severity or immediacy of harm to registrants and Internet users. These generally include behaviours that result in intrusion into other computers’ networks and systems or financial gain by fraudulent means. Following notification of the existence of such behaviours, ARI’s Abuse and Compliance Team will suspend the domain name pending further investigation to determine whether the domain name should be restored or cancelled. Cancellation will result if upon further investigation the behaviour is determined to be one of the types of abuse defined in the Acceptable Registration and Use Policy. Restoration of the domain name will result where further investigation determines that abusive behaviour, as defined by the Acceptable Registration and Use Policy, does not exist. Due to the higher severity or immediacy of harm attributed to types of abusive behaviour in this category, ARI will, in accordance with their contractual commitment to us in the form of SLA’s, carry out the mitigation response within 24 hours by either restoring or cancelling the domain name. The assessment made and actions taken will be recorded against the relevant CMS ticket.
Phishing is considered to be a serious violation of the Acceptable Registration and Use Policy owing to its fraudulent exploitation of consumer vulnerabilities for the purposes of financial gain. Given the direct relationship between phishing uptime and extent of harm caused, we recognise the urgency required to execute processes that handle phish domain termination in a timely and cost effective manner. Accordingly, ARI’s Abuse and Compliance Team will prioritise all reports of phishing from brand owners, anti-phishing providers or otherwise and carry out the appropriate mitigation response within 12 hours in accordance with the SLA’s in place between us and ARI. In addition, since a majority of phish domains are subdomains we believe it is necessary to ensure that subdomains do not represent an unregulated domain space to which phishers are known to gravitate. Regulation of the subdomain space is achieved by holding the registrant of the parent domain liable for any actions that may occur in relation to subdomains. In reality, this means that where a subdomain determined to be used for phishing is identified, the parent domain may be suspended and possibly cancelled effectively neutralising every subdomain hosted on the parent.
4.3.4 Executing Agency Instructions
We understand the importance of our role as a registry operator in addressing consumer vulnerabilities and we are cognisant of our obligations to assist law enforcement, government and quasi– governmental agencies in the execution of their responsibilities. As such, we will make all reasonable efforts to ensure the integration of these agencies into our processes for the identification and handling of abuse by, amongst other things:
1. Providing expedited channels of communication (discussed above).
2. Notifying LEA of abusive behaviour believed to constitute evidence of a commission of a crime eg distribution of child pornography.
3. Sharing all available information upon request from LEA utilising the expedited process, including results of our investigation.
4. Providing bulk WhoIs information upon request from LEA utilising the expedited process.
5. Acting on instructions by the agency.
It is anticipated that these actions will assist agencies in the prevention, detection, investigation, prosecution or punishment of criminal offences or breaches of laws imposing penalties. The relevant agencies are not limited to those enforcing criminal matters, but may also include those enforcing civil matters in order to eliminate consumer vulnerabilities.
Upon notification of abusive behaviour by LEA, government or quasi-governmental agencies through the expedited process described in 4.2.2.2.1 above, one of the following may occur:
1. The reported behaviour will be notified to ARI and subjected to a preliminary assessment and categorisation by ARI, as described in 4.3.1 above. The reported behaviour will then be mitigated based on the results of the categorisation. A report describing the manner in which the notification from the notifying agency was handled will be provided to us by ARI within 24 hours, for provision to the notifying agency by us. This report will also be recorded against the relevant CMS ticket.
OR
2. Where specific instructions are received from the notifying agency in a format acceptable to the registry operator’s Legal Counsel, we will act in accordance with those instructions provided that they do not result in the contravention of applicable law. We will execute the instructions of the notifying agency within 12 hours. Following prompt execution of the request, a report will be provided to the agency in a timely manner.
Finally, whilst we do not anticipate the occurrence of a security situation owing to ARI’s robust systems and processes deployed to combat abuse, we are aware of the availability of the Expedited Registry Security Request Process to inform ICANN of a present or imminent security situation and to request a contractual waiver for actions we might take or have taken to mitigate or eliminate the security concern.
5 RESOURCING
The efforts to minimise abusive registrations and other activities that have a negative impact on Internet users in this TLD will be undertaken jointly by employees of the registry operator and ARI.
5.1 ARI
This function will be performed by ARI. Abuse services are supported by the following departments:
– Abuse and Compliance Team (6 staff)
– Development Team (11 staff)
– Service Desk (14 staff)
A detailed list of the departments, roles and responsibilities in ARI is provided as attachment ‘Q28 – ARI Background & Roles.pdf’. This attachment describes the functions of the above teams and the exact number and nature of staff within.
The number of resources required to design, build, operate and support the SRS does not vary significantly with, and is not linearly proportional to, the number or size of TLDs that ARI provides registry services to.
ARI provides registry backend services to 5 TLDs and has a wealth of experience in estimating the number of resources required to support a registry system.
Based on past experience ARI estimates that the existing staff is adequate to support a registry system that supports in excess of 50M domains. Since this TLD projects 6000 domains, 0,01% of these resources are allocated to this TLD. See attachment ‘Q28 – Registry Scale Estimates & Resource Allocation.xlsx’ for more information.
ARI protects against loss of critical staff by employing multiple people in each role. Staff members have a primary role plus a secondary role for protection against personnel absence. Additionally ARI can scale resources as required. Additional trained resources can be added to any of the above teams with a 2 month lead time.
ARI’s anti-abuse service serves to prevent and mitigate abusive behaviour in the TLD as well as activities that may infringe trademarks. These responsibilities will be undertaken by three teams. ARI’s Development Team will be responsible for developing the technical platforms and meeting technical requirements needed to implement the procedures and measures adopted to mitigate the potential for abuse, identify abuse and handle identified abuse. ARI’s Abuse and Compliance Team will be responsible for the ongoing implementation of measures to minimise abusive registrations and other activities that have a negative impact on Internet users. ARI’s Service Desk will be responsible for responding to reports of abuse received through the abuse point of contact on the registry’s website and logging these in a ticket in ARI’s case management system.
The responsibilities of these teams relevant to the initial implementation and ongoing maintenance for our measures to minimise abusive registrations and other activities that affect the rights of trademark holders are described in our response to Question 29 – Rights Protection Mechanisms.
All of the responsibilities undertaken by ARI’s Development Team, Abuse and Compliance Team, and Service Desk are inclusive in ARI’s Managed Registry Services fee, which is accounted for as an outsourcing cost and explained in our responses to Question 47. The resourcing needs of these teams have been determined by applying the conservative growth projections for our TLD (which are identified in our answer to Question 48) to the team’s responsibilities at start-up and on an ongoing basis.
5.1.1 ARI Development Team
All tools and systems needed to support the initial and ongoing implementation of measures adopted to mitigate the potential for abuse, identify abuse and handle identified abuse will be developed and maintained by ARI. ARI has a software development department dedicated to this purpose which will ensure that the tools are fit for purpose and adjusted as requirements change.
ARI’s Development Team participate actively in the industry; this facilitates collaboration with relevant organisations on abuse related issues and ensures that the ARI Development Team is responsive to new and emerging domain name abuses and the tools and systems required to be built to address these abuses. This team consists of:
– 1 Development Manager
– 2 Business Analysts
– 6 Developers
– 2 Quality Analysts
5.1.2 ARI Abuse and Compliance Team
ARI’s Abuse and Compliance Team will be staffed by four full-time equivalent Policy Compliance Officers. These roles will entail the following:
A principal responsibility of the Policy Compliance Officers will be handling notifications of abuse through the SAPOC. This will involve identifying and categorising suspected abuse according to our Acceptable Registration and Use Policy and carrying out the appropriate mitigation response for all categorised abuses. Policy Compliance Officers will also be responsible for analysing registry data in search of behaviours indicative of abuse and reviewing industry lists in search of data that may identify abuse in the TLD. Furthermore, Policy Compliance Officers will provide training to the Marketing Manager of the registry operator’s organisation regarding abuse prevention and mitigation in order to enable the Marketing Manager to competently manage the registration and use of domain names and conduct information sessions which highlight the application of the Acceptable Registration and Use Policy.
Policy Compliance Officers will act on the instructions of verified agencies or dispute resolution providers and participate in ICANN and industry groups involved in the promulgation of policies and best practices to address abusive behaviour. They will escalate complaints and issues to the registry operator’s Legal Counsel when necessary and communicate with all relevant stakeholders (Registrars, registrants, LEA, general public) as needed in fulfilling these responsibilities. This role will be provided on a 24⁄7 basis, supported outside of ordinary business hours by ARI’s Service Desk.
Policy Compliance Officers will be required to have the following skills⁄qualifications: customer service⁄fault handling experience, comprehensive knowledge of abusive behaviour in a TLD and related policies, Internet industry knowledge, relevant post-secondary qualification, excellent communication and professional skills, accurate data entry skills, high-level problem solving skills, and high-level computer skills.
5.1.3 ARI Service Desk
ARI’s Service Desk will be staffed by 14 full-time equivalent positions. Responsibilities of Service Desk relevant to ARI’s Anti-Abuse Service include the following: responding to notifications of abuse through the abuse point of contact and expedited process for LEA, logging notifications as a ticket in ARI’s case management system, notifying us of a report received through the expedited process for LEA, government and quasi-governmental agencies, and forwarding tickets to ARI’s Abuse and Compliance team for resolution in accordance with the Acceptable Registration & Use Policy.
For more information on the skills and responsibilities of these roles, please see the in-depth resource section in answer to Question 31.
5.2 Registry Operator
The following is a description of the resources that are allocated to performing the tasks required by the registry operator. These tasks will be absorbed by the individuals currently performing the following roles within the registry operator’s organisation.
5.2.1 Marketing Manager
In the context of operating this TLD the registry operator’s existing Marketing Manager will be responsible for managing the creation of all domains in this TLD. The Marketing Manager must pre-approve all requests to create and⁄or update domain names by the Domain Administrator. In addition, the Marketing Manager will perform a monthly audit of all domain name transactions to verify that they were authorised and that the use of the domain name complies with the Acceptable Registration and Use Policy. The Marketing Manager will review the level of access that personnel have to the web portal, ensuring account permissions are relevant to the employee’s role as well as removing permissions of an employee promptly upon termination of employment. Finally the Marketing Manager will conduct biannual information sessions to improve awareness of the threat of domain name hijacking and fraud as well as raising awareness of the Acceptable Registration and Use Policy.
5.2.2 Domain Administrator
The registry operator’s existing Domain Administrator will be responsible for managing the registry operator’s domain name portfolio, which will involve creating, updating and maintaining all domains in this TLD in the name of and for the exclusive use of the registry operator.
5.2.3 Legal Counsel
The registry operator’s existing Legal Counsel will be responsible for responding to all reports and requests by LEA and managing the expedited process for those agencies and handling all escalated complaints and potential disputes arising in connection with the implementation of ARI’s anti-abuse service and related policies. This will involve assessing escalated complaints and issues, resolving disputes and liaising with all relevant stakeholders (Registrars, registrants, LEA, general public) as needed in fulfilling these responsibilities.
Based on the projections and the experience of ARI, the resources described here are more than sufficient to accommodate the needs of this TLD.
29. Rights Protection Mechanisms
We have engaged ARI Registry Services (ARI) to deliver services for this TLD. ARI provide registry services for a number of TLDs including the .au ccTLD. For more background information on ARI please see the attachment ‘Q29 – ARI Background & Roles.pdf’.
1 INTRODUCTION
Rights protection is a core objective of this TLD, facilitated by its planned operating model and well-developed rights protection mechanism (RPM) implementation plans. We intend to request an exemption pursuant to clause 6 from clause 1b of the Registry Operator Code of Conduct to enable us to register domain names in our own right in this TLD. Registrations will not be made commercially available. The control inherent in this model will assist us in protecting the legal rights of others. Our commitment to rights protection is further demonstrated by our adoption of many of the requirements proposed in the ‘2011 Proposed Security, Stability and Resiliency Requirements for Financial TLDs’ (at http:⁄⁄www.icann.org⁄en⁄news⁄correspondence⁄aba-bits-to-beckstrom-crocker-20dec11-en.pdf) (the ‘BITS Requirements’). We acknowledge that these requirements were developed by the financial services sector in relation to financial TLDs, but nevertheless believe that their adoption in this TLD (which is not financial-related) results in a more robust approach to combating abuse. In particular, we will adopt the following Requirements:
8: we will provide and maintain valid primary contact information (name, email address, and phone number) on our registry website.
10: we will re-validate our Registry-Registrar Agreements (RRA) at least annually.
13: we will notify Registrars immediately regarding any RPM investigation or compliance action including the nature of the investigation or compliance action by ICANN or any outside party (eg law enforcement etc).
Eligibility, naming and use restrictions will be imposed in this TLD (per Requirements 1, 3 and 4 of the BITS Requirements), supported at the time of registration by registrant warranty and enforced through internal processes requiring approvals within established reporting lines and the use of username⁄password to verify eligibility to register. As described in our response to Question 18, we will be the only eligible registrant in the TLD. This offers complete control over and responsibility for all registrations; the central point of control will ensure that multiple applications for the same name are not made, thus addressing Requirement 2 of the BITS Requirements. This robust policy and procedure framework, which will be continually improved, updated and rigidly enforced, will preclude abusive registrations from being made.
The abusive behaviour primarily targeted by sunrise, the TM Claims service, URS, UDRP, and Trademark PDDRP is cybersquatting, which is the registration of domain names constituting trademarks by registrants lacking rights in such marks. We note that different RPMs define the scope of protectable trademarks slightly differently; we therefore clearly identify the scope of protectable trademarks as respects each RPM. Cybersquatting is one of the many forms of abuse we will seek to minimise in our TLD. Our approach to combating abusive behaviour other than cybersquatting is described in our response to Question 28. Some overlap between the responses to Questions 28 and 29 is inherent because the prevention of cybersquatting can also serve to minimise other abusive behaviours such as phishing and pharming. By implementing the RPMs discussed below we thus aim also to minimise abuse as identified in our response to Question 28.
We recognise that RPMs implemented in this TLD are targeted at abusive behaviour not by others but by ourselves. We will be the respondent in all RPM proceedings. We nevertheless consider that such proceedings are unlikely to be raised due to the controls exercised within our organisation over registration.
For clarification, for the purposes of this response, references to the Registry Operator are references to the applicant entity; references to ‘we’, ‘us’, and ‘our’ refer to the same. References to a domain name registrant are references to a registrant authorised by us meeting the eligibility restrictions identified in our response to Question 18. Validation of the identity of domain name applicants will be easily achieved by Registrars given the internal-only nature of the TLD and the resultant close relationship between registry operator and Registrar.
2 START-UP RPMs
Below we identify our start-up RPM timeline and describe the way in which we will implement:
– A sunrise registration service
– The TM Claims service
2.1 Start-up RPMs Timeline
The timeline for start-up RPMs in our TLD is as follows:
Day 1: Single sunrise round opens
Day 30: Sunrise round closes
Day 31: Sunrise allocation period
Day 32: General registration begins, TM Claims Service begins
Day 92: TM Claims Service ends
2.2 Sunrise Registration Service
Our sunrise will provide trademark holders satisfying the eligibility restrictions identified in our response to Question 18 with a 30-day priority period in which to register their marks as domain names. Due to the application of the eligibility restrictions we will be the only eligible registrant, but holders of trademarks registered in the Trademark Clearinghouse (TMCH) will have the benefit of notice of sunrise registrations constituting an ‘Identical Match’ to their marks.
The following stakeholders are involved in implementation of the sunrise registration service:
– TMCH Service Provider⁄s
– Registrars
– Registry Operator
The role played by these stakeholders is described below with reference to:
– A summary of our Sunrise Policy and Sunrise Dispute Resolution Policy (SDRP)
– Our Sunrise Implementation Plan
– Our SDRP Implementation Plan
– Our implementation of sunrise and SDRP through contractual relationships
2.2.1 Sunrise Policy Summary and SDRP Summary
Through our Sunrise Policy we will offer a single, 30-day sunrise round in which trademark holders satisfying (i), (iii) and (iv) of the Sunrise Eligibility Requirements (SERs) proposed in the Applicant Guidebook at Trademark Clearinghouse s6.2.3 and the eligibility restrictions identified in our response to Question 18 will be eligible to apply for a domain name. This will be the first opportunity for registration in our TLD. Our Sunrise Policy will specify that applications received by an ICANN-accredited Registrar within the 30-day Sunrise Period and satisfying the SERs will be accepted for participation in the sunrise. Our Sunrise Policy will mandate that the trademarks upon which sunrise applications are based must fall within the Applicant Guidebook at Trademark Clearinghouse s7.2 and be supported by an entry in the TMCH. Internal registration processes will ensure that multiple applications for the same name are not made. Domains registered during sunrise will have a term of 1 year from the date of registration.
We will adopt (as registry operator) and submit (registrant) to a Sunrise Dispute Resolution Policy (SDRP) to allow any party to raise a challenge on the four grounds identified in the Applicant Guidebook at Trademark Clearinghouse s6.2.4. The remedy offered will be cancellation or deletion of a successfully challenged domain. The SDRP will specify that claims may be raised against a domain applied for during sunrise and will require that complaints clearly identify the challenger, the challenged domain name, and the ground⁄s upon which the complaint is based, and explain why the challenger believes that the ground⁄s are satisfied. If a TMCH service provider is not able to receive challenges directly as part of its undertaking to ‘maintain the SERs, validate and authenticate marks, as applicable, and hear challenges’ (Applicant Guidebook at Trademark Clearinghouse s6.2.5), ARI will receive SDRP challenges on our behalf and communicate these to the SDRP provider.
2.2.2 Sunrise Implementation Plan
1. Prior to or during our 30-day sunrise period, trademark holders can apply for validation of trademarks by the TMCH and inclusion of validated marks in the TMCH database.
2. ARI will develop a website and make available on that website our Sunrise Policy and SDRP.
3. An authorised employee will submit to an ICANN-accredited Registrar an application to register a domain name corresponding to a TMCH entry with evidence of the corresponding TMCH entry. If additional information or evidence of identity is required for validation by the Registrar this will be provided with the application. Compliance with registration policies implemented through internal processes will ensure that multiple applications are not made for the same name.
4. Registrars will be required through our RRA to validate the identity of all applicants and communicate sunrise application information to ARI.
5. ARI will perform standard checks (including IDN validity checks where relevant, reserved and restricted words in accordance with the Registry Agreement, composition requirements, etc.) to ensure that the domain being applied for is technically valid; an error message will be returned to the Registrar if the domain fails any of these checks.
6. Through an interface with the TMCH, ARI will identify all sunrise applications constituting an ‘Identical Match’ (as defined in the Applicant Guidebook at Trademark Clearinghouse s6.1.5) with a TMCH entry and provide notice to the holders of those trademarks of the filing of a corresponding sunrise registration.
7. A one-day quiet period will commence at the conclusion of the sunrise period. ARI will enable the sponsoring Registrar to CREATE (using EPP or the SRS web interface).
2.2.3 SDRP Implementation Plan
1. If a TMCH service provider is not able to directly receive complaints under our SDRP, we will specify in our SDRP the email address to which SDRP filings must be sent. This address will be monitored by ARI’s Abuse and Compliance Team.
2. ARI will develop a process of manual or automatic interface with the TMCH to communicate our SERs and any SDRP challenges received by ARI. This interface will also enable the TMCH service provider to notify ARI of successful SDRP challenges.
3. On notification from a TMCH service provider of a successful SDRP challenge, ARI will cancel or delete the domain name the subject of the successful challenge.
2.3 TM Claims Service
Immediately following the one-day sunrise allocation period, a 60-day period will commence during which we will offer the TM Claims Service. This is a service whereby prospective domain registrants receive notice of existing trademark rights matching their applied-for domain and trademark owners receive notice of registrations matching their mark. In accordance with the Applicant Guidebook our TM Claims service will be supported exclusively by the TMCH and will recognise and honour all word marks falling within the Applicant Guidebook at Trademark Clearinghouse s7.1.
The following stakeholders are involved in implementation of the TM Claims Service:
– TMCH Service Provider⁄s
– Trademark owners
– Registrars
– Registry Operator
The role played by these stakeholders is described below by reference to:
– Our TM Claims Service Implementation Plan
– Our implementation of the TM Claims service through contractual relationships
2.3.1 Implementation
2.3.1.1 TM Claims Service Implementation Plan
1. Prior to or during the 60-day TM Claims period, trademark holders can apply for validation of their marks by the TMCH and inclusion in the TMCH database. This enables the provision of notice to applicants during this period of entries in the TMCH and notice to trademark holders of registrations matching TMCH entries (how and by whom this will be achieved is detailed in subsequent steps of this implementation plan).
2. An authorised employee will submit to an ICANN-accredited Registrar an application for a domain. If additional information or evidence of identity is required for validation by the Registrar, this will be provided with the application. Compliance with registration policies implemented through internal processes will ensure that multiple applications are not made for the same name.
3. Registrars will be required through our RRA to validate the identity of all applicants.
4. For all applications received during this 60-day period, Registrars will be required to interface with the TMCH to determine whether an applied-for domain constitutes an ‘Identical Match’ with a trademark in the TMCH. If an ‘Identical Match’ is identified, the Registrar will provide to the applicant a TM Claims Notice in the form prescribed by the Applicant Guidebook. Following receipt of this notice the applicant must communicate to the Registrar its decision either to proceed with or abandon the application. If the applied-for name does not constitute an ‘Identical Match’ with a mark in the TMCH, no TM Claims Notice will be generated.
5. ARI will utilise the manual or automatic interface established for implementation of the SDRP (described above in ‘SDRP IMPLEMENTATION PLAN’) to facilitate reporting to registries by the TMCH of attempts to register domain names that are an ‘Identical Match’ with a trademark (as defined in the Applicant Guidebook at Trademark Clearinghouse s7.1) in the TMCH database.
6. We will conduct a review to determine whether to proceed with the application. If a decision is made to proceed, the Registrar will be required through our RRA to communicate the application information to ARI.
7. ARI will perform standard checks to ensure that the applied-for domain is technically valid; an error message will be returned to the Registrar if the domain fails any of these checks. If the domain passes these checks, ARI will enable the sponsoring Registrar to CREATE (using EPP or the SRS web interface) the domain.
8. Registrars will be required through our RRA to interface with the TMCH to promptly notify relevant mark holders of the registration of a domain constituting an ‘Identical Match’ to their TMCH entry.
2.3.1.2 Implementation through Contractual Relationships
The TM Claims Service Implementation Plan above will additionally be executed by the inclusion of the following clauses in our RRA:
– Registrars must use the TMCH as required by ICANN and the TMCH service provider⁄s.
– Registrars must not in their provision of the TM Claims Service make use of any trademark information aggregation, notification or validation service other than the TMCH.
– In order to prevent a chilling effect on registration, Registrars must ensure that applicants are not prevented from registering domain names considered an ‘Identical Match’ with a mark in the TMCH.
– Registrars must provide clear notice in the specific form provided by the ‘gTLD Applicant Guidebook’ to the prospective registrant of relevant entries in the TMCH.
3 ONGOING RPMs
As the only eligible registrant in our TLD, the ongoing RPMs described below are targeted at abusive behaviour by us, but such abuse will be prevented by internal processes that control domain name registration. We take seriously our responsibilities as Registry Operator and as registrant and acknowledge that as the registrant, we are subject to the URS and UDRP, as well as the Trademark PDDRP (to which all registry operators, regardless of the operating model of the TLD, are bound). We will abide by decisions rendered through those RPMs.
We also highlight that the single registrant⁄single user (SRSU) TLD model we intend to adopt, enabled by being granted an exemption to clause 1b of the Registry Operator Code of Conduct, is a new TLD model; RPMs designed prior to the new gTLD program were not designed with this model in mind. Even the newly designed URS and Trademark PDDRP are from conceptual and implementation perspectives not entirely practicable for the SRSU TLD model. Where gaps exist in current policy we have noted and addressed these in our implementation plans.
3.1 URS
The URS is a new RPM the implementation of which is mandated in all new gTLDs. It is targeted at providing a rapid takedown solution to clear-cut cases of cybersquatting. It is intended to have a deterrent effect and reduce the number of disputes under the UDRP.
Due to the complete control of all registrations in our planned SRSU model, we do not anticipate any situation in which it could be argued in good faith both that we have ‘no legitimate right or interest to the domain name’ in question and ‘that the domain name was registered and is being used in bad faith’. The risk of URS complaints will be minimised through internal processes controlling domain name registration. However, these processes would not stop a claimant from making a URS claim (even one in bad faith) against us. If that occurs we will to the extent practicable respond in a timely fashion and take steps to avoid default. In summary, we will have in place robust registration policies and internal procedures to prevent infringement of trademark rights by our registrations and therefore do not anticipate that URS claims will arise in our TLD, but nevertheless have developed an implementation plan to ensure that this mechanism is in place and is compliant with our obligations as a Registry Operator.
The URS is intended to supplement and not replace the UDRP, and the Applicant Guidebook foreshadows (at URS ss8.6 and 13) the likelihood of URS claimants also commencing UDRP claims. For this reason, we have considered in our URS Implementation Plan the potential interaction between URS stakeholders and UDRP stakeholders.
The following stakeholders are involved in implementation of the URS:
– URS claimants (holders of valid and enforceable trade or service marks)
– Registrar
– Registry Operator
– URS provider⁄s
– URS Examiner
The role played by these stakeholders is described below by reference to:
– Our URS Implementation Plan
– Our implementation of the URS through contractual relationships
3.1.1 Implementation
In our URS Implementation Plan below we identify certain aspects of implementation that are required under the Applicant Guidebook but nevertheless are not possible or practical to implement in the context of this TLD given its SRSU model. As the only eligible registrant, we acknowledge that we are prohibited from making changes to the WhoIs information of a registration if we have failed to respond to a URS complaint (default) in accordance with the Applicant Guidebook at URS s6.1. We also acknowledge we are prohibited from making changes to a domain name in locked status.
Understanding that a fundamental aim of the URS is expediency, all of the steps in the implementation plan will be undertaken as soon as practical but without compromising security or accuracy.
3.1.1.1 URS Implementation Plan
1. As an initial step, ARI will notify to each URS provider an email address for all URS-related correspondence. On an ongoing basis, ARI’s Abuse and Compliance Team will monitor this address for communications from URS providers including the Notice of Complaint, Notice of Default, URS Determination, Notice of Appeal and Appeal Panel Findings.
2. ARI will validate correspondence from a URS provider to ensure that it originates from the URS Provider.
3. ARI will within 24 hours of receipt of a URS Notice of Complaint lock the domain name⁄s the subject of that complaint by restricting all changes to the registration data, including transfer and deletion of the domain. The domain will continue to resolve while in this locked status.
4. ARI will immediately notify the URS provider in the manner requested by the provider once the domain⁄s have been locked.
5. On receipt of a favourable URS Determination ARI will lock the domain the subject of Determination for the balance of the registration period and redirect the nameservers to an informational web page provided by the URS provider. While a domain is locked, ARI will continue to display all of the WhoIs information of the original registrant except for the redirection of the nameservers and the additional statement that the domain will not be able to be transferred, deleted or modified for the life of the registration.
6. On receipt of notification from the URS provider of termination of a URS proceeding ARI will promptly unlock the domain and return full control to the registrant.
7. Where a default has occurred (because we have not submitted a response to a URS complaint in accordance with the Applicant Guidebook at URS s6.1) and a Determination has been made in favour of the complainant, in the event that ARI receives notice from a URS provider that a Response has been filed in accordance with the Applicant Guidebook at URS s6.4, ARI will as soon as practical restore a domain to resolve to the original IP address while preserving its locked status until a Determination from de novo review is notified to ARI.
8. ARI will ensure that no changes are made to the resolution of a registration the subject of a successful URS Determination until expiry of the registration or the additional registration year unless otherwise instructed by a UDRP provider.
We note that the Applicant Guidebook requires that registry operators make available to successful URS complainants an optional extension of the registration period for one additional year at commercial rates. This is rendered impractical in the context of our TLD by the fact that we are the only eligible registrant; any such extension will be undertaken by ourselves at wholesale cost.
3.1.1.2 Implementation of the URS through Contractual Relationships
We will require through our RRA that Registrars not take any action relating to a URS proceeding except as in accordance with a validated communication from ARI or a URS provider.
3.2 UDRP
The UDRP is applicable to domain name registrations in all new gTLDs. It is available to parties with rights in valid and enforceable trade or service marks and is actionable on proof of all three grounds identified in the policy as on ICANN’s website: http:⁄⁄archive.icann.org⁄en⁄udrp⁄udrp-policy-24oct99.htm
As the only eligible registrant in the TLD, we will be the respondent in all UDRP complaints in relation to the TLD. Because we will have control of all registrations we do not anticipate many, if any, situations in which it could be argued in good faith both that we have ‘no rights or legitimate interest in respect of the domain name’ in question and that the name ‘has been registered and is being used in bad faith’. The risk of UDRP complaints will be minimised through internal processes controlling registration. However, these processes would not stop a claimant from making a claim (even one in bad faith) against us. If a complaint is raised, we will to the extent practicable respond in a timely fashion and take steps to avoid default. In summary, while we expect that UDRP claims will not arise in our TLD, we have developed an implementation plan to ensure that this mechanism is in place and is compliant with our obligations as registry operator.
The remedies offered by the UDRP are cancellation or transfer of a registration to a successful UDRP claimant. We note, however, that transfer is rendered impossible in the context of this TLD; where an exemption to clause 1b of the Registry Operator Code of Conduct has been granted enabling the registry operator to register domain names in its own right, transfer of domains is prohibited. For this reason, it appears that the only applicable remedy to a UDRP claim raised against us is cancellation of the disputed domain. We will place cancelled names on a list to prevent their subsequent registration.
The following stakeholders are involved in implementation of the UDRP:
– UDRP claimants
– Registrar
– Registry Operator
– UDRP providers
The role played by these stakeholders is described below by reference to:
– Our UDRP Implementation Plan
– Our implementation of the UDRP through contractual relationships
Our UDRP Implementation Plan considers the potential overlap between URS implementation and UDRP implementation because we consider it likely that URS complainants will commence UDRP claims as a second recourse or simultaneously. We note that neither policy prohibits complainants from commencing proceedings simultaneously.
3.2.1 Implementation
Our UDRP Implementation Plan is set out below followed by a description of the implementation that will take place through contractual relationships.
3.2.1.1 UDRP Implementation Plan
From a policy compliance perspective as the registrant of domain names in our TLD, we acknowledge that we are subject to the UDRP.
From a technical perspective, our UDRP Implementation Plan focuses on interaction with Registrars because there is currently no interaction between existing gTLD registry operators and UDRP providers. On this basis we consider that ARI has one principal responsibility in facilitating Registrars’ implementation of the UDRP: ARI’s Development Team (described in ‘4 RESOURCES’ below) will maintain awareness of UDRP requirements and be capable of taking action when required and sufficiently skilled and flexible to respond to any changes to UDRP policy.
UDRP implementation would also ordinarily require that ARI provide EPP and the SRS web interface to enable Registrars to perform required UDRP functions in accordance with the Policy on Transfer of Registrations between Registrars. Transfers between Registrars are not likely to arise in our TLD and transfer is not a viable remedy for UDRP violation in the context of our TLD as explained above.
3.2.1.2 Implementation of the UDRP through Contractual Relationships
The UDRP is applicable to domain name registrations in all new gTLDs by force of a contractual obligation (Registry Agreement Art. 2.9) on registry operators to use only ICANN-accredited Registrars, who in turn are contractually required (RAA, 21 May 2009, at 3.8) to incorporate the UDRP in their Registration Agreements. Consistent with Requirement 7 of the BITS Requirements, we will require through our RRA that Registrars certify annually to ICANN their compliance with ICANN’s RAA.
3.3 Preventing Trademark Infringement in Operating the Registry
The new Trademark PDDRP, which targets infringement arising from the registry operator’s manner of operation or use of its TLD, is primarily directed at the situation in which the registry operator and registrant are not the same or affiliated entities. In that situation, trademark holders have no clear recourse against the registry operator. Because the Registry Operator in our TLD is also the registrant, trademark owners do in fact have recourse against us under the URS, UDRP. However, the grounds of those RPMs differ from grounds for claims under the Trademark PDDRP. Grounds for raising a Trademark PDDRP claim are as follows:
(i) There is a substantial pattern or practice of specific bad faith intent by the registry operator to profit from the sale of trademark infringing domain names; and
(ii) The registry operator’s bad faith intent to profit from the systematic registration of domain names within the gTLD that are identical or confusingly similar to the complainant’s mark, which:
(a) Takes unfair advantage of the distinctive character or reputation of the complainant’s mark; or
(b) impairs the distinctive character or reputation of the complainant’s mark; or
(c) creates a likelihood of confusion with the complainant’s mark.
While we will as required under the Registry Agreement agree to participate in all Trademark PDDRP procedures and be bound by resulting determinations, we consider the risk of claims being raised against us eliminated because it will not be possible for claimants to satisfy the two grounds cited above. Specifically, it cannot be shown that there exists a ‘substantial pattern or practice... to profit from the sale of trademark infringing domain names’ because domain names will not be sold in our TLD.
We will implement the Trademark PDDRP in accordance with our implementation plan below, but will have in place procedures to identify and address potential conflicts with others’ trademarks before domains are registered, and do not otherwise foresee that any Trademark PDDRP claims raised against us could succeed.
The following stakeholders are involved in our implementation of measures to prevent trademark infringement in our running of the TLD:
– Trademark holders
– Registry Operator
– Trademark PDDRP provider⁄s
The role played by these stakeholders is described below by reference to:
– Our Trademark PDDRP Implementation Plan
– Our implementation of our Trademark PDDRP through contractual relationships
3.3.1 Implementation
Our Trademark PDDRP Implementation Plan is set out below followed by a description of the implementation that will take place through contractual relationships.
3.3.1.1 Trademark PDDRP Implementation Plan
1. ARI will notify to the Trademark PDDRP provider⁄s contact details for communications regarding the Trademark PDDRP.
2. As described in our response to Question 28, ARI will publish our Acceptable Registration and Use Policy on a website specifically dedicated to abuse handling in our TLD. Consistent with Requirement 8 of the BITS Requirements, this website will include contact details to enable trademark holders to raise concerns regarding infringement of their trademarks by us and resultant harm caused by our operation or use of our TLD.
3. All calls will be responded to by ARI’s Service Desk on a 24⁄7 basis and will result in the generation of a ticket in ARI’s case management system (CMS). The details of the complaint (which will at a minimum include the information below) will be documented using a standard information gathering template, which will be recorded against the CMS ticket:
– Complainant name
– Contact details
– Trademark name
– Jurisdiction
– Registration date
– Registration number
– Nature of entitlement to trademark
– Explanation of why complainant believes that its mark has been infringed and harm caused by our operation or use of the TLD
4. Tickets will be forwarded to ARI’s Abuse and Compliance Team. A Policy Compliance Officer will conduct a preliminary assessment to ensure that a complaint is not spurious. If it is determined that a complaint is not spurious, the Policy Compliance Officer will use the contact details provided in the complaint to acknowledge receipt of the complaint and commence investigation and good faith negotiation with the complainant in accordance with the Applicant Guidebook at Trademark PDDRP s7.2.3(d). Any actions taken will be recorded against the CMS ticket.
5. On an ongoing basis, ARI’s Abuse and Compliance Team will monitor the email address notified to the Trademark PDDRP provider⁄s for all communications from the Trademark PDDRP provider including the threshold determination, Trademark PDDRP complaint, complainant’s reply, notice of default, expert panel determinations, notice of appeal and determinations of an appeal panel.
6. In the event that a complaint cannot be resolved and a Trademark PDDRP claim is made, ARI’s Abuse and Compliance Team will on our instruction do the following:
– File a response in accordance with the Applicant Guidebook at Trademark PDDRP s10 (thus avoiding, whenever possible, default);
– Where appropriate, make and communicate to the Trademark PDDRP provider decisions regarding the Trademark PDDRP proceeding, including whether to request a three-person Trademark PDDRP Expert Panel (Trademark PDDRP s13.2), request discovery (s15.1), request a hearing (s16), request a de novo appeal (s20.1), challenge an ICANN-imposed Trademark PDDRP remedy (s21.3), initiate dispute resolution under the Registry Agreement (s21.4), or commence litigation in the event of a dispute arising under the Trademark PDDRP (s22); and
– Where appropriate, undertake discovery in compliance the Applicant Guidebook at Trademark PDDRP s15, attend hearings raised under s16, and gather evidence in compliance with ss20.5 and 20.6.
7. ARI will on notification of an Expert Panel finding in favour of the Claimant (Trademark PDDRP s14.3), reimburse the Claimant.
8. ARI will implement any remedial measures recommended by the expert panel pursuant to Trademark PDDRP s18.3.1 and take all steps necessary to cure violations found by the expert panel (Trademark PDDRP s18.3.2) and notified by ICANN (Trademark PDDRP s21.3).
3.3.1.2 Implementation of Trademark PDDRP through Contractual Relationships
All new gTLD registry operators are bound to comply with the Trademark PDDRP by Specification 7, cl 2 of the Registry Agreement. In accordance with Requirement 6 of the BITS Requirements, we will certify annually to ICANN our compliance with the Registry Agreement.
4 RESOURCES
ARI’s abuse services are supported by the following departments:
– Abuse and Compliance Team (6 staff)
– Development Team (11 staff)
– Service Desk (14 staff)
A detailed list of the departments, roles and responsibilities in ARI is provided as attachment ‘Q29 – ARI Background & Roles.pdf’. This attachment describes the functions of the above teams and the exact number and nature of staff within.
The number of resources required to design, build, operate and support the SRS does not vary significantly with, and is not linearly proportional to, the number or size of TLDs that ARI provides registry services to.
ARI provides registry backend services to 5 TLDs and has a wealth of experience in estimating the number of resources required to support a registry system. Based on past experience ARI estimates that the existing staff is adequate to support a registry system that supports in excess of 50M domains. Since this TLD projects 6000 domains, 0,01% of these resources are allocated to this TLD. See attachment ‘Q29 – Registry Scale Estimates & Resource Allocation.xlsx’ for more information.
ARI protects against loss of critical staff by employing multiple people in each role. Staff members have a primary role plus a secondary role for protection against personnel absence. Additionally ARI can scale resources as required.
The measures described in the context of the responses to Questions 28 and 29 – which serve to prevent and mitigate abusive behaviour in the TLD as well as activities that may infringe trademarks – will be implemented and managed by ARI on our behalf. These responsibilities will be undertaken by three teams. ARI’s Development Team will be responsible for developing the technical platforms and meeting technical requirements needed to implement the RPMs discussed above. ARI’s Abuse and Compliance Team will be responsible for the ongoing operations of our measures to minimise abusive registrations and other activities that affect trademark rights recognised through RPMs. ARI’s Service Desk will be responsible for responding to reports of trademark infringement received through the abuse point of contact on the registry website and logging these in a ticket in ARI’s case management system.
The responsibilities of these teams relevant to the initial implementation and ongoing maintenance for our measures to minimise the potential in our TLD for abuse not specifically affecting trademark rights are described in our response to Question 28.
All of the responsibilities undertaken by ARI’s Development Team, Abuse and Compliance Team and Service Desk are inclusive in ARI’s Managed Registry services fee, which is accounted for as an outsourcing cost in our response to Question 47. The resourcing needs of these teams have been determined by applying the conservative growth projections for our TLD (identified in our response to Question 48) to the teams’ responsibilities at start-up and on an ongoing basis.
4.1 ARI Development Team
All tools and systems used for the transmission and receipt of information related to RPMs will be developed and maintained by ARI. ARI has a Development Team dedicated to this purpose which will ensure that the tools are fit for purpose and adjusted as requirements change.
ARI will ensure that systems and tools will be compliant with the appropriate processes for dealing with Registrars, the TMCH, URS and Trademark PDDRP providers as these processes are defined. ARI has been and will remain active in the formulating of these processes. ARI will use its resources to remain current with the approved measures for exchange of any material relevant to RPMs, whether during sunrise or on an ongoing basis. This team consists of:
– 1 Development Manager
– 2 Business Analysts
– 6 Developers
– 2 Quality Analysts
4.2 ARI Abuse and Compliance Team
ARI’s Abuse and Policy Compliance Team will be staffed by five full-time equivalent positions:
– 4 Policy Compliance Officers
– 1 Legal Manager
Policy Compliance Officers will be responsible for managing sunrise applications, supporting the SDRP, TM Claims Service, URS, UDRP and Trademark PDDRP, managing communications with the TMCH, receiving, assessing and managing trademark infringement complaints received through the single abuse point of contact, escalating complaints and issues to the Legal Manager when necessary, and communicating with all relevant stakeholders (Registrars, registrants, trademark holders, general public) as needed in fulfilling these responsibilities. This role will be provided on a 24⁄7 basis supported by the ARI Service Desk. Policy Compliance Officers will be required to have the following skills⁄qualifications: customer service⁄fault handling experience, complete knowledge of all RPMs offered by the TLD and related policies, Internet industry knowledge, relevant post-secondary qualification, excellent communication and professional skills, accurate data entry skills, high-level problem solving skills, and high-level computer skills.
The Legal Manager will be responsible for handling all potential disputes arising in connection with RPMs and related policies. This will involve assessing complaints and issues, liaising with legal counsel and management, resolving disputes and communicating with all relevant stakeholders (Registrars, registrants, trademark holders, general public) as needed in fulfilling these responsibilities. The Legal Manager will be required to have the following skills⁄qualifications: legal background (in particular, intellectual property⁄information technology law) or experience with relevant tertiary or post-graduate qualifications, dispute resolution experience, Internet industry experience, excellent communication, negotiation, problem solving and professional skills and good computer skills.
4.3 ARI Service Desk
ARI’s Service Desk will be staffed by 14 full-time equivalent positions. Responsibilities of the Service Desk relevant to RPMs include the following: responding to notifications of trademark infringement through the single abuse point of contact, logging notifications as a ticket in ARI’s case management system, and forwarding tickets to ARI’s Abuse and Compliance team for resolution in accordance with relevant RPM implementation plans.
For more information on the skills and responsibilities of these roles, please see the in-depth resources section in response to Question 31.
Based on the projections and the experience of ARI, the resources described here are more than sufficient to accommodate the needs of this TLD.
The use of these resources and the services they enable is included in the fees paid to ARI, which are described in response to Question 47.
30(a). Security Policy: Summary of the security policy for the proposed registry
We have engaged ARI Registry Services (ARI) to deliver services for this TLD. ARI provide registry services for a number of TLDs including the .au ccTLD. For more background information on ARI please see the attachment ‘Q30a – ARI Background & Roles.pdf’. This response describes Security as implemented by ARI under direction from the registry operator, taking into account any specific needs for this TLD
1 SECURITY POLICY SUMMARY
ARI operates an ISO27001 compliant Information Security Management System (ISMS) for Domain Name Registry Operations; see attachment ‘Q30a – SAI Global Certificate of Compliance.pdf’. The ISMS is an organisation-wide system encompassing all levels of Information Security policy, procedure, standards, and records. Full details of all the policies and procedures included in the ISMS are included in the attachment to Question 30b.
1.1 The ISMS
ARI’s ISMS’s governing policy:
– Defines the scope of operations to be managed (Domain Name Registry Operations).
– Designates the responsible parties (COO, CTO and Information Security Officer) for governance, Production Support Group for implementation and maintenance, and other departments for supporting services.
– Requires a complete Risk Assessment (a developed Security Threat Profile for the Service – in this case registry services for the TLD – and a Risk Analysis tracing threats and vulnerabilities through to Risks) and Risk Treatment Plan (each major risk in the Risk Assessment references the Statement of Applicability indicating controls to be implemented, responsible parties, and the effectiveness metrics for each).
– Includes a series of major sub policies governing security, which include but are not limited to:
– ICT acceptable use policy and physical security policies.
– PSG Security Policy which outlines the registry operations policies, the management of end-user devices, classification of networks and servers according to the classification of information they contain, networking, server & database configuration and maintenance guidelines, vulnerability and patch management, data integrity controls, access management, penetration testing, third party management, logging and monitoring, and cryptography.
– Requires ongoing review:
– Of risks, threats, the Risk Treatment Plan, client requirements and commitments, process and policy compliance, process and policy effectiveness, user etc.
– Regular internal and external penetration testing & vulnerability scanning.
– Ad-hoc review raised during normal operations, common sources being change management processes, scheduled maintenance or project debriefs, and security incidents.
– Yearly review cycle which includes both internal and external audits, including external surveillance audits for compliance.
– Additional yearly security controls assessment reviews, which include analysis of the security control implementations themselves (rather than compliance with any particular standard).
– At 24 month intervals, external penetration testing of selected production services.
– periodic ISO reaccreditation
ARI’s ISMS encompasses the following ARI standards:
– Configuration standards for operating systems, networking devices and databases based on several key publications, including those released by NIST (eg SP800-123, SP800-44v2, SP-800-40, SP800-41) and the NSA, staff testing and experience, and vendor supplied standards.
– Security Incident Classification, which identifies the various classifications of security incidents and events to ensure that events that qualify as security incidents.
– Information Classification and Handling which specifies the information classification scheme and the specific requirements of handling, labelling, management and destruction for each level of classification.
1.2 SECURITY PROCESSES
Processes are used to implement the policies. These include, but are not limited to:
1.2.1 Change Management
This includes change management and its sub-processes for access management, software deployment, release of small changes and scheduled maintenance. This process includes:
– The classification of changes and the flow into sub processes by classification.
– The release and deployment process for change control into production environments, outlining peer review, testing steps, approval points, checklist sets, staging requirements and communication requirements.
– The software release and deployment process with its specific testing and staged rollout requirements.
– The scheduled maintenance process and its various review points.
1.2.2 Incident Management
This includes incident management process and its sub-process for unplanned outages. These outline:
– How incidents are managed through escalation points, recording requirements, communication requirements etc.
– The unplanned outage procedure which applies directly to situations where the registry itself or other critical services are unexpectedly offline.
1.2.3 Problem Management
The goal of problem management is to drive long term resolution of underlying causes of incidents. This process centres on finding and resolving the root causes of incidents. It defines escalation points to third parties or other ARI departments such as Development, as well as verification of the solution prior to problem closure.
1.2.4 Security Incident Management
This process deals with the specific handling of security incidents. It outlines the requirements and decision points for managing security incidents. Decision points, escalation points to senior management and authorities are defined, along with evidence-gathering requirements, classification of incidents and incident logging.
1.2.5 Access Management
This process handles all access changes to systems. HR must authorize new users, and access changes are authorized by departmental managers and approved by the Information Security Officer.
When staff leave or significantly change roles, a separation process is followed which ensures all access that may have been granted during their employment (not just their initially granted access) is checked and where appropriate, revoked.
Finally, quarterly review of all access is undertaken by the ISO, reviewing and approving or rejecting (with an action ticket) as appropriate.
2 ARI’s SECURITY INFRASTRUCTURE SOLUTIONS
ARI has developed a layered approach to IT security infrastructure. At a high level, some of the layers are as follows:
– DDoS countermeasures are employed outside ARI networks. These include routing traps for DDoS attacks, upstream provider intervention, private peering links and third party filtering services.
– Routing controls at the edge of the network at a minimum ensures that only traffic with valid routing passes into ARI networks.
– Overprovisioning and burstable network capabilities help protect against DoS and DDoS attacks.
– Network firewalls filter any traffic not pre-defined by network engineering staff as valid.
– Application layer firewalls then analyse application level traffic and filter any suspicious traffic. Examples of these would be an attempt at SQL injection, script injection, cross-site scripting, or session hijacking.
– Server firewalls on front-end servers again filter out any traffic that is not strictly defined by systems administrators during configuration as valid traffic.
– Only applications strictly necessary for services are running on the servers.
– These applications are kept up-to-date with the latest security patches, as are all of the security infrastructure components that protect them or that they run on.
– ARI infrastructure is penetration-tested by external tools and contracted security professionals for vulnerabilities to known exploits.
– ARI applications are designed, coded and tested to security standards such as OWASP and penetration-tested for vulnerabilities to common classes of exploits by external tools and contracted security professionals.
– ARI configures SELinux on its production servers. Specific details of this configuration is confidential; essentially any compromised application is extremely limited in what it can do.
– Monitoring is used to detect security incidents at all layers of the security model. Specifically:
– Network Intrusion Detection systems are employed to monitor ARI networks for suspicious traffic.
– ARI maintains its own host-based Intrusion Detection system based on tripwire, which has now undergone four years of development. Specific details are confidential, but in summary, the system can detect any unusual activity with respect to configuration, program files, program processes, users, or network traffic.
– More generic monitoring systems are used as indicators of security incidents. Any behaviour outside the norm across over 1,100 individual application, database, systems, network and environmental checks is investigated.
– Capacity management components of the monitoring suite are also used to detect and classify security incidents. Some examples are:
– Network traffic counts, packet counts and specific application query counts.
– Long term trend data on network traffic vs. specific incident windows.
– CPU, Storage, Memory and Process monitors on servers.
– A second layer of hardware firewalling separates application and middle tier servers from database servers.
– Applications only have as much access to database information as is required to perform their function.
– Finally, database servers have their own security standards, including server-based firewalls, vulnerability management for operating system and RDBMS software, and encryption of critical data.
2.1 Physical Security Infrastructure
ARI maintains a series of physical security infrastructure measures including but not limited to biometric and physical key access control to secured areas and security camera recording, alarm systems and monitoring.
3 COMMITMENTS TO REGISTRANTS
We commit to the following:
– Safeguarding the confidentiality, integrity and availability of registrant’s data.
– Compliance with the relevant regulation and legislation with respect to privacy.
– Working with law enforcement where appropriate in response to illegal activity or at the request of law enforcement agencies.
– Maintaining a best practice information security management system that continues to be ISO27001-compliant.
– Validating requests from external parties requesting data or changes to the registry to ensure the identity of these parties and that their request is appropriate. This includes requests from ICANN.
– That access to DNS and contact administrative facilities requires multi-factor authentication by the Registrar on behalf of the registrant.– That Registry data cannot be manipulated in any fashion other than those permitted to authenticated Registrars using the EPP or the SRS web interface. Authenticated Registrars can only access Registry data of domain names sponsored by them.
– A Domain transfer can only be done by utilizing the AUTH CODE provided to the Domain Registrant.
– Those emergency procedures are in place and tested to respond to extraordinary events affecting the integrity, confidentiality or availability of data within the registry.
4 AUGMENTED LEVEL OF SECURITY
This TLD is a SRSU TLD (.brand style) and as such requires security considerations that are commensurate with its purpose. Our goal with this TLD is to use the TLD internally and adequate protect it against unauthorized registrations or modifications to the namespace, without making the internal process too onerous and thus increasing costs. Whilst, due to the SRSU nature, it is relatively straightforward to restrict and enforce restrictions on registrations, the impact of an unauthorised registration can be high, potentially damaging.
The following attributes describe the security with respect to the TLD:
– ARI, follows the highest security standards with respect to its Registry Operations. ARI is ISO 27001 certified and has been in the business of providing a Registry backend for 10 years. ARI have confirmed their adherence to all of the security standards as described in this application. As per recommendation 24 this ensures that the technical implementations do not compromise elevated security standards
– A single Registrar will be nominated for this TLD, facilitating the tightest possible control over Registrant validity enforcement and domain registration restrictions.
– Registrant will only be permitted to make changes to their domain name after a authenticating to their Registrar.
– Registrants will only be able to access all interfaces for domain registration and management via HTTPS. A reputed digital certificate vendor will provide the SSL certificate of the secure site.
– Registrar identity will be manually verified before they are accredited within this TLD. This will include verification of corporate identity, identity of individuals involved ⁄ mentioned, and verification of contact information
– Registrars will only be permitted to connect with the SRS via EPP after a multi-factor authentication that validates their digital identity. This is described further ahead.
– Registrars will only be permitted to use a certificate signed by ARI to connect with the Registry systems. Self-signed certificates will not be permitted.
– The Registry is DNSSEC enabled and the TLD zone will be DNSSEC enabled. This is described in detail in our response to question 43. The following additional requirements will exist for Registrars who want to get accredited to sell this TLD:
– Registrars must support DNSSEC capabilities within its control panels.
– If the Registrar provides Managed DNS services to Registrants within this TLD they must provide DNSSEC for the same. This ensures that DNSSEC is deployed at each zone and subsequent sub-zones at Registry, Registrar and Registrant level as per recommendation 26.
– Registrar access to all Registry Systems will be via TLS and secured with multi-factor authentication as per recommendation 27. This is described in detail in our responses to Question 24 and Question 25.
– Registrant access to all Registrar and Registry Systems will be via TLS and secured with multi-factor authentication as per recommendation 28. This is described in detail in our response to Question 25, Question 27 and Question 29.
– All communication between the Registrar or the Registrars systems and the registry system is encrypted using at least 128 bit encryption which been designated as ‘Acceptable’ till ‘2031 and beyond’ by NIST Special Publication 800-57. This includes the following communication:
– Secure websites and control panels provided by the Registrar to the Registrant.
– Ticketing systems provided by the Registrar to the Registrant.
– Web and EPP interfaces provided by ARI to the Registrars.
– Ticketing systems provided by ARI to the Registrar.
– Any communication between the Registrant, Registrar and Registry that is deemed as critical or contains credentials or sensitive information.
Where these requirements put controls on Registrars these will be enforced through the RRA.
5 RESOURCES
This function will be performed by ARI. The following resources are allocated to performing the tasks required to deliver the services described:
– Executive Management Team (4 staff)
– Production Support Group (27 staff)
ARI has ten years’ experience designing, developing, deploying, securing and operating critical Registry systems, as well as TLD consulting and technology leadership.
As a technology company, ARI’s senior management are technology and methodology leaders in their respective fields who ensure the organisation maintains a focus on technical excellence and hiring, training and staff management.
Executive Management is heavily involved in ensuring security standards are met and that continued review and improvement is constantly undertaken. This includes the:
– Chief Operations Officer
– Chief Technology Officer
A detailed list of the departments, roles and responsibilities in ARI is provided as attachment ‘Q30a – ARI Background & Roles.pdf’. This attachment describes the functions of the above teams and the exact number and nature of staff within.
The number of resources required to design, build, operate and support the SRS does not vary significantly with, and is not linearly proportional to, the number or size of TLDs that ARI provides registry services to.
ARI provides registry backend services to 5 TLDs and has a wealth of experience in estimating the number of resources required to support a registry system.
Based on past experience ARI estimates that the existing staff is adequate to support a registry system that supports in excess of 50M domains. Since this TLD projects 6000 domains, 0,01% of these resources are allocated to this TLD. See attachment ‘Q30a – Registry Scale Estimates & Resource Allocation.xlsx’ for more information.
ARI protects against loss of critical staff by employing multiple people in each role. Staff members have a primary role plus a secondary role for protection against personnel absence. Additionally ARI can scale resources as required. Additional trained resources can be added to any of the above teams with a 2 month lead time.
The Production Support Group is responsible for the deployment and operation of TLD registries.
The group consists of:
– Production Support Manager (also the ISO)
– Service Desk:
– 1 Level 1 Support Team Lead
– 8 Customer Support Representatives (Level 1 support)
– 1 Level 2 Support Team Lead
– 4 Registry Specialists (Level 2 support)
– Operations (Level 3 support):
– 1 Operations Team Lead
– 2 Systems Administrators
– 2 Database Administrators
– 2 Network Engineers
– Implementation:
– 1 Project Manager
– 2 Systems Administrators
– 1 Database Administrators
– 1 Network Engineers
ARI employs a rigorous hiring process and screening (Police background checks for technical staff and Australian Federal Government ‘Protected’ level security clearances for registry operations staff).
© Internet Corporation For Assigned Names and Numbers.