One document matched: draft-ietf-enum-void-02.txt
Differences from draft-ietf-enum-void-01.txt
ENUM R. Stastny
Internet-Draft Oefeg
Expires: April 22, 2006 L. Conroy
Siemens Roke Manor Research
J. Reid
DNS-MODA
October 19, 2005
IANA Registration for Enumservice VOID
<draft-ietf-enum-void-02.txt>
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 April 22, 2006.
Copyright Notice
Copyright (C) The Internet Society (2005).
Abstract
This document registers the Enumservice 'void' using the URI schemes
'mailto:' and 'http:' as per the IANA registration process defined in
the ENUM specification, RFC3761. This Enumservice may be used to
indicate that the E.164 number (or E.164 number range) tied to the
domain in which the enclosing NAPTR is published is not assigned for
Stastny, et al. Expires April 22, 2006 [Page 1]
Internet-Draft IANA VOID Enumservice Registration October 2005
communications service. When such an indication is provided, an ENUM
client can detect calls that will fail "early".
Table of Contents
1. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 3
2. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 4
3. The Problem . . . . . . . . . . . . . . . . . . . . . . . . . 5
4. The Proposed Solution . . . . . . . . . . . . . . . . . . . . 7
5. ENUM Service Registration - VOID . . . . . . . . . . . . . . . 8
6. Examples . . . . . . . . . . . . . . . . . . . . . . . . . . . 10
7. Operational Guidance . . . . . . . . . . . . . . . . . . . . . 11
8. Security Considerations . . . . . . . . . . . . . . . . . . . 14
9. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 15
10. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 16
11. References . . . . . . . . . . . . . . . . . . . . . . . . . . 17
11.1. Normative References . . . . . . . . . . . . . . . . . . 17
11.2. Informative References . . . . . . . . . . . . . . . . . 17
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 18
Intellectual Property and Copyright Statements . . . . . . . . . . 19
Stastny, et al. Expires April 22, 2006 [Page 2]
Internet-Draft IANA VOID Enumservice Registration October 2005
1. Terminology
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
document are to be interpreted as described in BCP 14, [1].
Stastny, et al. Expires April 22, 2006 [Page 3]
Internet-Draft IANA VOID Enumservice Registration October 2005
2. Introduction
The Circuit Switched Network (CSN) of which the Public Switched
Telephone Network, Integrated Services Digital Network, and Public
Land Mobile Network are part is designed to use E.164 numbers E.164
[2] as native global addresses. If a potential caller has an E.164
number, then to place a call using this address he or she needs a way
to pass the request either directly or indirectly to systems "in" the
CSN for them to forward.
ENUM has introduced a mechanism to find other contact addresses when
given an E.164 number. Thus, if the caller (or an agent somewhere in
the call path) has access to the global DNS, they can use ENUM
RFC3761 [3] to find alternative contacts to the E.164 number and
place the call using whatever system was indicated in those contacts.
However, ENUM entries may not exist for a given E.164 number for two
reasons. Either the assignee who is entitled to register an ENUM
domain associated with the E.164 number they hold has chosen not to
request this registration, or the number is not currently assigned
for communications service.
In either situation, the caller has no other information and so no
alternative to placing the call via the system that uses E.164
numbers as global identifiers; at present, this is the CSN.
Stastny, et al. Expires April 22, 2006 [Page 4]
Internet-Draft IANA VOID Enumservice Registration October 2005
3. The Problem
At present, from the ENUM client's perspective, two possibilities
exist: there is an ENUM domain that potentially holds alternative
contacts, or there is no ENUM domain, in which case a query on ENUM
will return a DNS response showing 'no such domain' (NXDOMAIN, code
3)[4].
This latter response is ambiguous. There are two potential reasons
for the lack of an ENUM domain holding alternative contacts; either
the assignee has chosen not to register the domain, or the E.164
number is not assigned for communications service at present.
If the number is assigned, then the caller can use the E.164 number
to place the call via a network that uses such identifiers as global
addresses (i.e. the CSN). If however, there is no domain because the
associated E.164 number is not assigned for communications service,
then any attempt to place the call via the CSN will fail.
What would be useful is a mechanism "between" a registration holding
NAPTRs with URIs and the lack of a domain registration. In this way,
an entity who is responsible for E.164 numbers in a range can
indicate that a particular number has not been assigned to anyone for
communications service. For example, if a communications service
provider has been allocated responsibility for delivering calls to
endpoints identified with E.164 numbers in a block, then they may
have some numbers in that block that are currently unused. These
E.164 numbers are not used to terminate calls to end users.
An originating user agent cannot differentiate this state from the
one in which there is an end user as a number assignee, but that end
user has have chosen not to "publish" other contacts. In effect, it
would be more useful if the originating end user could receive a
response that states "there is no service via this number", as
opposed to "there may be service via this number, but there are no
alternative contacts available".
In short, the issue is distinguishing between E.164 numbers that do
not have corresponding ENUM entries but are supported via the PSTN
and those E.164 numbers that are not terminated on the PSTN. In this
latter case lack of a NAPTR holding a destination URI really implies
that there is no service at all for this telephone number. For
example, some number ranges have been allocated for service that is
provided only via reference to an ENUM domain, and terminate on the
Internet (i.e. these calls will terminate only at a VoIP end point).
The fundamental problem is that there may be inconsistencies between
the E.164 name space as it is understood by the National Regulatory
Authority (NRA) and how that name space is represented in ENUM, as
Stastny, et al. Expires April 22, 2006 [Page 5]
Internet-Draft IANA VOID Enumservice Registration October 2005
service moves towards being provided in some cases only via non-PSTN
access. In effect, the PSTN may not have complete information and
ENUM may be required to deliver a call, but the data stored in ENUM
at present may be ambiguous.
For applications such as an ENUM-aware VoIP/PSTN gateway, this
presents a problem. These would use ENUM to decide how to route or
terminate a call. A simple default configuration rule for such a
gateway would probably be: "if the number called is not in ENUM or
has no NAPTR records, dump the call to the PSTN". Such a rule is
likely to be the norm while most telephony traffic uses the public
telephone network. In other words, if the response from the DNS is
that the number does not exist in ENUM, the gateway would try to
terminate the call on the PSTN.
This will not always work. The number that was attempted may be in
some range that cannot be terminated on the PSTN: a block assigned
for VoIP and ENUM exclusively, and for which there is no PSTN
termination, for example. If a number in such a range had not been
entered into ENUM, the DNS would return the expected NXDOMAIN or
NOHOST response, causing the gateway to take its default action which
would have undefined results. Where a "not in service" number is
within such a special number block, the typical action of a PSTN
element will be to pass this on to a VoIP/PSTN gateway, where as just
described another ENUM query may be used to determine call treatment:
the result could be a processing "loop".
Stastny, et al. Expires April 22, 2006 [Page 6]
Internet-Draft IANA VOID Enumservice Registration October 2005
4. The Proposed Solution
We propose an explicit indication of this "number unassigned" state.
This uses a NAPTR in the zone associated with an unassigned telephone
number, or at least in the "enclosing" zone, with an Enumservice
called VOID that should be taken as an assertion that the associated
E.164 number is not assigned to an end user for communications
service; it's an unused number.
This NAPTR can also be used by a National Regulatory Authority (NRA)
to indicate number blocks that it has reserved or has not allocated,
or has not assigned to a service provider.
It is a matter for individual Countries whether or not they will
support (or require) information giving the identity of the current
"owner" of an E.164 number within their responsibility to be made
available via IRIS/WHOIS. Thus it may not be possible to use these
protocols to find out the entity responsible for a number or number
range, particularly where that number or range is not currently "in
use".
For this reason, we propose that the VOID indication also includes a
contact address (an email address or a web address) by which the
authority responsible for this number (or range) can be contacted.
This may not be the same entity as the one that maintains the DNS
service for that "enclosing zone": often the NRA will sub-contract a
Registry Operator to maintain the DNS, but it is the NRA who is the
authority for the E.164 number range, not that Registry Operator.
Stastny, et al. Expires April 22, 2006 [Page 7]
Internet-Draft IANA VOID Enumservice Registration October 2005
5. ENUM Service Registration - VOID
Enumservice Name: "VOID"
Enumservice Type: "void"
Enumservice Subtypes: "mailto", "http", "https"
URI Schemes: "mailto:", "http:", "https:"
Functional Specification: The proposed solution in Section 4.
Definition of expected action:
If a NAPTR with this Enumservice is received, it indicates that
the queried E.164 number is currently unassigned to an end user
for communications service.
The recipient SHOULD treat this response as if they had received a
"number not in service" indication from a terminating network.
Note that, whatever subtype exists for this Enumservice, the
generated URI is not a potential target for any current call.
This contact (mailto:[5], http:[6], or https:[7]) MUST NOT be used
in normal call processing but only if there is a non-call related
reason to contact the number holder or authority.
Security considerations: see Section 8.
Intended usage: COMMON
Authors
Lawrence Conroy, Richard Stastny, Jim Reid (for authors contact
details see Authors' Addresses section).
Any other information that the author deems interesting:
There are three possible subtypes (each with an associated URI
scheme). In the first case, the subtype is "mailto" and has a
generated URI scheme of "mailto:". This can be used to hold an
email address of the entity responsible for the unassigned number
or number range (such as the NRA, or the Communications Service
Provider or CSP to whom they have allocated a block of numbers, of
which the current number is unused).
The second case has a sub-type of "http" and has a generated URI
scheme of "http:". The last case has a sub-type of "https" and an
Stastny, et al. Expires April 22, 2006 [Page 8]
Internet-Draft IANA VOID Enumservice Registration October 2005
associated generated URI scheme of "https:". In both these, the
URI can be used to indicate a web site holding information on the
number (or number range) associated with the domain holding this
NAPTR. They differ only in whether or not the URL "points to" a
web site using either a standard or TLS-secured connection.
Please see also Section 7 for a discussion on choices for where to
provision the VOID NAPTR and its impact on "real world"
performance.
Stastny, et al. Expires April 22, 2006 [Page 9]
Internet-Draft IANA VOID Enumservice Registration October 2005
6. Examples
1. VOID:mailto
$ORIGIN 0.6.9.2.3.6.1.4.4.e164.arpa.
3.8.0 NAPTR 10 100 "u" "E2U+void:mailto"
"!^.*$!mailto:num-drama-info@nra.cc.example!"
This indicates that the controller of the number block
+441632960xxx does not provide telephony service via the number
+441632960083; it is not assigned to an end user. Information on
the status of this number may be obtainable by contacting the
email address held in the regexp field.
2. VOID:http or VOID:https
$ORIGIN 1.6.9.2.3.6.1.4.4.e164.arpa.
4.8.0 NAPTR 10 100 "u" "E2U+void:http"
"!^.*$!http:\/\/www.nra.cc.example\/drama-numbers\/index.html!"
$ORIGIN 2.6.9.2.3.6.1.4.4.e164.arpa.
4.8.0 NAPTR 10 100 "u" "E2U+void:https"
"!^.*$!https:\/\/connect.nra.cc.example\/drama-numbers\/
secure.html!"
Both of these examples indicate that the controller of the number
block +441632960xxx does not provide communication service via
the number +441632960084; it is not assigned to an end user.
Information on the status of this number may be obtained by
making an HTTP connection to the web URL shown in the regexp
field of the former example, or making a connection using TLS to
the secure web URL held in the regexp field of the latter
example.
Stastny, et al. Expires April 22, 2006 [Page 10]
Internet-Draft IANA VOID Enumservice Registration October 2005
7. Operational Guidance
There are two possible scenarios where this VOID NAPTR could be
returned. One is direct and the other is indirect.
In the direct scenario, an ENUM lookup for a number explicitly
returns the VOID NAPTR. This could be done for a variety of reasons.
The number could have been delegated to an end user who has chosen to
insert this record: for instance it's in an ENUM or VoIP only number
block and the end user's SIP gateway is out of service. Another
possibility is that a communications service provider inserts VOID
NAPTRs for each of the numbers in the block that have not been
assigned to end-users. For these examples, the VOID NAPTR response
indicates to the client that the number is known to ENUM but there
are no communication end-points associated with it. The client can
then signal an error to the application or end user instead of then
trying and failing to terminate the call on the PSTN, which would
have been the typical behaviour of an ENUM-aware VoIP/PSTN gateway if
the ENUM lookup had returned an NXDOMAIN or NOHOST response.
For the indirect scenario, the client would make an additional DNS
lookup following an NXDOMAIN or NOHOST reply to an ENUM lookup.
NOHOST responses are returned when a name exists in the DNS, but not
as the record type requested. An NXDOMAIN reply from the DNS
indicates that the name does not exist. This could happen because
the number has not been entered into ENUM or the client tried to
lookup a number that was not valid in the prevailing numbering plan.
In the case of a number in an ENUM or VoIP only number block, an
NXDOMAIN response would indicate that the number had not been
assigned to the end user. However, the querying client may not know
that this is within such a block, and so be unaware of this
interpretation for its current query. It would be undesirable for a
gateway to then use a NOHOST or NXDOMAIN reply to dump the call to
the PSTN. The gateway could use information in that response for a
second ENUM lookup and act on the data returned from that.
NOHOST or NXDOMAIN replies from the DNS include the SOA record for
the closest enclosing zone in the Authority Section of the response.
See [4] & [8]. For an ENUM-only block, the closest enclosing zone
could be the delegation for that block: 0.8.7.3.4.e164.arpa. If the
gateway looked up the non-existent domain
0.9.8.7.6.5.4.3.2.1.0.8.7.3.4.e164.arpa, it would get an NXDOMAIN
reply containing the SOA record for 0.8.7.3.4.e164.arpa. The gateway
could then perform an ENUM lookup for this name. This second query
could return a VOID NAPTR to indicate that the number cannot be
terminated on the PSTN, and a suitable error message would be
returned to the end user or application. If this second lookup also
returned an NXDOMAIN or NOHOST, the gateway could assume that the
Stastny, et al. Expires April 22, 2006 [Page 11]
Internet-Draft IANA VOID Enumservice Registration October 2005
number can be terminated successfully on the PSTN.
In this second, indirect, case, clients would make two queries before
being SURE of the correct approach to a call attempt. The client
would first query for the requested zone and receive an NXDOMAIN or
NOHOST response, and then query the domain shown in the first
response as being the authority for the target (the "enclosing
zone"). It would not need to proceed further, but would in this case
have submitted two queries before determining the appropriate action.
This situation occurs only if no data at all has been entered into a
zone associated with a telephone number. An entry is instead only
available in the enclosing zone associated with the number block.
The indirect case ensures that the client always has a mechanism to
determine the appropriate action, using only data retrieved from DNS.
This approach succeeds, even where the number queried is invalid, and
requiring no knowledge of the target numbering plan by the querying
client.
In the early stages of ENUM deployment, provisioning of the ENUM tree
will be sparse. Thus, if this approach were to be used as the
default, many queries would have to use it, resulting in less
efficient operation. It is a fallback mechanism, and like all
fallbacks, it should be the exception that ensures full coverage of
all cases rather than the norm.
In most scenarios, a block of telephone numbers will be assigned to a
service provider, and that service provider will in turn allocate
individual telephone numbers (or groups of numbers) for services
provided to end customers. Rather than just provisioning a single
VOID NAPTR at the apex of the ENUM subtree associated with the number
block it has been assigned, the service provider can provision a VOID
NAPTR associated with each of the individual numbers (or groups of
numbers) within the number block that are not currently used. If the
individual number is then assigned for service to an end customer,
then the associated VOID NAPTR can be removed.
Thus, it is recommended that a service provider that has been
assigned a block of telephone numbers by its NRA should ensure that a
VOID NAPTR is returned for ENUM queries on the telephone numbers
within that block for which PSTN service is not provided. This can
be arranged by provisioning a VOID NAPTR associated with the Fully
Qualified Domain Name associated with each of the individual
telephone numbers within the block.
Whilst it is perfectly possible to provision a single wildcard entry
holding a VOID NAPTR to be returned for any query under the chosen
sub-tree apex where there is no assignment within the associated
number block, it is discouraged. The use of wildcards has been shown
Stastny, et al. Expires April 22, 2006 [Page 12]
Internet-Draft IANA VOID Enumservice Registration October 2005
to be counter-intuitive and so prone to errors. Provisioning
individual VOID NAPTRs for each number within a block is preferable,
as it maintains query efficiency whilst not being prone to subtle
behavioural flaws.
Stastny, et al. Expires April 22, 2006 [Page 13]
Internet-Draft IANA VOID Enumservice Registration October 2005
8. Security Considerations
DNS does not make policy decisions about the records that it shares
with an inquirer. All DNS records must be assumed to be available to
all inquirers at all times. The information provided within an ENUM
record set must therefore be considered to be open to the public.
An analysis of threats specific to the dependence of ENUM on the DNS,
and the applicability of DNSSEC [9] to these, is provided in [10].
The specific issues applicable to this registration are:
1. by including an email address, the responsible authority is
making this available globally. They should expect that the
published email address will be used to send unsolicited
commercial email to them.
2. by publishing the email address, they expose the identity of the
entity that has authority over this E.164 number (or range of
numbers). This may also be the case if a web URL is used.
3. by constructing a DNS response holding a VOID NAPTR, a third
party could initiate a denial of service attack on the assignee
of a number (or number range). The recipient of a "spoofed"
response would react by assuming that the associated E.164 number
is not in service, so denying calls to that number.
Stastny, et al. Expires April 22, 2006 [Page 14]
Internet-Draft IANA VOID Enumservice Registration October 2005
9. IANA Considerations
This document requests registration of the "void" Enumservice with
three sub-types (void:mailto, void:http and void:https) according to
the guidelines and specifications in RFC 3761 [3] and the definitions
in this document.
Stastny, et al. Expires April 22, 2006 [Page 15]
Internet-Draft IANA VOID Enumservice Registration October 2005
10. Acknowledgments
Thanks to Patrik Faltstrom, Michael Mealling an Peter Koch for their
thorough feedback, and colleagues in ETSI TISPAN who helped to
clarify VOID's operational features during the development of [11].
Stastny, et al. Expires April 22, 2006 [Page 16]
Internet-Draft IANA VOID Enumservice Registration October 2005
11. References
11.1. Normative References
[1] Bradner, S., "Key words for use in RFCs to Indicate Requirement
Levels", RFC 2119, BCP 14, March 1997.
[2] ITU-T, "The International Public Telecommunication Number Plan",
Recommendation E.164, May 1997.
[3] Faltstrom, P. and M. Mealling, "The E.164 to Uniform Resource
Identifiers (URI) Dynamic Delegation Discovery System (DDDS)
Application (ENUM)", RFC 3761, April 2004.
[4] Mockapetris, P., "DOMAIN NAMES - CONCEPTS AND FACILITIES",
RFC 1034, November 1987.
[5] Hoffman, P., Masinter, L., and J. Zawinski, "The mailto URL
scheme", RFC 2368, July 1998.
[6] Fielding, R. and et al. , "Hypertext Transfer Protocol --
HTTP/1.1", RFC 2616, June 1999.
[7] Rescola, E., "HTTP over TLS", RFC 2818, May 2000.
11.2. Informative References
[8] Andrews, M., "Negative Caching of DNS Queries (DNS NCACHE)",
RFC 2308, March 1998.
[9] Arends, R. and et al. , "Protocol Modifications for the DNS
Security Extensions", RFC 4035, March 2005.
[10] Atkins, D. and R. Austein, "Threat Analysis of the Domain Name
System (DNS)", RFC 3833, August 2004.
[11] ETSI, "Minimum Requirements for Interoperability of ENUM
Implementations", ETSI TS 102 172, January 2005.
[12] Bradner, S., "The Internet Standards Process -- Revision 3",
RFC 2026, BCP 9, October 1996.
[13] Bradner, S., "IETF Rights in Contributions", BCP 78, RFC 3978,
March 2005.
[14] Bradner, S., "Intellectual Property Rights in IETF Technology",
BCP 79, RFC 3979, March 2005.
Stastny, et al. Expires April 22, 2006 [Page 17]
Internet-Draft IANA VOID Enumservice Registration October 2005
Authors' Addresses
Richard Stastny
Oefeg
Postbox 147
1103 Vienna
Austria
Phone: +43-664-420-4100
Email: Richard.stastny@oefeg.at
Lawrence Conroy
Siemens Roke Manor Research
Roke Manor
Romsey
United Kingdom
Phone: +44-1794-833666
Email: lwc@roke.co.uk
Jim Reid
DNS-MODA
6 Langside Court
Bothwell, SCOTLAND
United Kingdom
Phone: +44 1698 852881
Email: jim@dns-moda.org
Stastny, et al. Expires April 22, 2006 [Page 18]
Internet-Draft IANA VOID Enumservice Registration October 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.
Stastny, et al. Expires April 22, 2006 [Page 19]
| PAFTECH AB 2003-2026 | 2026-04-24 02:39:12 |