RFC 8917

The LoST-Validation Straightforward-Naming Authority PoinTeR (S-NAPTR) Application Service Tag

📅 published October 2020, from ietf

📜 RFC 8917: The LoST-Validation Straightforward-Naming Authority PoinTeR (S-NAPTR) Application Service Tag 🎀

okay bestie, this one is RFC 8917 and it's a Standards Track doc from the Internet Engineering Task Force (IETF), so it's an actual official spec and not just vibes 💅. It was written by R. Gellens (Core Technology Consulting) and B. Rosen, and it's dated October 2020. The ISSN is 2070-1721 🧚.

The big plot twist is that it updates RFC 5222 🔥. It doesn't obsolete anything, since there's no Obsoletes line in the title block. So this doc is basically adding a new little tag to an existing protocol and saying "hey, this is how the old thing works now too" 💖.

Abstract ✨

okay so this doc adds the 'LoST-Validation' tag to the Straightforward-Naming Authority PoinTeR (S-NAPTR) Application Service Tag IANA registry 🎀. This tag can show up in a Naming Authority Pointer (NAPTR) Domain Name System (DNS) record to help clients of the Location-to-Service Translation (LoST) Protocol find LoST servers that are designated for location validation 🗺️. The tag and the info about using it updates RFC 5222, which lets a client explicitly discover a server that supports location validation 💅.

Status of This Memo 📋

this is an Internet Standards Track document 🌸.

it's a product of the Internet Engineering Task Force (IETF), so it represents the consensus of the IETF community 🫶. It got public review and was approved for publication by the Internet Engineering Steering Group (IESG) 👑. If you want more info on Internet Standards, check Section 2 of RFC 7841 🍓.

for the current status, any errata, and how to send feedback on this doc, go to https://www.rfc-editor.org/info/rfc8917 🦋.

Copyright (c) 2020 IETF Trust and the persons identified as the document authors. All rights reserved ✨.

this doc is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (https://trustee.ietf.org/license-info), as they're in effect on the date of publication 📜. Please actually read these, bestie, because they explain your rights and restrictions for this doc 🙈. Code Components pulled out of this doc have to include the Simplified BSD License text, as described in Section 4.e of the Trust Legal Provisions, and they come without warranty, as the Simplified BSD License describes 💀.

Table of Contents 🧚

1.  Document Scope
2.  Introduction
  2.1.  Requirements Language
3.  The LoST-Validation Application Service Tag
4.  Backwards Compatibility
5.  Security Considerations
6.  IANA Considerations
  6.1.  S-NAPTR Registration
7.  References
  7.1.  Normative References
  7.2.  Informative References
Acknowledgements
Authors' Addresses

1. Document Scope 🦋

okay so this doc adds 'LoST-Validation' to the S-NAPTR Application Service Tag IANA registry 🎀, and it explains how this tag fits into the LoST server discovery procedure from [RFC5222] 💅. The tag goes into NAPTR DNS records so that clients of the Location-to-Service Translation (LoST) Protocol [RFC5222] can find servers that are designated for location validation ✨. The tag and how it's used is an update to [RFC5222], and it's what lets you explicitly discover a server that supports location validation 🌸.

2. Introduction 💖

the LoST Protocol [RFC5222] is a mapping service that also lets a client ask for a civic address to be validated 🗺️. The LoST protocol lets servers ignore a request to do location validation, which is a whole thing 🙈.

the National Emergency Number Association (NENA) came up with an architecture for all-IP emergency services, known as "i3" [NENA-i3] 🚨. In that architecture, mapping (routing) and validation are two separate functional elements: an Emergency Call Routing Function (ECRF) and a Location Validation Function (LVF) 🧚. NENA i3 requires the mapping (ECRF) and validation (LVF) functions to be separable 🔥. An entity running a LoST server cluster can decide to offer mapping and validation using consolidated or separate server clusters, meaning the same boxes or different boxes 🍓.

here's the reason it matters. Mapping is used in real time during emergency call routing, but validation is used in advance, usually when data gets provisioned 💅. So mapping has way higher availability and response-time requirements than validation 👑. An organization might run these on different clusters so it's easier to give mapping the high level of service it needs while shielding it from the potentially bursty load of validation 🌸. Another organization might use the same servers for both, set up and deployed to hit the high service level that mapping demands 💜.

so to keep that separability, any entity querying a LoST server has to be able to resolve an Application Unique String (AUS) into a URL for a LoST server designated for the required service, which is either mapping or validation ✨. This separability has to stay intact through the whole LoST tree structure, from forest guide all the way down to leaf node (the LoST architecture is described in [RFC5582]) 🦋. Because LoST referrals return an AUS and not a URL, you need either a different service tag or a DNS name convention to tell the services apart, like "ecrf.example.org" and "lvf.example.org" 🎀. DNS name conventions are inflexible and fragile, so a different service tag is the preferred approach 🙅‍♀️.

also, since LoST servers can ignore a validation request, a service tag made just for location validation cuts down the chance that a client who needs validation ends up at servers that aren't doing it (because of configuration and/or conditions). That chance has been there since [RFC5582] 🫶.

2.1. Requirements Language 📏

the key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and "OPTIONAL" in this doc are to be read as described in BCP 14 [RFC2119] [RFC8174], but only when they show up in all capitals, exactly as shown here 💅.

3. The LoST-Validation Application Service Tag 🌈

this doc adds 'LoST-Validation' to the "S-NAPTR Application Service Tags" registry that [RFC3958] created 🎀. The 'LoST-Validation' tag is the counterpart to the 'LoST' tag that [RFC5222] added: 'LoST' finds servers that can do the core mapping function, while 'LoST-Validation' finds servers set aside for the validation function ✨.

because some servers might be set up to do both mapping and validation, a server found through the 'LoST' tag might also do validation (and resolving the two tags might give the same URL) 🦋. But since the two functions might be separate, a client looking for a LoST server for location validation can first try a URI-Enabled NAPTR (U-NAPTR) resolution with the 'LoST-Validation' tag, then fall back to the 'LoST' tag if that doesn't resolve to a usable LoST server 🔥.

LoST [RFC5222] says LoST servers get located by resolving an AUS with U-NAPTR/DDDS (URI-Enabled NAPTR / Dynamic Delegation Discovery Service) [RFC4848], and it defines the 'LoST' application service tag 🧚. To keep mapping and validation separable in LoST, this doc defines the 'LoST-Validation' service tag 💖. The tag also cuts down the chance that a client who needs location validation reaches servers that aren't doing validation (because of configuration and/or conditions) 🙈. NAPTR records for LoST servers available for location validation contain the 'LoST-Validation' service tag 🌸.

an entity that needs to do location validation with LoST follows the discovery procedure from [RFC5222], except it uses the 'LoST-Validation' tag instead of the 'LoST' tag 💅. The HTTP and HTTPS URL schemes are used for both service tags 🍓. If there are no NAPTR records with the 'LoST-Validation' tag, the 'LoST' tag is used 👑. Falling back to the 'LoST' tag can happen if the 'LoST-Validation' tag doesn't end up with a usable LoST server ✨. The discovery procedure with the 'LoST-Validation' tag might give the same URL as the 'LoST' tag, or it might give a different one 🦋. When the URLs are different, they could lead to the same physical servers, or to different servers 🫶.

4. Backwards Compatibility ✨

Okay bestie, the main job of LoST, and especially the location validation part, is emergency services 🚨. In North America, the NENA i3 document [NENA-i3] spells out how protocols like LoST get used. The i3 doc is expected to reference the 'LoST-Validation' service tag and say how it gets used in both server NAPTR DNS records and client resolution of AUS. 💅

LoST lets a server say no to location validation and defines the 'locationValidationUnavailable' warning. It can also send a client to a different server instead of answering itself. So say a LoST tree has separate server clusters for mapping and validation. A mapping server that gets a validation request can either do the validation or return the 'locationValidationUnavailable' warning, and it might also include a <redirect> element pointing to a validation server. BUT, the <redirect> element carries 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 separate service tag. That keeps deployment flexible so nobody has to follow a DNS naming convention. 🎀

LoST clients doing emergency services work in North America are expected to follow the NENA i3 spec, which means they support the 'LoST-Validation' service tag once it's defined. A LoST client built before the 'LoST-Validation' tag existed would use the 'LoST' tag to resolve an AUS. That client might not be doing location validation at all, but if it is, the LoST server it contacts may still perform it. Even when mapping and validation are split, the data is identical. The split is just a load and deployment optimization. 🦋

Servers designated for mapping might still perform validation when asked, possibly depending on load or other factors. If an older client tries validation with a designated mapping server that refuses, the client will retry later, and by then the server might be able to help (e.g., if its load or other conditions have changed). Even if a designated mapping server refuses to validate at any time, it 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 can't reach a server that's willing to validate, so it follows up (e.g., by submitting a discrepancy report as specified in NENA i3). Fixing this might mean updating the client with the 'LoST-Validation' service tag, updating the AUS returned in a redirect and in DNS to use a different DNS host name, or letting the server validate when it's not under stress (or some combo of these). 😭

Note that LoST doesn't require servers to perform validation, so this situation can happen whether or not the 'LoST-Validation' service tag exists. Using the tag just makes it more likely that a client can validate a location when it really needs to. 💜

5. Security Considerations 🔐

Hold onto your hats, because this part is serious. The security considerations described in [RFC3958], [RFC4848], and [RFC5222] apply here. Adding an extra tag doesn't bring any new security aspects into the picture. Separating the services might be desired, for example, so that different levels of resources (such as server capacity, attack mitigation, bandwidth, etc.) can be given to the mapping and validation services. In that case, separate tags are needed so LoST clients (which may include other LoST servers) can find the correct server cluster. 🚨

[RFC5222] talks about how DNS security [RFC4033] can help reduce the risk of DNS-based attacks. DNS security is now much more widely deployed than it was when [RFC5222] was published, so such measures SHOULD be used when doing NAPTR resolution. ⚠️ Also, while there are valid reasons to go ahead with a LoST mapping query even when security checks fail while starting or handling an emergency call, those concerns generally don't apply to a LoST validation query made before an emergency call happens. 🙏

6. IANA Considerations 📋

IANA has added 'LoST-Validation' to the "S-NAPTR Application Service Tags" registry created by [RFC3958]. This tag is the 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".) 🙈

6.1. S-NAPTR Registration

This document registers an S-NAPTR application service tag:

Application Service Tag:  LoST-Validation

Defining Publication:  This document

7. References 📚

7.1. Normative References

[RFC2119]  Bradner, S., "Key words for use in RFCs to Indicate
           Requirement Levels", BCP 14, RFC 2119,
           DOI 10.17487/RFC2119, March 1997,
           <https://www.rfc-editor.org/info/rfc2119>.

[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, <https://www.rfc-editor.org/info/rfc3958>.

[RFC4033]  Arends, R., Austein, R., Larson, M., Massey, D., and S.
           Rose, "DNS Security Introduction and Requirements",
           RFC 4033, DOI 10.17487/RFC4033, March 2005,
           <https://www.rfc-editor.org/info/rfc4033>.

[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,
           <https://www.rfc-editor.org/info/rfc4848>.

[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,
           <https://www.rfc-editor.org/info/rfc5222>.

[RFC8174]  Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC
           2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174,
           May 2017, <https://www.rfc-editor.org/info/rfc8174>.

7.2. Informative References

[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,
           <https://www.nena.org/page/i3_Stage3>.

[RFC5582]  Schulzrinne, H., "Location-to-URL Mapping Architecture and
           Framework", RFC 5582, DOI 10.17487/RFC5582, September
           2009, <https://www.rfc-editor.org/info/rfc5582>.

Acknowledgements 🫶

Many thanks to Ted Hardie, Ben Campbell, Dan Banks, Pete Resnick, Shawn Emery, Robert Wilton, Roman Danyliw, and Benjamin Kaduk for their helpful reviews and suggestions, and to Barry Leiba for shepherding the document. 🌸

Authors' Addresses 📮

Randall Gellens
Core Technology Consulting
United States of America

Email: rg+ietf@coretechnologyconsulting.com
URI:   http://www.coretechnologyconsulting.com


Brian Rosen
470 Conrad Dr.
Mars, PA 16046
United States of America

Email: br@brianrosen.net
📦 where this page comes from