The third section of the
Registry Operator's Proposal is a description of the
registry operator's
Technical Capabilities and Plan. This section must
include a
comprehensive, professional-quality technical plan that
provides a
detailed description of the registry operator's current technical
capabilities
as well as a full description of the operator's proposed
technical
solution for establishing and operating all aspects of the registry.
The
technical plan will require detailed, specific information regarding
the
technical capabilities of the proposed registry. The topics listed
below
are representative of the type of subjects that will be covered in the
Technical
Capabilities and Plan section of the Registry Operator's
Proposal.
[INSTRUCTION: ICANN will extensively review and analyze this section of
the
Registry Operator's Proposal. The content, clarity, and
professionalism of
this section will be important factors in ICANN's
evaluation of
applications. We strongly recommend that those who are
planning to apply
secure professional assistance from engineers and/or other
technical
consultants to aid in the formulation of the technical plan and
the
preparation of the Technical Capabilities and Plan section of the
Registry
Operator's Proposal.]
As all of the technical operations of the new
Registry will be carried out by 7Ways.com, the
remainder of this section
III of this document as far as section D15.2.14 was prepared by
7Ways and
relates to their personnel, and proposed methods of running the new TLD
Registry. This plan forms part of our submission and
we fully support and intend to have them
implement the systems described
herein if our application is approved.
The Technical Capabilities
and Plan section should consist of at least the
following:
This should provide a
detailed description of the registry operator's technical
capabilities,
including information about key technical personnel
(qualifications and
experience), size of technical workforce, and access to
systems
development tools. It should also describe the registry operator's
significant
past achievements. This description offers the registry
operator an
opportunity to demonstrate the extent of its technical expertise in
activities
relevant to the operation of the proposed registry
.
The technical workforce is first composed by a
CEO, a CTO, 3 engineers, plus 2 technicians
(7WAYS Team).
Francois Collignon 7WAYSInc CEO fc@7ways.net
·
Electronic engineering background.
·
Director of domain name registration
“7ways”-accredited registrar by ICANN and
CORE
·
Director LODGER, Inc internet services (USA)
·
CEO 7ways, Inc. internet services (USA)
·
CORE Executive Committee Member
·
Founding member of CORE (Council of
Registrars-Geneva)
·
Executive member and Financial chairman of CORE
·
Vice president of the Internet European
Business Association (Madrid)
·
Active participation in setting up the internet
governance, DNSO and ICANN
·
Steering Committee member for dot EU
·
Coordinator of added value services Working
group for dot EU
·
Active member of the international AFNIC group
that supports the DNSO and
ICANN
initiatives
Edouard galera 7WAYS CTO eg@7ways.net
13 years of experience in software, hardware and
security development.
Has developed the Access control system for the
European Parliament as consultant for
Polaroid Europe. Has developed the
Access control system of the US Air Force Base of
Barksdale (Louisiana) as
consultant for Polaroid US. Has worked for SAGEM group and has
done
different missions for Apple (SAGEM-Apple partnerships) VideoConferencing
product
MeetMe and SAGEM ISDN Geoport Adapter. Work on missions to improve
Internet/Intranet
security for foreign organizations (cannot be cited). Work with the French
justice for Internet investigation. Pioneer of Internet electronic payment in
France. He is
co-founder of 7WAYS.
Jean-Pierre Stierlin 7WAYS Software
Engineer jps@7ways.net
Telecommunication-Network expert. 13 years of
experience, has worked for SAGEM group
and has done different missions for
Apple (SAGEM-Apple partnerships)
VideoConference MeetMe product, has
developed H320-QuickTime conferencing interface
with Apple technical team,
and has developed for SAGEM, SagemPPP, Sagem Internet
router for
MacIntosh, Mac SSH (freeware client, http://www.macssh.com).
Has developed
7WAYS experimental registry platform with E.Galera and
B.Nizet.
Daniel Chiaramello 7WAYS Software
Engineer dc@7ways.net
Telecommunication/Network expert. 10 years
experience. Has developed for SAGEM X25
drivers on MacIntosh, ISDN
(Q921/Q931) drivers and on the Sagem Internet router for
MacIntosh. Works
for 7WAYS on the TLDNames registrar platform back-office.
Bernard Nizet 7WAYS Software Engineer bn@7ways.net
Database Expert. 12 years experience. has worked for SEMA group, has developed
TLDNames, the registrar application for 7WAYS.
The technical workforce
The technical workforce will be composed by 6
persons to be hired for technical support
24h/24, 7days/7 plus two
technical person for backup. They will be managed by the key
technical personnel.
7WAYS
experience in registration.
7WAYS,
was created in June 1998, the company is located at Sophia Antipolis (France)
and
is specialized in Internet engineering and security. 7WAYS is a
registrar accredited by
ICANN and is a member of CORE (Council of
Registrars). It has passed the
NSIRegistry
technical certification for itself and for a foreign customer. It has developed
a
complete registry platform compatible with CORE SRS specifications.
7WAYS is leader
in the Added values services working group for the
European Commission’s project dot-EU.
7WAYS TLDNames registrar platform : http://www.tldnames.com
Registry development concept is based on readily available systems
development tool under
Linux, which are in open source.
This should present a
comprehensive technical plan for the proposed registry
operations. In
addition to providing basic information concerning the
operator's proposed
technical solution (with appropriate diagrams), this
section offers the
registry operator an opportunity to demonstrate that it
has carefully
analyzed the technical requirements of registry operation.
Factors that
should be addressed in the technical plan include:
Address all locations of systems.
Provide diagrams of all of the systems
operating at each location. Address
the specific types of systems being used,
their capacity, and their
interoperability, general availability, and level
of security. Describe in
detail buildings, hardware, software systems,
environmental equipment,
Internet connectivity, etc.
Description of the architecture’s components.
Functional registry architecture.
The central registry server.
The central registry server
hosts the registry’s database and perform transactions with
registrars.
This server is redundant multi-processor computer with a RAID disk array.
The mirror registry server.
The mirror registry server
is a duplication (hardware & software) of the central registry
(database
updated in real-time). It will operate in case of failure or maintenance of the
central
registry server. Switching between central registry and mirror can
be automatically
initiated by the security scanner in case of failure
detection or security problem.
The Firewall & VPN Gateway.
The Firewall & VPN
(Virtual Private Network) Gateway element is composed by:
·
A traffic filtering firewalls:
it selectively route packets between internal and external
networks
according to the registry’s security policy. Traffic filtering decisions
are
made on the source address, destination address, protocol, source port,
destination
port, or are based on the interface the packet arrives or goes out on.
·
An application level firewall or
proxy: it mediates traffic among clients and the
registry. Proxy server
take network requests and screen them according to registry’s
security
policy. Only valid requests will be relayed by the proxy server to the
registry
server.
·
A VPN gateway: is a gateway supporting security technologies such as IPSec that
provide authentification and encryption mecanisms. It will be used to provide
secured communications with
elements of the registry located in remote areas.
Name servers
We will initially have two TLD Name servers at
different locations. Initially one in France and
one in the U.S. As we
expand operations we plan to increase the number of TLD Name
servers to 5
at different locations. The registry will have full remote access to all TLD
servers thru secure communications (VPN).
The Whois servers.
One or several
Whois servers are uses. Whois database synchronization with central registry
will be operated in real-time. Information will be transferred within a VPN
tunnel.
The local backup server.
Registry Data
will be transmitted on the backup server each day. They will be compressed,
encrypted and stored on removable magnetic devices. Any failure in the
transmission of
the backup file will generate an alarm to the maintenance
task force.
The remote data escrow
server.
Data Escrow
service providers will receive incremental backups each day. Data will be
encrypted
by using PGP, and transmitted thru a VPN. So, two security level will be used.
Any
failure in the transmission of the backup file to the remote Data
escrow server will
generate an alarm to the maintenance task force.
The security scanner.
The security
scanner function is to detect the network security holes in the registry
platform,
Whois servers and name servers due to hacking or system
misconfiguration according to
registry’s security policy. An alarm is issued to the registry task force in
case of security
problem detection.
The central registry, mirror
registry, and name servers hardware.
Redundant, hot-swappable multiprocessor system
(2 to 4 processors). The system is
safeguarded by two uninterruptable
power supplies (UPS). RAID mass storage is used for
fault-tolerancy and
disk mirroring.
Operating system.
For maintenance purpose, the same operation
system is used for all elements of the registry.
Our choice is a security
enhanced version of Linux for stability, efficiency, and security.
All
installed software components are in open source.
Please describe in detail.
The registry model is based on the principle that competing
registars share the registry
resources
on an equal footing. This is done by delivering to registrars the same
connectivity
package which help them to implement the registry access.
A
Council of Registrars (CORE) member, 7WAYS propose to use the CORE SRS protocol
to
perform exchanges between the registrars and the registry platform.
See:
“CORE Shared Registry System Protocol (SRSP)Version 1.1” document attached.
Database size, throughput, scalability,
procedures for object creation,
editing, and deletion, change
notifications, registrar transfer procedures,
grace period implementation,
reporting capabilities, etc.
The
database schema described here covers the tables used to store permanent data.
The
current domain, name host, holder and contact information, as well as
the
respective historic information. Additional tables not described here
are used for
processing and verification purposes.
Domain table
Used to hold information on the registered domain. Key Fields are:
·
Domain name (SLD + TLD)
·
Registrar ID.
·
Registrant (pointer to Registrant table).
·
Administrative contact (pointer to Contact table).
·
Technical contact ID (pointer to Contact table).
·
Zone contact ID (pointer to Contact table).
·
Domain Creation date
·
Domain Expiration date
·
Domain last modification date.
·
Status of the domain (active, hold…)
·
Names servers ID’s
for the domain.
·
Area of business.
·
Market location.
·
Values added services (pointer to values added
services table, see below)
Registrant table
The registrant table has an identical
structure with the contact table (see below). But as
the registrant
modification process is more restrictive than Admin,Tech and Zone
contacts,
a separate table is used. There is one registrant record for each domain
registered.
A registrant will be identified by a unique ID.
Contacts
table
The contact table holds
information for contact people associated to domains. A
contact record can
be used for many domains. The key fields are:
·
Contact ID (unique
identifier for the contact)
·
First Name
·
Last Name
·
Role/Individual (the
contact acts for himself or for an organization)
·
Address
·
City
·
State
·
Postal Code
·
Country
·
Telephone number
·
Fax number
·
Mobile phone number
(for SMS/WAP notifications).
·
Email
·
Title
·
Organization
·
Registrar ID (which
registrar has registered the contact)
·
Contact Creation date
·
Contact last modification date.
Name hosts table
Several name servers can be
used for a domain. The Name hosts table holds the host
name and the IP address
associated. A unique ID identify the name host and is
used to link with
the domain table. Key fields for host table are:
·
Host ID (unique
identifier for the host)
·
Hostname
·
Host IP address
·
Host contact ID (person
responsible for the host)
·
Registrar ID (which
registrar has registered the host)
·
host Creation date
·
host last modification date.
Value added services table.
The value added services table
holds additional information for domains, the structure
is not defined yet
but may store informations as encryption certificates, content
description
of the domain, keywords related to the domain (for search engines
use)…
In general, this table let the
possibility to the registry to hold more informations for
domains, it adds
flexibility for later evolutions.
Registrar Table
The registrar table is
maintained and owned by the registry. Some parts of the data are
exposed
to the registrars, and a registrar is able to modify some aspects of his
own
data. The data which is exposed is:
·
Registrar ID (unique ID
identifying the registrar).
·
Registrar Name
·
The account balance.
·
The status (active,
suspended…)
·
The main Contact.
·
The Administrative
contact.
·
The PGP public key used
for access to the Registry using SRS.
Log Tables.
The database is designed to support large
volume, and fast response to queries. Our
experimental registry platform
has been tested with 1,000,000 records. Queuing
mechanism have been implemented in case of database overload. Architecture
update
can be performed to increase the system performance.
See: “CORE Shared Registry System Protocol (SRSP)
Version 1.1” document attached.
See:
“CORE Shared Registry System Protocol (SRSP)Version 1.1” document attached.
A grace period will be used for charged
transactions (domain creation, renewal,
transfer). The period is estimated
to 4 days. Any cancellation of the above transaction
will refund the
registrar account.
Any
change concerning domain information will be notified to the related contact
(registrant, administrative, billing or technical contact) depending of the
nature of the
update.
Reporting
Capabilities.
Registrars
will have an access to the registry thru a secure and authenticated HTTP
connection. All information stored
on the registry concerning their activity will be
accessible (Domains
created, contacts…).
Procedures for changes,
editing by registrars, updates. Address frequency, security,
process,
interface, user authentication, logging, data back-up.
Locations of nameservers, procedures for and means of distributing zone files to them.
Zone file generation will be processed continuously as
an independent process connected to the
registry database, the procedure
will be:
Once a domain is created or updated (name servers
updates), the Zone file generation process
will check its validity using
nslookup queries, in case of failure, the result will be logged,
and
alarms will be periodically issued. The successfully tested zone file then will
be
distributed immediately to the TLD name servers thru VPNs. The goal is
to reach as far as
possible the real time availability of the domain on
the network.
Zone
file distribution
The zone file incremental distribution mechanisms will follow the
related RFC’s.
Vixie, P., "DNS NOTIFY: A Mechanism for Prompt Notification of Zone
Changes", RFC 1996,
August 1996.
Ohta, M.,
"Incremental Zone Transfer", RFC
1995, August 1996
Registry
Operator can access servers distributed over the Internet (TLD name and Whois
servers) using authenticated and encrypted communications for maintenance
purposes. All
servers are configured to require no physical intervention.
TLD
name servers automatically maintain old zone files for at least 7 days.
Technical characteristics, system security, accessibility.
Frequency and procedures for
backup of data. Describe hardware and
systems used, data format, identity of
escrow agents, procedures
for retrieval of data/rebuild of database, etc.
The
private PGP key needed to access the registry backup information may be
transmitted
(not thru the network) to ICANN for verification purposes.
Address software and
hardware, connection speed, search capabilities,
coordination with other
Whois systems, etc.
WHOIS information database will be updated
less than one minute after a domain registration.
The WHOIS aims are :
.
·
Return domains information in several formats (text,
formatted text (standard), HTML, XML)
·
Return domain information in several languages
·
Return extended information (area of business, Market
location).
Access to a WHOIS server is done by sending
information to the TCP 43 port (compatible with
the existing model), or by
HTTP access (public information) or by SSL-HTTP access for
extended
information (registrar access), . The WHOIS server requests will be enriched so
that specific information concerning
domains (language choice, returned information
format choice,
nature of information selected…) may be accessed. A WAP access to the WHOIS
database is also provided.
In case of load of the WHOIS service, a load
balancing system between multiple Whois servers
will be implemented
according to the RFC 1794 (DNS Support for Load Balancing),
coordination
will be done by incremental updates thru VPNs.
Search Capabilities
Search in the WHOIS database
will be performed on the following criteria:
·
Domain name
·
Contact name
or Contact ID (unique ID identifying the contact).
·
Host name or
IP Address or Host ID (unique ID identifying the contact).
·
Area of
business.
·
Market
Location.
Technical and physical
capabilities and procedures to prevent system hacks,
break-ins, data
tampering, and other disruptions to operations. Physical
security.
7WAYS
work with internal and external security specialists, they are able to ensure
the system
follow the registry’s security policy. 7WAYS has a technology
survey team to check
newly discovered security issues in operating systems.
The experts will regularly review the
registry architecture.
Servers areas must include the following controls:
·
The area owner must be
clearly identified.
·
The area must be locked,
even when attended.
·
Access to the area must be
restricted to only those authorized by the area owner.
·
Access to the area must only
be allowed from the provider internal space,
and emergency exit doors must be
alarmed. Exterior windows are not permitted in ground floor installations.
·
The area must include
intrusion detection. Access to the area
must be controlled by electronically controlled access.
·
Registry’s Servers will be
installed in a closed rack.
A traffic and Application Firewall will protect the
registry’s servers (see D15.2.1).
A network scanner will automatically check the
possible security holes, and will issue an alarm
to Authorized persons if
any is detected (see D15.2.1).
System procedures will check
periodically the registry database integrity. Alarm will be issued
in case
of integrity loss.
Any
communication between registry’s servers will be authenticated and encrypted
using
IPSec VPN’s.
Technical capability for
handling a larger-than-projected demand for
registration or load. Effects
on load on servers, databases, back-up systems,
support systems, escrow
systems, maintenance, personnel.
The
system has been designed with reliability, flexibility, and security
considerations. Each
element of the registry platform can be duplicated
for availability of the service covered
(registry, DNS, Whois), but also
to accept a higher demand of resources.
Larger
demand for registration has no effect on backup servers and escrow systems
except the
transmission time and the volume of information stored which
capacity update can be
easily solved.
Define, analyze, and quantify quality of service.
The target availability parameters are set in
consideration of relative cost and volume and
nature of service provided.
Whenever possible, multiple redundant resources are used.
Network quality of service
We will use Affinity’s high quality network.
As
the mirror server is a perfect duplication of the central registry server
(hardware, software,
data). Switching will be automatically initiated in
case of complete crash of one of those
systems, or manually for
maintenance purposes.
As there will be multiple TLD name servers, which
servers are high-availability machines, zero
downtime can be expected for
Domain Naming System.
Procedures for problem
detection, redundancy of all systems, back up power
supply, facility
security, technical security, availability of back up
software, operating
system, and hardware, system monitoring, technical
maintenance staff,
server locations.
See D15.2.1 section.
Procedures for restoring the
system to operation in the event of a system
outage, both expected and
unexpected. Identify redundant/diverse systems for
providing service in
the event of an outage and describe the process for
recovery from various
types of failures, the training of technical staff
who will perform these
tasks, the availability and backup of software and
operating systems
needed to restore the system to operation, the
availability of the
hardware needed to restore and run the system, backup
electrical power
systems, the projected time for restoring the system, the
procedures for
testing the process of restoring the system to operation in
the event of
an outage, the documentation kept on system outages and on
potential
system problems that could result in outages.
Using redundant, hot-swappable systems with RAID-Array and multiple
Hot-swappable power
supply, partial automatic recovery is expected, if an
element of the central or mirror
servers crashes. Recovery time: service
availability maintained, technical maintenance
required, 1 hour.
In case of complete crash of the central registry server, the mirror
server will go immediately
and transparently in operation. As the data are
systematically updated between central and
mirror servers, no information
are loss during this recovery mecanism. Recovery time:
service
availability maintained, technical maintenance required, 8 hours.
In the case of failure without the possibility to access the
RAID-array, data recovery can be
done from the daily backup-tape. Assumed
recovery time, 8 hours.
Support for registrars and
for Internet users and registrants. Describe
technical help systems,
personnel accessibility, web-based, telephone and
other support, support
services to be offered, time availability of support,
and
language-availability of support.
There will be different levels Support for registrars
·
Email.
·
Web based help service.
·
Telephone.
A support team will be accessible 7days/7, 24h/24, for phone and mail
technical support. The mission of
the support team includes also the
registry
maintenance.
In the initial phase English languages will be supported, but the
registry-
registrar agreement will have provisions that the registrar have
to provide
support for registrants.
Estimated annual
costs of running Registry for New TLD
Engineering and technical costs:
monitoring and 24x7 availability: 450 K
new
developments,registrars support: $200 K
back-office
and technical customer services: $50 K
Other
costs :
Connectivity
50 K$
equipment
amortization: 25 K
property and
plants: $25 K
travel /
trainings : $50 K
G&A : $50
K
Variable costs
for domains exceeding 5000: $5
Technical
Glossary.
Digital certificate
A structure for binding a principal's identity to its public key. A
certification authority (CA) issues and digitally signs a
digital
certificate.
Digital signature
A method for verifying that a message originated from a
principal and that it has not changed en route. Digital signatures is
typically
performed by encrypting a digest of the message with the private key of the
signing party.
FIREWALL
A
firewall is a set of related programs, located at a network gateway server,
that protects the resources of a private network
from users from other
networks. (The term also implies the security policy that is used with the
programs.) An enterprise
with an intranet that allows its workers access
to the wider Internet installs a firewall to prevent outsiders from accessing
its own private data resources and for controlling what outside resources its
own users have access to.
PGP
PGP (Pretty Good Privacy) is a popular
program used to encryption and decrypt e-mail over the Internet. It can also be
used
to send an encrypted digital signature that lets the receiver verify
the sender's identity and know that the message was
not changed en route.
Available both as freeware and in a low-cost commercial version, PGP is the
most widely used
privacy-ensuring program by individuals and is also used
by many corporations. PGP can also be used to encrypt files
being stored
so that they are unreadable by other users or intruders.
IPSec (Internet Protocol Security protocol)
IPSec
(Internet Protocol Security) is a developing standard for security at the
network or packet-processing layer of network
communication. Earlier
security approaches have inserted security at the application layer of the
communications model.
IPSec will be especially useful for implementing
virtual private networks and for remote user access through dial-up
connection
to private networks. A big advantage of IPSec is that security arrangements can
be handled without requiring
changes to individual user computers. Cisco
has been a leader in proposing IPSec as a standard (or combination of
standards
and technologies) and has included support for it in its network routers.
TUNNELING
Relative
to the Internet, tunnelling is using the Internet as part of a private secure
network. The "tunnel" is the particular path
that a given
company message or file might travel through the Internet.
VPN (virtual private network)
A
virtual private network (VPN) is a private data network that makes use of the
public telecommunication infrastructure,
maintaining privacy through the
use of a tunnelling protocol and security procedures.