The LoST-Validation Straightforward-Naming Authority PoinTeR (S-NAPTR) Application Service Tag
updates
- rfc-5222 — LoST: A Location-to-Service Translation Protocol
Extracted elements (11)
A distinct service tag ('LoST-Validation') is preferred over a DNS naming convention (e.g., 'ecrf.example.org' vs 'lvf.example.org') because DNS name conventions are inflexible and fragile, and because LoST referrals return an AUS rather than a URL, requiring a mechanism that works throughout the full LoST tree structure.
The NENA i3 architecture requires the mapping (ECRF) and validation (LVF) functions to be separable because the mapping service is used in real time during emergency call routing with high availability requirements, while validation is used in advance during data provisioning and can tolerate lower availability. A separate tag allows operators to deploy these on independent server clusters.
Using a dedicated 'LoST-Validation' tag reduces the likelihood that a client needing location validation reaches servers that are not performing validation due to configuration or load conditions, a risk that has existed since RFC 5582.
A LoST client implemented prior to the 'LoST-Validation' tag will use the 'LoST' tag to resolve an AUS. If the contacted mapping server refuses validation, the client retries later, or the server may return a redirect with a different AUS pointing to a designated validation server.
Because some servers may be configured to provide both mapping and validation, a server identified by the 'LoST' tag might also perform validation; resolving both tags could yield the same URL. When URLs differ, they may point to the same or different physical servers.
In the absence of any NAPTR records containing the 'LoST-Validation' service tag, the 'LoST' service tag is used. Clients may also fall back to 'LoST' if 'LoST-Validation' fails to resolve to a usable LoST server.
When performing NAPTR resolution for LoST validation discovery, DNS security (DNSSEC, per RFC 4033) SHOULD be used to mitigate the risk of DNS-based attacks.
The 'LoST-Validation' service tag is used in NAPTR DNS records to identify LoST servers designated for location validation. Clients perform the same U-NAPTR/DDDS discovery procedure as described in RFC 5222, but substituting 'LoST-Validation' for 'LoST' as the service tag; both HTTP and HTTPS URL schemes are used.
This document registers the 'LoST-Validation' application service tag in the IANA 'S-NAPTR Application Service Tags' registry created by RFC 3958. It serves as a counterpart to the 'LoST' tag added by RFC 5222, enabling explicit discovery of servers designated for location validation.
Security considerations from RFC 3958, RFC 4848, and RFC 5222 all apply. No additional security concerns are introduced by adding the new tag. Separation of services via distinct tags allows allocation of different resource levels (server capacity, attack mitigation, bandwidth) to mapping vs. validation services.
While valid reasons exist to proceed with a LoST mapping query despite DNSSEC failures during emergency call routing, these concerns generally do not apply to a LoST validation query made in advance; therefore DNSSEC protection is more uniformly applicable to the validation path.