idnits 2.17.1 draft-gellens-lost-validation-09.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- ** The document seems to lack a both a reference to RFC 2119 and the recommended RFC 2119 boilerplate, even if it appears to use RFC 2119 keywords. RFC 2119 keyword, line 245: '... measures SHOULD be used when perfor...' RFC 2119 keyword, line 342: '... of DNS Security [RFC4033] a SHOULD...' -- The draft header indicates that this document updates RFC5222, but the abstract doesn't seem to directly say this. It does mention RFC5222 though, so this could be OK. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year (Using the creation date from RFC5222, updated by this document, for RFC5378 checks: 2006-06-20) -- The document seems to lack a disclaimer for pre-RFC5378 work, but may have content which was first submitted before 10 November 2008. If you have contacted all the original authors and they are all willing to grant the BCP78 rights to the IETF Trust, then this is fine, and you can ignore this comment. If not, you may need to add the pre-RFC5378 disclaimer. (See the Legal Provisions document at https://trustee.ietf.org/license-info for more information.) -- The document date (July 1, 2020) is 1389 days in the past. Is this intentional? Checking references for intended status: Proposed Standard ---------------------------------------------------------------------------- (See RFCs 3967 and 4897 for information about using normative references to lower-maturity documents in RFCs) No issues found here. Summary: 1 error (**), 0 flaws (~~), 1 warning (==), 3 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Network Working Group R. Gellens 3 Internet-Draft Core Technology Consulting 4 Updates: 5222 (if approved) B. Rosen 5 Intended status: Standards Track July 1, 2020 6 Expires: January 2, 2021 8 The LoST-Validation S-NAPTR Application Service Tag 9 draft-gellens-lost-validation-09 11 Abstract 13 This document adds the "LoST-Validation" service tag to the 14 Straightforward Naming Authority PoinTeR (S-NAPTR) Application 15 Service Tag IANA registry. This tag can appear in a Naming Authority 16 Pointer (NAPTR) Domain Name System (DNS) record to assist clients of 17 the Location-to-Service Translation Protocol (LoST) in identifying 18 LoST servers explicitly willing to perform location validation. This 19 tag and the information on its use is an update to RFC5222 that 20 enables the explicit discovery of a server that supports location 21 validation. 23 Status of This Memo 25 This Internet-Draft is submitted in full conformance with the 26 provisions of BCP 78 and BCP 79. 28 Internet-Drafts are working documents of the Internet Engineering 29 Task Force (IETF). Note that other groups may also distribute 30 working documents as Internet-Drafts. The list of current Internet- 31 Drafts is at http://datatracker.ietf.org/drafts/current/. 33 Internet-Drafts are draft documents valid for a maximum of six months 34 and may be updated, replaced, or obsoleted by other documents at any 35 time. It is inappropriate to use Internet-Drafts as reference 36 material or to cite them other than as "work in progress." 38 This Internet-Draft will expire on January 2, 2021. 40 Copyright Notice 42 Copyright (c) 2020 IETF Trust and the persons identified as the 43 document authors. All rights reserved. 45 This document is subject to BCP 78 and the IETF Trust's Legal 46 Provisions Relating to IETF Documents 47 (http://trustee.ietf.org/license-info) in effect on the date of 48 publication of this document. Please review these documents 49 carefully, as they describe your rights and restrictions with respect 50 to this document. Code Components extracted from this document must 51 include Simplified BSD License text as described in Section 4.e of 52 the Trust Legal Provisions and are provided without warranty as 53 described in the Simplified BSD License. 55 Table of Contents 57 1. Document Scope . . . . . . . . . . . . . . . . . . . . . . . 2 58 2. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 59 3. The LoST-Validation Application Service Tag . . . . . . . . . 3 60 4. Backwards Compatability . . . . . . . . . . . . . . . . . . . 4 61 5. Security Considerations . . . . . . . . . . . . . . . . . . . 5 62 6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 6 63 6.1. S-NAPTR Registration . . . . . . . . . . . . . . . . . . 6 64 7. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 6 65 8. Changes from Previous Versions . . . . . . . . . . . . . . . 6 66 8.1. Changes from -00 to -01 . . . . . . . . . . . . . . . . . 6 67 8.2. Changes from -01 to -02 . . . . . . . . . . . . . . . . . 7 68 8.3. Changes from -02 to -03 . . . . . . . . . . . . . . . . . 7 69 8.4. Changes from -03 to -04 . . . . . . . . . . . . . . . . . 7 70 8.5. Changes from -04 to -05 . . . . . . . . . . . . . . . . . 7 71 8.6. Changes from -05 to -06 . . . . . . . . . . . . . . . . . 7 72 8.7. Changes from -06 to -07 . . . . . . . . . . . . . . . . . 7 73 8.8. Changes from -07 to -08 . . . . . . . . . . . . . . . . . 8 74 8.9. Changes from -08 to -09 . . . . . . . . . . . . . . . . . 8 75 9. References . . . . . . . . . . . . . . . . . . . . . . . . . 8 76 9.1. Normative References . . . . . . . . . . . . . . . . . . 8 77 9.2. Informative references . . . . . . . . . . . . . . . . . 8 78 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 9 80 1. Document Scope 82 This document adds 'LoST-Validation' to the S-NAPTR Application 83 Service Tag IANA registry, and describes how this tag fits in the 84 LoST server discovery procedure described in [RFC5222]. This tag is 85 used with Naming Authority Pointer (NAPTR) Domain Name System (DNS) 86 records so that clients of the Location-to-Service Translation 87 Protocol (LoST) [RFC5222] can identify servers explicitly willing to 88 perform location validation. This tag and the information on its use 89 is an update to [RFC5222] that enables the explicit discovery of a 90 server that supports location validation. 92 2. Introduction 94 The Location-to-Service Translation Protocol, LoST [RFC5222] defines 95 a mapping service with the additional ability for a client to request 96 that a civic address be validated. The LoST protocol allows servers 97 to ignore a request to perform location validation. The National 98 Emergency Number Association (NENA) has defined an architecture for 99 all-IP emergency services (known as "i3" [NENA-i3]), which defines 100 the mapping (routing) and validation functions as two distinct 101 functional elements, defined as an Emergency Call Routing Function 102 (ECRF) and a Location Validation Function (LVF). NENA i3 requires 103 that the mapping (ECRF) and validation (LVF) functions be separable, 104 so that an entity responsible for a LoST server cluster can decide to 105 provide mapping and validation services using consolidated or 106 separate server clusters (i.e., using the same or separate boxes). 107 The rationale is that the mapping service is used in real-time during 108 emergency call routing, while the validation service is used in 109 advance, typically when data is provisioned, and therefore the 110 mapping service has much higher availability and response time 111 requirements than the validation service. An organization might 112 choose to deploy these services using different server clusters to 113 make it easier to provide higher levels of service for the mapping 114 function while shielding it from the potentially bursty load of 115 validation, while another organization might choose to use the same 116 sets of servers for both, configured and deployed to offer the high 117 service level demanded of the mapping service. 119 In order to permit this separability, any entity querying a LoST 120 server needs to be able to resolve an Application Unique String (AUS) 121 into a URL for a LoST server that offers the required service 122 (mapping or validation). This separability needs to be maintained 123 throughout the LoST tree structure, from forest guide to leaf node 124 (LoST architecture is described in [RFC5582]). Because LoST 125 referrals return an AUS rather than a URL, either a different Service 126 Tag or a DNS name convention (e.g., "ecrf.example.org" and 127 "lvf.example.org") is needed to differentiate the different services. 128 DNS name conventions are inflexible and fragile, making a different 129 service tag the preferred approach. 131 Because a server discovered using the "LoST" application service tag 132 may ignore a request to perform location validation, a service tag 133 explicitly for location validation also reduces the likelihood (which 134 has existed since [RFC5582]) of a client requiring location 135 validation reaching servers unwilling to do so. 137 3. The LoST-Validation Application Service Tag 139 This document adds 'LoST-Validation' to the S-NAPTR Application 140 Service Tag registry created by [RFC3958]. The 'LoST-Validation' tag 141 serves as a counterpart to the 'LoST' tag added by [RFC5222]: The 142 'LoST' tag identifies servers able to perform the core mapping 143 function, while 'LoST-Validation' identifies servers explicitly 144 willing to perform the validation function. 146 Because some servers might be configured to provide both mapping and 147 validation functions, a server identified using the 'LoST' service 148 tag might also perform the validation function (and resolving the two 149 tags might result in the same URL). Because the two functions might 150 be separate, clients seeking a LoST server for location validation 151 can first try U-NAPTR resolution using the 'Lost-Validation' service 152 tag, and fallback to the 'LoST' service tag if this does not resolve 153 to a usable LoST server. 155 LoST [RFC5222] specifies that LoST servers are located by resolving 156 an application Unique String (AUS) using U-NAPTR/DDDS (URI-Enabled 157 NAPTR/Dynamic Delegation Discovery Service) [RFC4848], and defines 158 the 'LoST' Application service tag. In order to permit separability 159 of the mapping and validation services performed using LoST, and to 160 reduce the likelihood of a client requiring location validation 161 reaching servers unwilling to do so, this document defines the 'LoST- 162 Validation' service tag. NAPTR records for LoST servers available 163 for location validation contain the 'LoST-Validation' service tag. 164 An entity needing to perform location validation using LoST performs 165 the discovery procedure as described in [RFC5222], except that the 166 'LoST-Validation' service tag is used in preference to the 'LoST' 167 service tag. For both service tags, the HTTP and HTTPS URL schemes 168 are used. In the absense of any NAPTR records containing the 'LoST- 169 Validation' service tag, the 'LoST' service tag is used. Fallback to 170 the 'LoST' service tag may follow if the 'Lost-Validation' service 171 tag fails to result in a usable LoST server. The discovery procedure 172 with the 'LoST-Validation' service tag might result in the same URL 173 as the 'LoST' service tag, or it may result in a different URL. When 174 the URLs are different, they could lead to the same physical servers, 175 or different servers. 177 4. Backwards Compatability 179 The primary use of LoST in general, and the location validation 180 functionality in particular, is within the emergency services area. 181 Within North America, the NENA i3 [NENA-i3] document specifies how 182 protocols including LoST are used. The i3 document is expected to 183 reference the 'LoST-Validation' service tag, and specify its use in 184 both server NAPTR DNS records and client resolution of Application 185 Unique Strings (AUS). 187 LoST allows a server to refuse to perform location validation, and 188 defines the 'locationValidationUnavailable' warning. LoST also 189 allows a server to refer to another server rather than answering 190 itself. So, in a deployment where a LoST tree has separate server 191 clusters for mapping and for validation, mapping servers receiving a 192 request for validation could either perform the validation as 193 requested, or return the 'locationValidationUnavailable' warning, and 194 potentially also include a element to redirect to a 195 validation server. However, the element contains an 196 Application Unique String, so unless the AUSs for validation and 197 mapping are different (e.g., 'ecrf.example.org' and 198 'lvf.example.org'), we still need a different service tag to allow 199 for flexible deployment choices (i.e., not requiring a DNS name 200 convention). 202 LoST clients performing emergency services operations are expected to 203 comply with the latest NENA i3 specification, and hence support the 204 'LoST-Validation' service tag when defined. A LoST client 205 implemented prior to the addition of the 'LoST-Validation' tag would 206 use the 'LoST' tag to resolve an AUS. Such a client might not be 207 performing location validation, but if it is, the LoST server it 208 contacts may perform the service. Even in a deployment where mapping 209 and validation are split, the data is identical; the split is a load 210 and deployment optimization strategy. The server designated for 211 mapping is likely to perform validation when requested, potentially 212 unless it is under load. If an older client attempts validation 213 using a designated mapping server that refuses the request, the 214 client will retry later, at which point the server may no longer be 215 under load and may provide the function. Even in the (unlikely) case 216 of a designated mapping server that refuses to perform validation at 217 any time, the server could return a redirect with a different AUS 218 (e.g., "lvf.example.com") that resolves to a designated validation 219 server. In the (unlikely) worst case, the client will be unable to 220 reach a server willing to perform validation, and will submit a 221 discrepancy report, as specified in NENA i3. The discrepancy report 222 resolution would be to update the client with the 'LoST-Validation' 223 service tag, update the AUS returned in a redirect and DNS to use a 224 different DNS host name, or permit the server to perform validation 225 when not under stress (or a combination). Note that, because LoST 226 does not require servers to perform validation, the situation 227 described can exist regardless of the addition of the 'LoST- 228 Validation' service tag. The addition of the tag improves the 229 likelihood of a client needing validation being able to do so. 231 5. Security Considerations 233 The security considerations described in [RFC3958], [RFC4848], and 234 [RFC5222] apply here. No additional security aspects are foreseen by 235 the addition of an extra tag. Separation of services might be 236 desired, for example, to be able to allocate different levels of 237 resources (such as server capacity, attack mitigation, bandwidth, 238 etc.) to the mapping and validation services, in which case separate 239 tags are needed to allow LoST clients (which may include other LoST 240 servers) to identify the correct server cluster. 242 [RFC5222] descriptively discusses the use of DNS Security [RFC4033] 243 to mitigate the risk of DNS-based attacks. Because DNS Security has 244 become more widely deployed since the publication of [RFC5222], such 245 measures SHOULD be used when performing NAPTR resolution. Note that, 246 while there are valid reasons to proceed with a LoST mapping query 247 despite security failures while initiating or processing an emergency 248 call, these concerns generally do not apply to a loST validation 249 query done in advance of an emergency call. 251 6. IANA Considerations 253 IANA is requested to add 'LoST-Validation' to the S-NAPTR Application 254 Service Tag registry created by [RFC3958] This tag serves as a 255 counterpart to the 'LoST' tag added by [RFC5222]. 257 (Note that IANA and [RFC3958] call this registry "S-NAPTR Application 258 Service Tags" while [RFC5222] calls it "U-NAPTR application service 259 tag".) 261 6.1. S-NAPTR Registration 263 This document registers an S-NAPTR application service tag: 265 Application Service Tag: LoST-Validation 267 Defining Publication: This document. 269 7. Acknowledgements 271 Many thanks to Ted Hardie, Ben Campbell, Dan Banks, Pete Resnick, 272 Shawn Emery, Robert Wilton, Roman Danyliw, and Benjamin Kaduk for 273 their helpful reviews and suggestions, and to Barry Leiba for 274 shepherding the document. 276 8. Changes from Previous Versions 278 8.1. Changes from -00 to -01 280 o Fixed incorrect tag in Section 6 282 o Clarified background and explanation in Section 2 284 o Clarified text in Section 3 286 o Expanded text in Section 5 288 8.2. Changes from -01 to -02 290 o Fixed bug in .xml file 292 8.3. Changes from -02 to -03 294 o Reworded fallback text in Section 2 296 8.4. Changes from -03 to -04 298 o Fixed some references to [RFC4848] that should be to [RFC5222] in 299 sections Section 2 and Section 3 301 o Added clarifying text in Abstract 303 o Copied text from Abstract to Section 1 305 o Added clarifying text in Section 2 307 8.5. Changes from -04 to -05 309 o Added reference to [RFC5222] in Section 5 311 o Added clarifying text to Section 2 313 o Moved some text from Section 2 to Section 3 315 o Added new section Section 4 317 8.6. Changes from -05 to -06 319 o Changed intended status from Informational to Standards Track 321 o Added indication that the document (if approved) updates RFC 5222 323 o Added text to Abstract, Document Scope (Section 1), and 324 Introduction (Section 2) to better explain document purpose. 326 o Added Informational reference to [RFC5582] 328 o Minor wording improvements in multiple sections 330 8.7. Changes from -06 to -07 332 o Minor editorial changes to Introduction (Section 2) 334 8.8. Changes from -07 to -08 336 o Added text in Abstract and Document Scope (Section 1) clarifying 337 the updates to [RFC5582] 339 8.9. Changes from -08 to -09 341 o Added text in Security Considerations (Section 5) making the use 342 of DNS Security [RFC4033] a SHOULD 344 9. References 346 9.1. Normative References 348 [RFC3958] Daigle, L. and A. Newton, "Domain-Based Application 349 Service Location Using SRV RRs and the Dynamic Delegation 350 Discovery Service (DDDS)", RFC 3958, DOI 10.17487/RFC3958, 351 January 2005, . 353 [RFC4033] Arends, R., Austein, R., Larson, M., Massey, D., and S. 354 Rose, "DNS Security Introduction and Requirements", 355 RFC 4033, DOI 10.17487/RFC4033, March 2005, 356 . 358 [RFC4848] Daigle, L., "Domain-Based Application Service Location 359 Using URIs and the Dynamic Delegation Discovery Service 360 (DDDS)", RFC 4848, DOI 10.17487/RFC4848, April 2007, 361 . 363 [RFC5222] Hardie, T., Newton, A., Schulzrinne, H., and H. 364 Tschofenig, "LoST: A Location-to-Service Translation 365 Protocol", RFC 5222, DOI 10.17487/RFC5222, August 2008, 366 . 368 9.2. Informative references 370 [NENA-i3] National Emergency Number Association (NENA) 371 Interconnection and Security Committee, i3 Architecture 372 Working Group, , "Detailed Functional and Interface 373 Standards for the NENA i3 Solution", 2016, 374 . 376 [RFC5582] Schulzrinne, H., "Location-to-URL Mapping Architecture and 377 Framework", RFC 5582, DOI 10.17487/RFC5582, September 378 2009, . 380 Authors' Addresses 382 Randall Gellens 383 Core Technology Consulting 384 US 386 Email: rg+ietf@coretechnologyconsulting.com 387 URI: http://www.coretechnologyconsulting.com 389 Brian Rosen 390 470 Conrad Dr 391 Mars, PA 16046 392 US 394 Email: br@brianrosen.net