The LoST-Validation Straightforward-Naming
Authority PoinTeR (S-NAPTR) Application Service Tag
Core Technology Consulting
United States of America
rg+ietf@coretechnologyconsulting.com
http://www.coretechnologyconsulting.com
470 Conrad Dr.
Mars
PA
16046
United States of America
br@brianrosen.net
Real-Time Applications and Infrastructure
location
LoST
emergency
emergency services
ecrf
lvf
i3
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 (LoST) Protocol in identifying LoST
servers designated for location validation. This tag and
the information about its use update RFC 5222, which enables the explicit discovery of a server that supports location validation.
Document Scope
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 . This tag is used with Naming Authority Pointer
(NAPTR) Domain Name System (DNS) records so that clients of the
Location-to-Service Translation (LoST) Protocol can identify servers designated for location validation. This tag and the information on its use is an update to that enables the explicit discovery of a server that supports location validation.
Introduction
The LoST Protocol 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" ), 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; 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; 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. Another organization might choose to use the same
sets of servers for both services, 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 designated for 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 ). 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 between the services. DNS name conventions are inflexible and fragile, making a different service tag the preferred approach.
Because LoST servers may ignore a request to perform location
validation, a service tag explicitly for location validation also
reduces the likelihood (which has existed since ) that a client needing location validation will reach servers that are not doing so
(due to configuration and/or conditions).
The key words "MUST", "MUST NOT",
"REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT",
"RECOMMENDED", "NOT RECOMMENDED",
"MAY", and "OPTIONAL" in this document are to be
interpreted as described in BCP 14 when, and only when, they appear in all capitals, as
shown here.
The LoST-Validation Application Service Tag
This document adds 'LoST-Validation' to the "S-NAPTR Application
Service Tags" registry created by . The 'LoST-Validation' tag serves as a counterpart
to the 'LoST' tag added by :
the 'LoST' tag identifies servers able to perform the core mapping
function, while 'LoST-Validation' identifies servers designated for 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 a URI-Enabled NAPTR (U-NAPTR) resolution using the
'LoST-Validation' service tag and can fall back to the 'LoST' service tag if this does not resolve to a usable LoST server.
LoST specifies that LoST
servers are located by resolving an AUS using U-NAPTR/DDDS (URI-Enabled
NAPTR / Dynamic Delegation Discovery Service) and defines the 'LoST' application service tag. In
order to permit separability of the mapping and validation services
performed using LoST, this document defines the 'LoST-Validation'
service tag. This tag also reduces the likelihood that a client needing
location validation might reach servers that are not performing validation (due to
configuration and/or conditions). 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 , 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 absence 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.
Backwards Compatibility
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 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 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 AUS, 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 in North
America are expected to
comply with the 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. Servers designated for mapping might perform validation when
requested (potentially depending on load or other factors). 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 might provide the function (e.g., if its load or other conditions
have changed). Even
in the 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 worst case, the client will be
unable to reach a server willing to perform validation and will follow
up (e.g., submit a discrepancy report as specified in NENA i3). The
resolution may 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. Use of
the tag improves the likelihood that a client is able to validate a
location when needed.
Security Considerations
The security considerations described in , , and 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.
descriptively discusses the
use of DNS security to
mitigate the risk of DNS-based attacks. Because DNS security has become
more widely deployed since the publication of , such measures SHOULD be used when
performing NAPTR resolution. Note that, while there are valid reasons
to proceed with a LoST mapping query despite security failures while
initiating or processing an emergency call, these concerns generally do
not apply to a LoST validation query done in advance of an emergency
call.
IANA Considerations
IANA has added 'LoST-Validation' to the "S-NAPTR Application Service
Tags" registry created by .
This tag serves as a counterpart to the 'LoST' tag added by .
(Note that IANA and call this registry "S-NAPTR Application Service Tags", while calls it "U-NAPTR application service tag".)
S-NAPTR Registration
This document registers an S-NAPTR application service tag:
- Application Service Tag:
- LoST-Validation
- Defining Publication:
- This document
References
Normative References
Informative References
Detailed Functional and Interface Standards for the NENA i3 Solution
Acknowledgements
Many thanks to , , , , , , , and for their helpful reviews and suggestions and to for shepherding the document.