| Network Working Group | R. Gellens |
| Internet-Draft | Core Technology Consulting |
| Updates: 5222 (if approved) | B. Rosen |
| Intended status: Standards Track | May 11, 2020 |
| Expires: November 12, 2020 |
The LoST-Validation S-NAPTR Application Service Tag
draft-gellens-lost-validation-07
This document adds the "LoST-Validation" service tag to the Straightforward Naming Authority PoinTeR (S-NAPTR) Application Service Tag IANA registry. This tag can appear in a Naming Authority Pointer (NAPTR) Domain Name System (DNS) record to assist clients of the Location-to-Service Translation Protocol (LoST) in identifying LoST servers explicitly willing to perform location validation.
This Internet-Draft is submitted in full conformance with the provisions of BCP 78 and BCP 79.
Internet-Drafts are working documents of the Internet Engineering Task Force (IETF). Note that other groups may also distribute working documents as Internet-Drafts. The list of current Internet-Drafts is at https://datatracker.ietf.org/drafts/current/.
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."
This Internet-Draft will expire on November 12, 2020.
Copyright (c) 2020 IETF Trust and the persons identified as the document authors. All rights reserved.
This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (https://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Code Components extracted from this document must include Simplified BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Simplified BSD License.
This document adds 'LoST-Validation' to the S-NAPTR Application Service Tag IANA registry, and describes how this tag fits in the LoST server discovery procedure described in [RFC5222]. This tag is used with Naming Authority Pointer (NAPTR) Domain Name System (DNS) records so that clients of the Location-to-Service Translation Protocol (LoST) [RFC5222] can identify servers explicitly willing to perform location validation.
The Location-to-Service Translation Protocol, LoST [RFC5222] defines a mapping service with the additional ability for a client to request that a civic address be validated. The LoST protocol allows servers to ignore a request to perform location validation. The National Emergency Number Association (NENA) has defined an architecture for all-IP emergency services (known as "i3" [NENA-i3]), which defines the mapping (routing) and validation functions as two distinct functional elements, defined as an Emergency Call Routing Function (ECRF) and a Location Validation Function (LVF). NENA i3 requires that the mapping (ECRF) and validation (LVF) functions be separable, so that an entity responsible for a LoST server cluster can decide to provide mapping and validation services using consolidated or separate server clusters (i.e., using the same or separate boxes). The rationale is that the mapping service is used in real-time during emergency call routing, while the validation service is used in advance, typically when data is provisioned, and therefore the mapping service has much higher availability and response time requirements than the validation service. An organization might choose to deploy these services using different server clusters to make it easier to provide higher levels of service for the mapping function while shielding it from the potentially bursty load of validation, while another organization might choose to use the same sets of servers for both, configured and deployed to offer the high service level demanded of the mapping service.
In order to permit this separability, any entity querying a LoST server needs to be able to resolve an Application Unique String (AUS) into a URL for a LoST server that offers the required service (mapping or validation). This separability needs to be maintained throughout the LoST tree structure, from forest guide to leaf node (LoST architecture is described in [RFC5582]). Because LoST referrals return an AUS rather than a URL, either a different Service Tag or a DNS name convention (e.g., "ecrf.example.org" and "lvf.example.org") is needed to differentiate the different services. DNS name conventions are inflexible and fragile, making a different service tag the preferred approach.
Because a server discovered using the "LoST" application service tag may ignore a request to perform location validation, a service tag explicitly for location validation also reduces the likelihood (which has existed since [RFC5582]) of a client requiring location validation reaching servers unwilling to do so.
This document adds 'LoST-Validation' to the S-NAPTR Application Service Tag registry created by [RFC3958]. The 'LoST-Validation' tag serves as a counterpart to the 'LoST' tag added by [RFC5222]: The 'LoST' tag identifies servers able to perform the core mapping function, while 'LoST-Validation' identifies servers explicitly willing to perform the validation function.
Because some servers might be configured to provide both mapping and validation functions, a server identified using the 'LoST' service tag might also perform the validation function (and resolving the two tags might result in the same URL). Because the two functions might be separate, clients seeking a LoST server for location validation can first try U-NAPTR resolution using the 'Lost-Validation' service tag, and fallback to the 'LoST' service tag if this does not resolve to a usable LoST server.
LoST [RFC5222] specifies that LoST servers are located by resolving an application Unique String (AUS) using U-NAPTR/DDDS (URI-Enabled NAPTR/Dynamic Delegation Discovery Service) [RFC4848], and defines the 'LoST' Application service tag. In order to permit separability of the mapping and validation services performed using LoST, and to reduce the likelihood of a client requiring location validation reaching servers unwilling to do so, this document defines the 'LoST-Validation' service tag. NAPTR records for LoST servers available for location validation contain the 'LoST-Validation' service tag. An entity needing to perform location validation using LoST performs the discovery procedure as described in [RFC5222], except that the 'LoST-Validation' service tag is used in preference to the 'LoST' service tag. For both service tags, the HTTP and HTTPS URL schemes are used. In the absense of any NAPTR records containing the 'LoST-Validation' service tag, the 'LoST' service tag is used. Fallback to the 'LoST' service tag may follow if the 'Lost-Validation' service tag fails to result in a usable LoST server. The discovery procedure with the 'LoST-Validation' service tag might result in the same URL as the 'LoST' service tag, or it may result in a different URL. When the URLs are different, they could lead to the same physical servers, or different servers.
The primary use of LoST in general, and the location validation functionality in particular, is within the emergency services area. Within North America, the NENA i3 [NENA-i3] document specifies how protocols including LoST are used. The i3 document is expected to reference the 'LoST-Validation' service tag, and specify its use in both server NAPTR DNS records and client resolution of Application Unique Strings (AUS).
LoST allows a server to refuse to perform location validation, and defines the 'locationValidationUnavailable' warning. LoST also allows a server to refer to another server rather than answering itself. So, in a deployment where a LoST tree has separate server clusters for mapping and for validation, mapping servers receiving a request for validation could either perform the validation as requested, or return the 'locationValidationUnavailable' warning, and potentially also include a <redirect> element to redirect to a validation server. However, the <redirect> element contains an Application Unique String, so unless the AUSs for validation and mapping are different (e.g., 'ecrf.example.org' and 'lvf.example.org'), we still need a different service tag to allow for flexible deployment choices (i.e., not requiring a DNS name convention).
LoST clients performing emergency services operations are expected to comply with the latest NENA i3 specification, and hence support the 'LoST-Validation' service tag when defined. A LoST client implemented prior to the addition of the 'LoST-Validation' tag would use the 'LoST' tag to resolve an AUS. Such a client might not be performing location validation, but if it is, the LoST server it contacts may perform the service. Even in a deployment where mapping and validation are split, the data is identical; the split is a load and deployment optimization strategy. The server designated for mapping is likely to perform validation when requested, potentially unless it is under load. If an older client attempts validation using a designated mapping server that refuses the request, the client will retry later, at which point the server may no longer be under load and may provide the function. Even in the (unlikely) case of a designated mapping server that refuses to perform validation at any time, the server could return a redirect with a different AUS (e.g., "lvf.example.com") that resolves to a designated validation server. In the (unlikely) worst case, the client will be unable to reach a server willing to perform validation, and will submit a discrepancy report, as specified in NENA i3. The discrepancy report resolution would be to update the client with the 'LoST-Validation' service tag, update the AUS returned in a redirect and DNS to use a different DNS host name, or permit the server to perform validation when not under stress (or a combination). Note that, because LoST does not require servers to perform validation, the situation described can exist regardless of the addition of the 'LoST-Validation' service tag. The addition of the tag improves the likelihood of a client needing validation being able to do so.
The security considerations described in [RFC3958], [RFC4848], and [RFC5222] apply here. No additional security aspects are foreseen by the addition of an extra tag. Separation of services might be desired, for example, to be able to allocate different levels of resources (such as server capacity, attack mitigation, bandwidth, etc.) to the mapping and validation services, in which case separate tags are needed to allow LoST clients (which may include other LoST servers) to identify the correct server cluster.
IANA is requested to add 'LoST-Validation' to the S-NAPTR Application Service Tag registry created by [RFC3958] This tag serves as a counterpart to the 'LoST' tag added by [RFC5222].
(Note that IANA and [RFC3958] call this registry "S-NAPTR Application Service Tags" while [RFC5222] calls it "U-NAPTR application service tag".)
This document registers an S-NAPTR application service tag:
Many thanks to Ted Hardie, Ben Campbell, Dan Banks, Pete Resnick, and Shawn Emery for their helpful reviews and suggestions, and to Barry Leiba for shepherding the document.
| [RFC3958] | Daigle, L. and A. Newton, "Domain-Based Application Service Location Using SRV RRs and the Dynamic Delegation Discovery Service (DDDS)", RFC 3958, DOI 10.17487/RFC3958, January 2005. |
| [RFC4848] | Daigle, L., "Domain-Based Application Service Location Using URIs and the Dynamic Delegation Discovery Service (DDDS)", RFC 4848, DOI 10.17487/RFC4848, April 2007. |
| [RFC5222] | Hardie, T., Newton, A., Schulzrinne, H. and H. Tschofenig, "LoST: A Location-to-Service Translation Protocol", RFC 5222, DOI 10.17487/RFC5222, August 2008. |
| [NENA-i3] | National Emergency Number Association (NENA) Interconnection and Security Committee, i3 Architecture Working Group, "Detailed Functional and Interface Standards for the NENA i3 Solution", 2016. |
| [RFC5582] | Schulzrinne, H., "Location-to-URL Mapping Architecture and Framework", RFC 5582, DOI 10.17487/RFC5582, September 2009. |