ENUM -- Telephone Number Mapping A. Mayrhofer
Working Group enum.at
Internet-Draft B. Hoeneisen
Expires: January 9, 2006 Switch
July 8, 2005
ENUM Validation Architecture
draft-mayrhofer-enum-validation-arch-00
Status of this Memo
By submitting this Internet-Draft, each author represents that any
applicable patent or other IPR claims of which he or she is aware
have been or will be disclosed, and any of which he or she becomes
aware will be disclosed, in accordance with Section 6 of BCP 79.
Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF), its areas, and its working groups. Note that
other groups may also distribute working documents as Internet-
Drafts.
Internet-Drafts are draft documents valid for a maximum of six months
and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress."
The list of current Internet-Drafts can be accessed at
http://www.ietf.org/ietf/1id-abstracts.txt.
The list of Internet-Draft Shadow Directories can be accessed at
http://www.ietf.org/shadow.html.
This Internet-Draft will expire on January 9, 2006.
Copyright Notice
Copyright (C) The Internet Society (2005).
Abstract
An ENUM domain name is tightly coupled with the underlying E.164
number. The process of verifying whether or not the Registrant of an
ENUM domain name is identical to the Assignee of the corresponding
E.164 number is commonly called "validation". This document
describes validation requirements and a high level architecture for
an ENUM validation infrastructure.
Mayrhofer & Hoeneisen Expires January 9, 2006 [Page 1]
Internet-Draft ENUM Validation Architecture July 2005
Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3
1.1 Requirements . . . . . . . . . . . . . . . . . . . . . . . 3
2. ENUM Provisioning Model and Roles . . . . . . . . . . . . . . 4
2.1 Number Assignment Entity (NAE) . . . . . . . . . . . . . . 5
2.2 Assignee . . . . . . . . . . . . . . . . . . . . . . . . . 6
2.3 Registrant . . . . . . . . . . . . . . . . . . . . . . . . 7
2.4 Validation Entity (VE) . . . . . . . . . . . . . . . . . . 7
2.5 Registry . . . . . . . . . . . . . . . . . . . . . . . . . 7
2.6 Registrar . . . . . . . . . . . . . . . . . . . . . . . . 7
2.7 Domain Name System Service Provider (DNS-SP) . . . . . . . 8
2.8 Application Service Provider (ASP) . . . . . . . . . . . . 8
3. Validation Process Assumptions . . . . . . . . . . . . . . . . 8
3.1 Work Flow . . . . . . . . . . . . . . . . . . . . . . . . 8
3.2 Trust Relations . . . . . . . . . . . . . . . . . . . . . 9
3.3 Data Flow and Format . . . . . . . . . . . . . . . . . . . 10
4. Example Scenarios . . . . . . . . . . . . . . . . . . . . . . 10
4.1 E.164 Number Assignment along with ENUM Registration . . . 10
4.2 Fully Disjoint Roles . . . . . . . . . . . . . . . . . . . 12
5. Security Considerations . . . . . . . . . . . . . . . . . . . 14
5.1 Fraud Prevention . . . . . . . . . . . . . . . . . . . . . 14
5.2 Assignee Data . . . . . . . . . . . . . . . . . . . . . . 14
6. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 14
7. References . . . . . . . . . . . . . . . . . . . . . . . . . . 14
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . 15
Intellectual Property and Copyright Statements . . . . . . . . 16
Mayrhofer & Hoeneisen Expires January 9, 2006 [Page 2]
Internet-Draft ENUM Validation Architecture July 2005
1. Introduction
ENUM [1] uses the Domain Name System (DNS) [2] for mapping E.164
numbers [3] to Uniform Resource Identifiers (URIs). E.164 numbers
are converted to ENUM domain names through means described further in
RFC 3761 [1].
"Ordinary" domain names are usually allocated on a first-come-first-
served basis, where the associated registration data is the complete
source of ownership. However, ENUM domain names are linked to E.164
numbers, and thus intrinsically tied to the status and the Assignee
of the corresponding E.164 number.
1.1 Requirements
Preserving integrity between ENUM and E.164 is one of the main
concerns in current ENUM implementations, and often one of the
reasons why "trials" precede commercial implementations.
To maintain this relationship between E.164 numbers and ENUM domain
names, registration processes must ensure that during the entire
lifetime of an ENUM delegation the following requirements are
fulfilled:
o The ENUM domain name either corresponds to an assigned E.164
number, or the respective E.164 number is being assigned during
the registration process itself.
o The corresponding E.164 number is within a number area approved to
be used with ENUM.
o The registration of the ENUM domain name is authorized by the
Assignee of the corresponding E.164 number; i.e. the entity
requesting the registration of an ENUM domain name is either the
Assignee of the corresponding E.164 number itself or an entity
authorized to request registration on behalf of said Assignee.
o The Registrant of the ENUM domain is identical to the Assignee of
the corresponding E.164 number.
The process of verifying the above requirements during registration
is commonly called "initial validation". In addition to this one-
time validation process, provisions must be made that ENUM domain
name delegations are revoked when the requirements above are no
longer met. In other words, it must be ensured that the state of the
ENUM domain name tracks any change in state and ownership of the
corresponding E.164 number. The regular process of ensuring that the
above requirements are still satisfied is commonly called "recurring
validation" or "revalidation".
The above requirements are usually part of the local registration
policy issued by the authorities in charge of ENUM administration.
Mayrhofer & Hoeneisen Expires January 9, 2006 [Page 3]
Internet-Draft ENUM Validation Architecture July 2005
2. ENUM Provisioning Model and Roles
The above requirements lead to the introduction of a new role in the
provisioning model, an entity performing validation related tasks. A
typical ENUM provisioning model, on which this document is based, is
depicted in Figure 1:
ENUM Model
+----------+
.| Registry |- -- -- -- -- -- --
. +----------+ |
. |
. | | Trust
DNS Delegation | Relation
. | Registration |
. |
. | |
+--------+ +-----------+ +----+
| DNS-SP |-- -- -- -- --| Registrar |----------------| VE |
+--------+ Nameservers +-----------+ Validation +----+
: | / |
: | E.164 Number
: | ENUM Assignment
: NAPTR | Management _ Verification
: | / |
: | _
: | / |
+-----+ ENUM enabled +------------+ E.164 Number +-----+
| ASP |- -- -- -- -- --| Assignee = |-- -- -- -- --| NAE |
+-----+ Service | Registrant | Assignment +-----+
+------------+
Legend:
ASP: Application Service Provider
DNS-SP: Domain Name System Service Provider
NAE: Number Assignment Entity
VE: Validation Entity
Figure 1
These different roles are described further below. Note that an
entity can act in more than one of these roles simultaneously, e.g.
the Registrar, the DNS-SP, and the ASP roles could be performed by a
single company.
Mayrhofer & Hoeneisen Expires January 9, 2006 [Page 4]
Internet-Draft ENUM Validation Architecture July 2005
2.1 Number Assignment Entity (NAE)
A Number Assignment Entity (NAE) assigns E.164 numbers to end users.
Often, but not always, the Communication Service Provider (CSP) of
the end user (Assignee) acts as NAE. There are two main variants for
E.164 number assignments:
1. Indirect assignment:
The National Number Plan Administrator (NNPA) assigns ranges of
E.164 numbers to CSPs. Out of these ranges, the CSPs assign
numbers (or number blocks) to their customers (end-users,
Assignees). In this variant the CSPs perform the role of the
NAE.
2. Direct assignment:
In certain cases a NNPA assigns E.164 numbers directly to
Assignees (end-users), and therefore the NNPA acts as NAE in this
variant. Typically this concerns the assignment of special
purpose numbers (e.g. premium rate).
These two variants of E.164 number assignment are depicted in
Figure 2:
Mayrhofer & Hoeneisen Expires January 9, 2006 [Page 5]
Internet-Draft ENUM Validation Architecture July 2005
E.164 Number Assignment
+--------------------------------------------+
| International Telecommunication Union (ITU)|
+--------------------------------------------+
|
Country codes (e.g. +41)
|
v
+-------------------------------------------+
| National Number Plan Administrator (NNPA) |------------+
+-------------------------------------------+ |
| |
Number Ranges |
(e.g. +41 44268 xxxx) |
| |
v |
+--------------------------------------+ |
| Communication Service Provider (CSP) | |
+--------------------------------------+ |
| |
| Single Numbers
Either Single Numbers (e.g. +41 900 123456)
or Number Blocks [Variant 2]
(e.g. +41 44268 1234, +41 44268 15 xx) |
[Variant 1] |
| |
v |
+----------+ |
| Assignee |<------------------------------+
+----------+
Figure 2
As the Assignee (subscriber) data associated with the E.164 number is
the primary source of number assignment information, the NAE usually
holds the authoritative information required to confirm the
assignment.
A CSP that acts as NAE (indirect assignment) may therefore easily
assert the E.164 number assignment for their subscribers. However it
is unlikely that all CSPs will participate in ENUM validation.
2.2 Assignee
The person or organization to whom a NAE assigns a E.164 number is
called Assignee of this number. For the scope of this document, the
term Assignee, subscriber, and number-holder are used equivalently.
Mayrhofer & Hoeneisen Expires January 9, 2006 [Page 6]
Internet-Draft ENUM Validation Architecture July 2005
The Assignee has the "right to use" on the assigned E.164 number.
2.3 Registrant
The ENUM Registrant is the end user, the person or organization who
is the "holder" of the ENUM domain name.
The Registrant usually has control over his ENUM domain name(s) and
its DNS zone content.
2.4 Validation Entity (VE)
The Validation Entity (VE) verifies, whether or not the Registrant of
an ENUM domain name is identical to the Assignee of the corresponding
E.164 number.
Often it also verifies that the entity requesting the registration of
an ENUM domain name is either the Assignee of the corresponding E.164
number itself or an entity authorized to request registration on
behalf of said Assignee.
This role may be performed by several parties and is not necessarily
limited to a single entity.
The actual validation methods applied may vary depending on e.g. the
particular party, available data-sources, Assignee's choice, and
regulatory requirements.
2.5 Registry
The ENUM Registry operates the master database of ENUM domain
delegations and runs the authoritative nameservers for the relevant
zone under e164.arpa. The Registry is a natural monopoly.
While the Registry could try to check the legitimacy of incoming
delegation requests, it is often undesirable for the Registry to deal
with the validation problem, as it may have no direct link to the
Registrant.
2.6 Registrar
An ENUM Registrar performs ENUM domain delegations on behalf of a
Registrant by interacting with the Registry, typically through a
protocol like Extensible Provisioning Protocol (EPP). This role is
similar to the one that Registrars fulfill in the "ordinary" domain
name registration world.
The Registrar may well not be the same entity as the CSP of the
Mayrhofer & Hoeneisen Expires January 9, 2006 [Page 7]
Internet-Draft ENUM Validation Architecture July 2005
Registrant. Therefore a Registrar may lack authoritative number-
assignment information. If the Registrar and the CSP are the same
entity (or has a source of authoritative data), the Registrar could
perform the role of the VE itself. However, prior to the
registration of an ENUM domain name, the Registrar has to ensure a
proper validation through a VE.
2.7 Domain Name System Service Provider (DNS-SP)
The Domain Name System Service Provider (DNS-SP) operates the
nameservers for the ENUM DNS zones, which contain the ENUM Naming
Authority Pointer (NAPTR) Resource Record (RR) entries [1].
In most cases the Registry delegates the ENUM DNS zones to the
nameservers at the DNS-SP.
Usually the DNS-SP is not involved in the validation process.
2.8 Application Service Provider (ASP)
The Application Service Provider (ASP) operates a service for the
Registrant. This service could be an IP telephony service, whereby
the service provider populates the ENUM zone for their customers so
that others can discover that customer's URI.
Usually the ASP is not involved in the validation process.
3. Validation Process Assumptions
3.1 Work Flow
The prototypical initial validation workflow using the above roles
and definitions consists of the following steps:
1. A potential Registrant approaches a Registrar, and orders an ENUM
domain name.
2. The Registrar chooses a cooperating Validation Entity, and
requests an initial validation for the ENUM domain name ordered.
3. The Validation Entity performs the actual validation, which could
require interaction with the Assignee/Registrant.
4. The Validation Entity indicates the result of the initial
validation to the Registrar.
5. If the validation process was successful, the Registrar
provisions the ENUM domain name with the Registry. Depending on
the local Registry policy, validation related information may be
provided to the Registry along with this registration.
In most cases, local policy mandates expiration dates to be imposed
on successful validations. If the ENUM delegation is to be kept
Mayrhofer & Hoeneisen Expires January 9, 2006 [Page 8]
Internet-Draft ENUM Validation Architecture July 2005
beyond this expiration date, recurring validation has to be
performed. A typical revalidation workflow involves the following
steps:
1. In good time before the current validation expires, the Registrar
requests the Validation Entity to revalidate the domain name in
question.
2. The Validation Entity verifies if the delegation requirements are
still met. It may use information acquired during the initial
validation or associated to the registration data.
3. The Validation Entity indicates the result of the recurring
validation to the Registrar.
4. In case the revalidation has been successful, the domain
delegation may persist. Local Registry policy may require
updating domain name registration data, especially in case the
Registry keeps validation related expiry information.
5. In case the revalidation has failed, the ENUM domain delegation
must be suspended, either by explicit interaction with the
Registry or -- if the Registry keeps validation related
information -- automatically when the current validation expires.
Local policy may grant a grace period on the expiration date.
This work flow ensures the integrity between the E.164 and ENUM
namespaces. ENUM domain delegations which fail to meet the
validation requirements are suspended from DNS.
3.2 Trust Relations
The above validation workflow implies the following trust relations:
o The Registry trusts the Validation Entities to enforce the local
validation policy.
o The Registrars trust the Validation Entities properly to perform
validation based on the Registrar's request.
o Depending on the amount of validation data provided to the
Registry additional trust relations may be necessary. Three cases
can be differentiated:
* The Registry receives no validation related data: The Registry
needs to trust the Registrar that validation has been
performed, and the result was positive. In addition, the
Registry needs to trust the Registrar that it will properly
remove delegations for which revalidation fails.
* The Registry receives validation related data including expiry
date, but there are no means of checking its authenticity: The
Registry needs to trust the Registrar that the validation data
provided is authentic.
* The Registry receives validation related data including expiry
date and means to verify its authenticity (e.g. a cryptographic
signature issued by the VE): No additional trust relations are
necessary.
Mayrhofer & Hoeneisen Expires January 9, 2006 [Page 9]
Internet-Draft ENUM Validation Architecture July 2005
3.3 Data Flow and Format
The validation process requires the following regular data flows
(Note: data flows not directly related to validation are out of scope
of this document):
o Registrars communicate with Validation Entities to initiate,
modify or cancel validation requests. Validation Entities act
upon validation requests, and provide validation results to
Registrars. Since Registrars could potentially communicate with
several Validation Entities, and Validation Entities could provide
services to several Registrars (worst case: full mesh), a
standardized protocol and data format should be used in this data
flow.
o If the local Registry policy mandates that validation related
information is to be stored along with delegation records, a
validation related data flow between Registry and Registrar is
required. Since the registration itself already requires
communication between those entities, validation related
information in a standardized data format should be embedded into
the existing Registry-Registrar protocol data flow.
o Validation Entities may need to communicate with Assignees to
perform validation. A Validation Entity may choose to perform all
communication with the Assignee via the requesting Registrar
rather than contacting the Assignee by itself. Since the actual
communication form and process is expected to greatly vary, it
does not make sense to specify any data formats or processes for
this purpose.
4. Example Scenarios
4.1 E.164 Number Assignment along with ENUM Registration
In this simple scenario we assume that the roles of the Registrar,
the VE, and the NAE are performed by the same entity, e.g. a Internet
Telephony Service Provider (ITSP). This ITSP is a CSP, that was
assigned number ranges by the NNPA. Out of these ranges he assigns
numbers to his customers (Assignees) to provide those with
communication services. The ITSP chooses to assign an E.164 number
together with the corresponding ENUM domain name. Therefore it can
perform the validation simply by reference to its subscriber
database.
Figure 3 shows the external interactions needed for the ENUM domain
name provisioning process:
Mayrhofer & Hoeneisen Expires January 9, 2006 [Page 10]
Internet-Draft ENUM Validation Architecture July 2005
E.164 Number Assignment along with ENUM Registration
+----------+
| Registry |
+----------+
^
|
|(3)
|
+--------------------------------------+
| |
| ITSP |
| +-----------+ +----+ |
| | Registrar | | VE | |
| +-----------+ (2) +----+ |
| |
+--------------------------+ |
^ | |
| | |
|(1) | |
| | |
| | |
+------------+ (4) | +-----+ |
| Assignee = |<----------| | NAE | |
| Registrant | | +-----+ |
------------- | |
+-----------+
Legend:
ITSP: Internet Telephony Service Provider
NAE: Number Assignment Entity
VE: Validation Entity
Figure 3
1. The ITSP receives an order for ENUM Services.
2. The ITSP assigns a free E.164 number and performs the validation
at the same time.
3. The ITSP sends an ENUM registration request to the Registry,
which might contain additional information about the validation
applied.
4. The ITSP sends a confirmation about the E.164 number assignment
and the ENUM registration to its customer, who is now Assignee
and Registrant.
This scenario is quite close to "ordinary" domain name registrations.
Mayrhofer & Hoeneisen Expires January 9, 2006 [Page 11]
Internet-Draft ENUM Validation Architecture July 2005
4.2 Fully Disjoint Roles
In this more complex scenario we assume that all roles of the ENUM
provisioning model are performed by different entities. In contrast
with the previous example (in Section 4.1), here we assume that the
ENUM domain name to be registered is based on an already assigned
E.164 number and the NAE in question provides the VE with access to
the subscriber database. We further assume that there is a
requirement for the VE to verify the intention of the Assignee. The
validation process therefore involves also contacting the Assignee.
Figure 4 shows the interactions needed for the ENUM domain name
provisioning process:
Mayrhofer & Hoeneisen Expires January 9, 2006 [Page 12]
Internet-Draft ENUM Validation Architecture July 2005
Fully Disjoint Roles
+----------+
| Registry |
+----------+
^
|
|(9)
|
|
| (3)
+-----------+ ---------->+----+
| Registrar |<---------- | VE |
+-----------+ (8) > +----+
^ / / ^ |
| / / | |
| (7)/ / | |
|(2) / / | |
| / / (5)| |
| / / | |
| / / | |
| / /(6) | |
| / / | |(4)
| / / | |
| / / | |
+------------+< | v
| Assignee = | +-----+
| Registrant |<---------- | NAE |
+------------+ (1) +-----+
Legend:
NAE: Number Assignment Entity
VE: Validation Entity
Figure 4
1. The NAE assigns an E.164 number. This assignment could have been
done long before the ENUM domain name registration, e.g. at the
time when the Assignee subscribed to a common telephony service.
2. The Assignee orders the corresponding ENUM domain name at a
Registrar of his choice.
3. The Registrar requests validation at an independent VE.
4. The VE contacts the subscriber database of the NAE, to verify
that the Assignee of the E.164 number corresponds to the
Registrant of the ENUM domain name.
Mayrhofer & Hoeneisen Expires January 9, 2006 [Page 13]
Internet-Draft ENUM Validation Architecture July 2005
5. The result of the NAE subscriber database is positive.
6. The VE performs a call-back to the E.164 number to be registered
as ENUM domain name, makes provisions for authentication and asks
the Assignee to confirm his intention.
7. The Assignee confirms and the VE documents this confirmation.
8. The VE returns a positive answer to the Registrar. The answer
might contain some additional information about the validation
process, such as expiration date, validation method applied, and
so on.
9. Finally the Registrar can send an ENUM registration request to
the Registry. Additional information about the validation
process might be sent along with the registration request.
5. Security Considerations
5.1 Fraud Prevention
Situations where an entity has control over the ENUM domain of a
third party's E.164 number impose high fraud potential. Unauthorized
control over an ENUM domain of a bank could eg. be used for "man in
the middle" attacks on telephone banking applications. Cases of such
attacks could discredit ENUM as a whole.
Implementing high quality validation processes is therefore crucial
to any ENUM deployment, and should receive high attention.
5.2 Assignee Data
When handling Assignee data, privacy and discretion issues must be
considered. Implementations transporting assignee data over the
internet must use authenticated and encrypted transport protocols.
Local registration/validation policy and agreements should clearly
limit usage of Assignee data.
6. Acknowledgements
The authors would like to thank the following persons for their
valuable suggestions and contributions: Lawrence Conroy, Michael
Haberler, Otmar Lendl, Marcel Parodi, Patrik Schaefer, Richard
Stastny
7. References
[1] Faltstrom, P. and M. Mealling, "The E.164 to Uniform Resource
Identifiers (URI) Dynamic Delegation Discovery System (DDDS)
Application (ENUM)", RFC 3761, April 2004.
[2] Mockapetris, P., "Domain names - Implementation and
Mayrhofer & Hoeneisen Expires January 9, 2006 [Page 14]
Internet-Draft ENUM Validation Architecture July 2005
Specification", STD 13, RFC 1035, November 1987.
[3] ITU-T, "The international public telecommunication numbering
plan", Recommendation E.164, May 1997.
Authors' Addresses
Alexander Mayrhofer
enum.at GmbH
Karlsplatz 1/9
Wien A-1010
Austria
Phone: +43 1 5056416 34
Email: alexander.mayrhofer@enum.at
URI: http://www.enum.at/
Bernie Hoeneisen
Switch
Neumuehlequai 6
CH-8001 Zuerich
Switzerland
Phone: +41 44 268 1515
Email: hoeneisen@switch.ch, b.hoeneisen@ieee.org
URI: http://www.switch.ch/
Mayrhofer & Hoeneisen Expires January 9, 2006 [Page 15]
Internet-Draft ENUM Validation Architecture July 2005
Intellectual Property Statement
The IETF takes no position regarding the validity or scope of any
Intellectual Property Rights or other rights that might be claimed to
pertain to the implementation or use of the technology described in
this document or the extent to which any license under such rights
might or might not be available; nor does it represent that it has
made any independent effort to identify any such rights. Information
on the procedures with respect to rights in RFC documents can be
found in BCP 78 and BCP 79.
Copies of IPR disclosures made to the IETF Secretariat and any
assurances of licenses to be made available, or the result of an
attempt made to obtain a general license or permission for the use of
such proprietary rights by implementers or users of this
specification can be obtained from the IETF on-line IPR repository at
http://www.ietf.org/ipr.
The IETF invites any interested party to bring to its attention any
copyrights, patents or patent applications, or other proprietary
rights that may cover technology that may be required to implement
this standard. Please address the information to the IETF at
ietf-ipr@ietf.org.
Disclaimer of Validity
This document and the information contained herein are provided on an
"AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS
OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET
ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED,
INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE
INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED
WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
Copyright Statement
Copyright (C) The Internet Society (2005). This document is subject
to the rights, licenses and restrictions contained in BCP 78, and
except as set forth therein, the authors retain all their rights.
Acknowledgment
Funding for the RFC Editor function is currently provided by the
Internet Society.
Mayrhofer & Hoeneisen Expires January 9, 2006 [Page 16]