IETF ENUM WG R. Stastny Internet Draft OeFEG L. Conroy Document:draft-stastny-enum-void-00.txt Siemens Roke Manor Research Expires: January 2005 July 2004 IANA Registration for enumservice void 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 scheme 'mailto:' as per the IANA registration process defined in the ENUM specification RFC3761 [2]. This 'ENUMservice' SHALL be used to indicate that the E.164 number or E.164 number range connected to the domain used in DNS as described in [2] is not assigned to an end-user in case of an E.164 number or to a communication service provider in case of an E.164 number range. 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 [3]. Stastny Expires - January 2005 [Page 1] Draft-stastny-enum-void-00.txt July 2004 Table of Contents 1. Introduction...................................................2 2. The problem....................................................2 3. The proposed solution..........................................3 4. ENUM Service Registration......................................4 5. Example........................................................5 6. Security considerations........................................5 7. IANA Considerations............................................5 8. Normative References...........................................6 9. Informative References.........................................6 10.Acknowledgments................................................6 11.Author's Addresses.............................................6 1. Introduction ENUM Registrations are used to make available Universal Resource Identifiers and other data associated with an assigned E.164 number. For ENUM, the E.164 number assignee has the exclusive right to register a domain associated with "their" number, and has exclusive control over the content made available in this zone. If an assignee of an E.164 number does not choose to register the associated ENUM domain, then any DNS query on that domain will return a response indicating 'no such domain' (NXDOMAIN, code 3)[4]. A major use of ENUM registrations is to "publish" URIs indicating alternative destination, so that potential callers who only know the E.164 number can find the appropriate URI to contact the registrant. If no registration exists associated with an E.164 number, then that potential caller (or their agents) have no further information, and so must "fall back" to passing the call to their default network, assuming that this will route the call appropriately. For voice calls this default network is usually the PSTN; the call is processed as a "normal" phone call. 2. The problem Some National Number Regulatory Authorities (NRA) have chosen to allocate a particular part of the E.164 number space under their control for exclusive use of ENUM registrations; that is, they have decided that calls to E.164 numbers in this range MUST be processed using ENUM, and delivered to the URI generated as a result of a successful ENUM query. A call cannot be simply "dropped" onto the default network for delivery, as there is no direct association between the E.164 number and a terminal connected to that network. Stastny Expires - January 2004 [Page 2] Draft-stastny-enum-void-00.txt July 2004 This raises an issue. If the originating user agent is unaware that this choice has been made for this part of the number space, they may assume that receipt of an NXDOMAIN response to a query on an E.164 number means that they should deliver the call onwards using their default call processing method. As control of the E.164 number space is distributed, it is quite possible that the user agent in one country is unaware of the assignment choices for an E.164 number under the allocation authority (NRA) of another country. This user agent may deliver the call using the normal mechanism, and it 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 provision, and so there is no-one with the right to register the associated domain. 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. As there is no end user as an assignee for an unused number, there cannot be a registration for the associated ENUM domain. An originating user agent cannot differentiate this state from the one in which there is an end user as a number assignee, but that they 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. Note that, where a number (or number range) has not been assigned to an end user, there cannot be an associated ENUM registration (or range of registrations). Thus there cannot be information made Stastny Expires - January 2004 [Page 3] Draft-stastny-enum-void-00.txt July 2004 available via ISIS/Whois on the identity of the current "owner" of the number. For this reason, we propose that the VOID indication also includes an email 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 As defined in [2], 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" URI Scheme(s): "mailto:" 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. Security considerations: see section 5 Intended usage: COMMON Authors: Lawrence Conroy, Richard Stastny (for authors contact details see Authors' Addresses section) Any other information that the author deems interesting: See above. Stastny Expires - January 2004 [Page 4] Draft-stastny-enum-void-00.txt July 2004 5. Example $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@ofcom.org.uk!" This indicates that the controller of the number block +441632960xxx does not provide telephony service via the number +441632960038; it is not assigned to an end user. 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[5] to these, is provided in[2]. 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 number range). (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 registers the E2U+void ENUM service according to specifications and guidelines in RFC 3761 [2] and the definitions in this document. Stastny Expires - January 2004 [Page 5] Draft-stastny-enum-void-00.txt July 2004 8. Normative References 2 Faltstrom, P. and Mealling M., "The E.164 to Uniform Resource Identifiers (URI) Dynamic Delegation Discovery System (DDDS) Application (ENUM)", RFC 3761, April 2004. 3 Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997 4 Mockapetris, P., "Domain Names - Concepts and Facilities", STD 13, RFC 1034, November 1987 9. Informative References 1 Bradner, S., "The Internet Standards Process -- Revision 3", BCP 9, RFC 2026, October 1996. 5 Eastlake, D., "Domain Name System Security Extensions", RFC 2535, March 1999 6 Bradner, S., "Intellectual Property Rights in IETF Technology", BCP 78, RFC3667, February 2004 7 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 Stastny Expires - January 2004 [Page 6] Draft-stastny-enum-void-00.txt July 2004 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. Acknowledgement Funding for the RFC Editor function is currently provided by the Internet Society. Stastny Expires - January 2004 [Page 7]