One document matched: draft-ietf-enum-void-00.txt
IETF ENUM WG R. Stastny
Internet Draft OeFEG
L. Conroy
Document:draft-ietf-enum-void-00.txt Siemens Roke Manor Research
Expires: March 2005 October 2004
IANA Registration for Enumservice VOID
<draft-ietf-enum-void-00.txt>
Status of this Memo
By submitting this Internet-Draft, I certify that any applicable
patent or other IPR claims of which I am aware have been disclosed,
or will be disclosed, and any of which I become aware will be
disclosed, in accordance with RFC 3668.
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 a "work in progress."
The list of current Internet-Drafts can be accessed at
http://www.ietf.org/1id-abstracts.html
The list of Internet-Draft Shadow Directories can be accessed at
http://www.ietf.org/shadow.html
Copyright Notice
Copyright (C) The Internet Society (2004). All Rights Reserved.
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
communications service. When such an indication is provided, an ENUM
client can detect calls that will fail "early".
Conventions used in this document
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 RFC-2119 [1].
1. 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 [2] as
native global addresses. If a potential caller has an E.164 number,
then to place a call using this address has needed 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 [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.
2. 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".
3. The proposed solution
We propose an explicit indication of this "number unassigned" state.
This uses a NAPTR 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 an 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.
4. ENUM Service Registration - VOID
As defined in [3], the following is a template covering information
needed for the registration of the Enumservice specified in this
document.
Enumservice Name: "VOID"
Type(s): "void"
Subtype(s): "mailto", "http", "https"
URI Scheme(s): "mailto:", "http:", "https:"
Functional Specification: The proposed solution in section 3.
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 6
Intended usage: COMMON
Authors:
Lawrence Conroy, Richard Stastny (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 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 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.
5. Examples
(i) 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.foo!"
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.
(ii) VOID:http and VOID:https
$ORIGIN 0.6.9.2.3.6.1.4.4.e164.arpa.
4.8.0 NAPTR 10 100 "u" "E2U+void:http"
"!^.*$!http:\/\/www.nra.foo\/drama-numbers\/index.html!"
$ORIGIN 0.6.9.2.3.6.1.4.4.e164.arpa.
4.8.0 NAPTR 10 100 "u" "E2U+void:https"
"!^.*$!https:\/\/connect.nra.foo\/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.
6. 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[8] to these, is provided in[3].
The specific issues applicable to this registration are:
(i) 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.
(ii) 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.
(iii) 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.
7. IANA Considerations
This document requests registration of the E2U+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.
8. Normative References
1 Bradner, S., "Key words for use in RFCs to Indicate Requirement
Levels", BCP 14, RFC 2119, March 1997.
2 ITU-T, "The International Public Telecommunication Number
Plan", Recommendation E.164 , May 1997.
3 Faltstrom, P. and Mealling M., "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", STD
13, RFC 1034, November 1987.
5 Hofmann, P., Masinter, L., Zawinski, J, "The mailto URL scheme",
RFC2368, July 1998.
6 Fielding, R., Gettys, J., Mogul, J., Frystyk, H., Masinter, L.,
Leach, P. and T. Berners-Lee, "Hypertext Transfer Protocol -
HTTP/1.1", RFC 2616, June 1999;
7 Rescola, E., "HTTP Over TLS", RFC 2818, May 2000.
9. Informative References
8 Eastlake, D.,"Domain Name System Security Extensions", RFC 2535,
March 1999
9 Bradner, S., "The Internet Standards Process -- Revision 3", BCP
9, RFC 2026, October 1996.
10 Bradner, S., "Intellectual Property Rights in IETF Technology",
BCP 78, RFC3667, February 2004
11 Bradner, S., "IETF Rights in Contributions", BCP 79, RFC3668,
February 2004
10. Acknowledgments
Thanks to Jim Reid for the substantial inputs regarding the
mechanism to query the enclosed zone and to Patrik Faltstrom and
Michael Mealling for their feedback.
11. Author's Addresses
Lawrence Conroy
Siemens Roke Manor Research
Roke Manor
Romsey
United Kingdom
Phone: +44-1794-833666
Email: lwc@roke.co.uk
Richard Stastny
OeFEG
Arsenal Objekt 24, Postbox 147
1140 Vienna
Austria
Phone: +43 664 420 4100
Email: richard.stastny@oefeg.at
This draft expires in March 2005
Full Copyright Statement
Copyright (C) The Internet Society (2004). 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.
Disclaimer of Warranty
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.
Disclaimer of Validity
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.
Acknowledgement
Funding for the RFC Editor function is currently provided by the
Internet Society.| PAFTECH AB 2003-2026 | 2026-04-24 02:39:59 |