A. Zmolek Internet Draft Avaya Inc. Document: draft-zmolek-enum-pointer-00.txt Expires: August 2002 February 20, 2002 ENUM Service Resolution Pointer Status of this Memo This document is an Internet-Draft and is in full conformance with all provisions of Section 10 of RFC2026. 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. Abstract Current notions of service field tags in ENUM NAPTR records would frame the service exposure problem as a tradeoff between the privacy and heft involved in revealing detailed service information on the one hand or the arbitrary constraint of such information on the other. This draft suggests an alternative approach that keeps NAPTR record size small, places service exposure policy and presence capabilities in the hands of the ENUM registrant where it belongs, and minimizes impact to the ENUM registrar and their respective DNS architecture. Table of Contents Status of this Memo................................................1 Abstract...........................................................1 1. Introduction....................................................2 2. ENUM Exposure of Services: NAPTR Records and Service Field Tags.2 3. Shortcomings of ENUM Service Exposure...........................2 4. An ENUM Service Resolution Pointer..............................3 5. Benefits of a Service Resolution Pointer........................4 Zmolek Expires August 2002 1 INTERNET-DRAFT ENUM Service Resolution Pointer February 2002 6. Standardization of "Service Resolution" Services................4 7. Security Considerations.........................................5 References.........................................................6 Author's Address...................................................6 1. Introduction ENUM has mainly been focused on the mechanisms for representing E.164 numbers within DNS, delegation and administration of the resulting database records, etc. Until recently, the scope and nature of end-user service exposure was assumed to be relatively small and simple. Unfortunately, with the addition of service field tags that reveal codec capabilities and transcoding, service exposure is no longer small or simple. Too much detail results in more complexity, less privacy, and undermines the basic intent of ENUM. One way to address this issue is to constrain the range of services that can be exposed via ENUM, but it's not clear this can be done effectively without unreasonably limiting ENUM applicability. This draft suggests another option: an ENUM service field tag giving a URI pointer for a "service resolution" service. This would allow the end user to apply presence, privacy, and access control if desired. In addition, this draft identifies potential areas of further standardization around such services. 2. ENUM Exposure of Services: NAPTR Records and Service Field Tags ENUM exposes services as service URIs in NAPTR records. This usage is discussed in RFC-2916 [ENUM]. When a request is made to the ENUM service via DNS, the reply is a NAPTR record containing one or more service fields with associated URI and preference information. From Example 3.2.1 in RFC-2916: $ORIGIN 4.3.2.1.6.7.9.8.6.4.e164.arpa. IN NAPTR 100 10 "u" "sip+E2U" "!^.*$!sip:info@tele2.se!" . IN NAPTR 102 10 "u" "mailto+E2U" "!^.*$!mailto:info@tele2.se!" . This describes that the domain 4.3.2.1.6.7.9.8.6.4.e164.arpa is preferably contacted by SIP, and secondly by SMTP. In both cases, the next step in the resolution process is to use The resolution mechanism for each of the protocols, (SIP and SMTP) to know what node to contact for each. 3. Shortcomings of ENUM Service Exposure Zmolek Expires August 2002 2 INTERNET-DRAFT ENUM Service Resolution Pointer February 2002 Several problems exist within the current ENUM service exposure model. First, the service capabilities of the E.164 number are assumed to be static. This may be a reasonable assumption at the moment, but the emerging concept of presence-based routing undermines it. And simple PBX or Centrex services like call forwarding already challenge this assumption. In either case, the fact that an E.164 number will no longer be strongly bound to a single or specific endpoint means that valid service capabilities will have to be limited or derived dynamically from an authoritative presence system for that E.164 number. Secondly, detailed service capability exposure needed for certain fax, message interchange, and media transcoding services increases NAPTR record size, forcing DNS to run over TCP as UDP packet size maximums are reached. This is a significant problem, as it may force clients to use a special DNS resolver and adds substantial delay to the ENUM resolution process, rendering it less useful overall. And most importantly, ENUM has no reasonable way of directly applying privacy and access control. ENUM was intended to be a public service and as such it does not attempt to limit access to service capability information. Unfortunately, the proliferation of such information has substantial privacy implications. With the advent of complex service field tags, profiling techniques can provide yet more information to a malicious user. In order to address these shortcomings of ENUM service exposure, service resolution for dynamic services will need to take place outside of the DNS system. Even if DNS had methods for access control, the nature of DNS caching and lifetime of records would pose problems for dynamic service resolution. Moreover, managing multiple models for policy, identity, and other associated rules would be problematic for ENUM service providers who require reliable but fairly rigid mass-market architectures. 4. An ENUM Service Resolution Pointer To link to a "service resolution" service, an appropriate service tag and URI pointer is needed. This draft will not advocate a specific service field tag, since it should be derived from a specific, well-defined service. Nor will this draft advocate a particular service, since more than one service may become useful as presence and other "service resolution" services proliferate. Nevertheless, for purposes of example, this draft will use "pres+E2U" as a representative service tag for an as-yet-undefined presence service. So if we assume the existence of a well-defined presence service using a "pres:" URI, then the author's ENUM NAPTR record might contain the following: Zmolek Expires August 2002 3 INTERNET-DRAFT ENUM Service Resolution Pointer February 2002 $ORIGIN 1.0.0.4.4.4.4.0.2.7.1.e164.arpa. IN NAPTR 100 10 "u" "pres+E2U" "!^.*$!pres:zmolek@avaya.com!" . This would signal to the querying element that service availability for this E.164 number is handled by my presence service via a specific URI, namely "pres:zmolek@avaya.com". The next step depends on the protocol indicated by the URI. The "pres" protocol and its implementation in this presence service will address issues of query structure, access control, and the like. While it can be argued that the "sip+E2U" service tag is a already sufficient as a service resolution pointer because it can point to other SIP services, the reality is that SIP-based service can only act as a service resolver for services that are already well-defined within SIP. With the possible exception of POTS service, SIP presence services are not currently designed to point to services offered via non-SIP signaling protocols. 5. Benefits of a Service Resolution Pointer First and most importantly, a service resolution pointer places control over service exposure into the hands of the ENUM registrant where it belongs. Of course, the registrant may still choose to expose services directly through ENUM. But for many potential registrants, control over service exposure is a prerequisite for participation in ENUM registration in the first place. For ENUM service providers, having a service resolution pointer opens the door to additional value-added services while addressing the rising tide of privacy and security concerns surrounding ENUM. ENUM registrants may choose to have presence, policy, and privacy services provided by their ENUM registrar. Key to the value of the service resolution pointer is that no modification of the ENUM standard is required. As far as ENUM is concerned, the "service resolution" service is, in fact, a valid E.164-associated service like any other. 6. Standardization of "Service Resolution" Services Naturally, the utility of a service resolution pointer is limited if the service itself isn't standardized. Detailed specification of such a service is likely beyond the scope of the ENUM working group and will not be discussed in this draft. Nevertheless, the need exists for standardized queries, data formatting, and associated protocols and interfaces associated with one or more such services. It is this author's assertion that existing work has not sufficiently addressed the need for a well-defined, general-purpose presence service--e.g. one that is not tightly bound to either the PSTN carrier or IM service provider model, nor bound to a specific Zmolek Expires August 2002 4 INTERNET-DRAFT ENUM Service Resolution Pointer February 2002 signaling protocol. Those with interest in creating such a general- purpose presence service specification are encouraged to contact the author. 7. Security Considerations In general, this proposed approach provides opportunities for improving ENUM security without weakening the underlying security of ENUM services. Use of a service resolution pointer in NAPTR records can improve confidentiality and allow for request authentication and authorization if desired. Given that a "service resolution" service tag is treated under ENUM just as any other exposed service, the same basic security considerations apply. Zmolek Expires August 2002 5 INTERNET-DRAFT ENUM Service Resolution Pointer February 2002 References [ENUM] Falstrom, P., "E.164 number and DNS", RFC 2916, September, 2000 Author's Address Andrew Zmolek Avaya, Inc. 8740 Lucent Blvd. 403E273 Highlands Ranch, CO 80129 United States Phone/Fax: +1 720 444 4001 Email: zmolek@avaya.com Zmolek Expires August 2002 6