idnits 2.17.1 draft-ietf-opsawg-mud-iot-dns-considerations-02.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 an IANA Considerations section. (See Section 2.2 of https://www.ietf.org/id-info/checklist for how to handle the case when there are no actions for IANA.) == There are 1 instance of lines with non-RFC2606-compliant FQDNs in the document. == There are 1 instance of lines with non-RFC6890-compliant IPv4 addresses in the document. If these are example addresses, they should be changed. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year -- The document date (11 July 2021) is 1019 days in the past. Is this intentional? Checking references for intended status: Best Current Practice ---------------------------------------------------------------------------- (See RFCs 3967 and 4897 for information about using normative references to lower-maturity documents in RFCs) == Unused Reference: 'RFC6146' is defined on line 596, but no explicit reference was found in the text -- Possible downref: Non-RFC (?) normative reference: ref. 'Akamai' -- Possible downref: Non-RFC (?) normative reference: ref. 'AmazonS3' -- Possible downref: Normative reference to a draft: ref. 'I-D.ietf-dnsop-terminology-ter' ** Downref: Normative reference to an Informational draft: draft-ietf-suit-architecture (ref. 'I-D.ietf-suit-architecture') -- Possible downref: Normative reference to a draft: ref. 'I-D.peterson-doh-dhcp' ** Downref: Normative reference to an Informational RFC: RFC 1794 ** Downref: Normative reference to an Experimental RFC: RFC 8094 ** Obsolete normative reference: RFC 8499 (Obsoleted by RFC 9499) == Outdated reference: A later version (-11) exists of draft-pauly-dprive-oblivious-doh-06 == Outdated reference: A later version (-07) exists of draft-richardson-mud-qrcode-00 Summary: 5 errors (**), 0 flaws (~~), 6 warnings (==), 5 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 OPSAWG Working Group M. Richardson 3 Internet-Draft Sandelman Software Works 4 Intended status: Best Current Practice W. Pan 5 Expires: 12 January 2022 Huawei Technologies 6 11 July 2021 8 Operational Considerations for use of DNS in IoT devices 9 draft-ietf-opsawg-mud-iot-dns-considerations-02 11 Abstract 13 This document details concerns about how Internet of Things devices 14 use IP addresses and DNS names. The issue becomes acute as network 15 operators begin deploying RFC8520 Manufacturer Usage Description 16 (MUD) definitions to control device access. 18 This document explains the problem through a series of examples of 19 what can go wrong, and then provides some advice on how a device 20 manufacturer can best make deal with these issues. The 21 recommendations have an impact upon device and network protocol 22 design. 24 {RFC-EDITOR, please remove. Markdown and issue tracker for this 25 document is at https://github.com/mcr/iot-mud-dns-considerations.git 26 } 28 Status of This Memo 30 This Internet-Draft is submitted in full conformance with the 31 provisions of BCP 78 and BCP 79. 33 Internet-Drafts are working documents of the Internet Engineering 34 Task Force (IETF). Note that other groups may also distribute 35 working documents as Internet-Drafts. The list of current Internet- 36 Drafts is at https://datatracker.ietf.org/drafts/current/. 38 Internet-Drafts are draft documents valid for a maximum of six months 39 and may be updated, replaced, or obsoleted by other documents at any 40 time. It is inappropriate to use Internet-Drafts as reference 41 material or to cite them other than as "work in progress." 43 This Internet-Draft will expire on 12 January 2022. 45 Copyright Notice 47 Copyright (c) 2021 IETF Trust and the persons identified as the 48 document authors. All rights reserved. 50 This document is subject to BCP 78 and the IETF Trust's Legal 51 Provisions Relating to IETF Documents (https://trustee.ietf.org/ 52 license-info) in effect on the date of publication of this document. 53 Please review these documents carefully, as they describe your rights 54 and restrictions with respect to this document. Code Components 55 extracted from this document must include Simplified BSD License text 56 as described in Section 4.e of the Trust Legal Provisions and are 57 provided without warranty as described in the Simplified BSD License. 59 Table of Contents 61 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 62 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 4 63 3. Strategies to map names . . . . . . . . . . . . . . . . . . . 4 64 4. DNS and IP Anti-Patterns for IoT device Manufacturers . . . . 6 65 4.1. Use of IP address literals in-protocol . . . . . . . . . 6 66 4.2. Use of non-deterministic DNS names in-protocol . . . . . 7 67 4.3. Use of a too inclusive DNS name . . . . . . . . . . . . . 8 68 5. DNS privacy and outsourcing versus MUD controllers . . . . . 8 69 6. Recommendations to IoT device manufacturer on MUD and DNS 70 usage . . . . . . . . . . . . . . . . . . . . . . . . . . 9 71 6.1. Consistently use DNS . . . . . . . . . . . . . . . . . . 9 72 6.2. Use primary DNS names controlled by the manufacturer . . 9 73 6.3. Use Content-Distribution Network with stable names . . . 10 74 6.4. Do not use geofenced names . . . . . . . . . . . . . . . 10 75 6.5. Prefer DNS servers learnt from DHCP/Route 76 Advertisements . . . . . . . . . . . . . . . . . . . . . 10 77 7. Privacy Considerations . . . . . . . . . . . . . . . . . . . 11 78 8. Security Considerations . . . . . . . . . . . . . . . . . . . 12 79 9. References . . . . . . . . . . . . . . . . . . . . . . . . . 12 80 9.1. Normative References . . . . . . . . . . . . . . . . . . 12 81 9.2. Informative References . . . . . . . . . . . . . . . . . 14 82 Appendix A. Appendices . . . . . . . . . . . . . . . . . . . . . 15 83 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 15 85 1. Introduction 87 [RFC8520] provides a standardized way to describe how a specific 88 purpose device makes use of Internet resources. Access Control Lists 89 (ACLs) can be defined in an RFC8520 Manufacturer Usage Description 90 (MUD) file that permit a device to access Internet resources by DNS 91 name. 93 Use of a DNS name rather than IP address in the ACL has many 94 advantages: not only does the layer of indirection permit the mapping 95 of name to IP address to be changed over time, it also generalizes 96 automatically to IPv4 and IPv6 addresses, as well as permitting 97 loading balancing of traffic by many different common ways, including 98 geography. 100 At the MUD policy enforcement point - the firewall - there is a 101 problem. The firewall has only access to the layer-3 headers of the 102 packet. This includes the source and destination IP address, and if 103 not encrypted by IPsec, the destination UDP or TCP port number 104 present in the transport header. The DNS name is not present! 106 It has been suggested that one answer to this problem is to provide a 107 forced intermediate for the TLS connections. This could in theory be 108 done for TLS 1.2 connections. The MUD policy enforcement point could 109 observe the Server Name Identifier (SNI) [RFC6066]. Some Enterprises 110 do this already. But, as this involves active termination of the TCP 111 connection (a forced circuit proxy) in order to see enough of the 112 traffic, it requires significant effort. But, TLS 1.3 provides 113 options to encrypt the SNI as the ESNI, which renders the practice 114 useless in the end. 116 So in order to implement these name based ACLs, there must be a 117 mapping between the names in the ACLs and layer-3 IP addresses. The 118 first section of this document details a few strategies that are 119 used. 121 The second section of this document details how common manufacturer 122 anti-patterns get in the way this mapping. 124 The third section of this document details how current trends in DNS 125 presolution such as public DNS servers, DNS over TLS (DoT), and DNS 126 over HTTPS (DoH) cause problems for the strategies employed. Poor 127 interactions with content-distribution networks is a frequent 128 pathology that can result. 130 The fourth section of this document makes a series of recommendations 131 ("best current practices") for manufacturers on how to use DNS, and 132 IP addresses with specific purpose IoT devices. 134 The Privacy Considerations section concerns itself with issues that 135 DNS-over-TLS and DNS-over-HTTPS are frequently used to deal with. 136 How these concerns apply to IoT devices located within a residence or 137 enterprise is a key concern. 139 The Security Considerations section covers some of the negative 140 outcomes should MUD/firewall managers and IoT manufacturers choose 141 not to cooperate. 143 2. Terminology 145 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 146 "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and 147 "OPTIONAL" in this document are to be interpreted as described in 148 BCP 14 [RFC2119] [RFC8174] when, and only when, they appear in all 149 capitals, as shown here. 151 This document is a Best Current Practices (BCP) document. It uses 152 the above language where it needs to make a normative requirement on 153 implementations. 155 3. Strategies to map names 157 The most naive method is to try to map IP addresses to names using 158 the in-addr.arpa (IPv4), and ipv6.arpa (IPv6) mappings. This fails 159 for a number of reasons: 161 1. it can not be done fast enough, 163 2. it reveals usage patterns of the devices, 165 3. the mapping are often incomplete, 167 4. even if the mapping is present, due to virtual hosting, it may 168 not map back to the name used in the ACL. 170 This is not a successful strategy, and do not use it. 172 XXX -- explain in detail how this can fail. 174 XXX -- explain N:1 vs 1:1 for virtual hosting. 176 The simplest successful strategy for translating names is for a MUD 177 controller to take is to do a DNS lookup on the name (a forward 178 lookup), and then use the resulting IP addresses to populate the 179 physical ACLs. 181 There are still a number of failures possible. 183 The most important one is in the mapping of the names to IP addresses 184 may be non-deterministic. [RFC1794] describes the very common 185 mechanism that returns DNS A (or reasonably AAAA) records in a 186 permutted order. This is known as Round Robin DNS, and it has been 187 used for many decades. The device is intended to use the first IP 188 address that is returned, and each query returns addresses in a 189 different ordering, splitting the load among many servers. 191 This situation does not result in failures as long as all possible A/ 192 AAAA records are returned. The MUD controller and the device get a 193 matching set, and the ACLs that are setup cover all possibilities. 195 There are a number of circumstances in which the list is not 196 exhaustive. The simplest is when the round robin does not return all 197 addresses. This is routinely done by geographical DNS load balancing 198 system. It can also happen if there are more addresses than will 199 conveniently fit into a DNS reply. The reply will be marked as 200 truncated. (If DNSSEC resolution will be done, then the entire RR 201 must be retrieved over TCP (or using a larger EDNS(0) size) before 202 being validated) 204 However, in a geographical DNS load balancing system, different 205 answers are given based upon the locality of the system asking. 206 There may also be further layers of round-robin indirection. 208 Aside from the list of records being incomplete, the list may have 209 changed between the time that the MUD controller did the lookup and 210 the time that the IoT device does the lookup, and this change can 211 result in a failure for the ACL to match. 213 In order to compensate for this, the MUD controller SHOULD regularly 214 do DNS lookups. These lookups need to be rate limited in order to 215 avoid load. It may be necessary to avoid recursive DNS servers in 216 order to avoid receiving cached data. Properly designed recursive 217 servers should cache data for many minutes to days, while the 218 underlying DNS data can change at a higher frequency, providing 219 different answers to different queries! 221 A MUD controller that is aware of which recursive DNS server that the 222 IoT device will use can instead query that server on a periodic 223 basis. Doing so provides three advantages: 225 1. any geographic load balancing will base the decision on the 226 geolocation of the recursive DNS server, and the recursive name 227 server will provide the same answer to the MUD controller as to 228 the IoT device. 230 2. the resulting name to IP address mapping in the recursive name 231 server will be cached, and will remain the same for the entire 232 advertised Time-To-Live reported in the DNS query return. This 233 also allows the MUD controller to avoid doing unnecessary 234 queries. 236 3. if any addresses have been omitted in a round-robin DNS process, 237 the cache will have the set of addresses that were returned. 239 The solution of using the same caching recursive resolver as the 240 target device is very simple when the MUD controllers is located in a 241 residential CPE device. The device is usually also the policy 242 enforcement point for the ACLs, and a caching resolver is typically 243 located on the same device. In addition the convenience, there is a 244 shared fate advantage: as all three components are running on the 245 same device, if the device is rebooted, clearing the cache, then all 246 three components will get restarted when the device is restarted. 248 Where the solution is more complex is when the MUD controller is 249 located elsewhere in an Enteprise, or remotely in a cloud such as 250 when a Software Defines Network (SDN) is used to manage the ACLs. 251 The DNS servers for a particular device may not be known to the MUD 252 controller, nor the MUD controller be even permitted to make recusive 253 queries that server if it is known. In this case, additional 254 installation specific mechanisms are probably needed to get the right 255 view of DNS. 257 4. DNS and IP Anti-Patterns for IoT device Manufacturers 259 In many design fields, there are good patterns that should be 260 emulated, and often there are patterns that should not be emulated. 261 The latter are called anti-patterns, as per [antipatterns]. 263 This section describes a number of things with IoT manufacturers have 264 been observed to do in the field, each of which presents difficulties 265 for MUD enforcement points. 267 4.1. Use of IP address literals in-protocol 269 A common pattern for a number of devices is to look for firmware 270 updates in a two step process. An initial query is made (often over 271 HTTPS, sometimes with a POST, but the method is immaterial) to an 272 authoritatve server. (What is this) The current firmware model of 273 the device is sometimes provided and then the authoritative server 274 provides a determination if a new version is required, and if so, 275 what version. In simpler cases, an HTTPS end point is queried which 276 provides the name and URL of the most recent firmware. 278 The authoritative upgrade server then responds with a URL of a 279 firmware blob that the device should download and install. Best 280 practice is that firmware is either signed internally 281 ([I-D.ietf-suit-architecture]) so that it can be verified, or a hash 282 of the blob is provided. 284 An authoritative server might be tempted to provided an IP address 285 literal inside the protocol: there are two arguments (anti-patterns) 286 for doing this. 288 One is that it eliminates problems to firmware updates that might be 289 caused by lack of DNS, or incompatibilities with DNS. For instance 290 the bug that causes interoperability issues with some recursive 291 servers would become unpatchable for devices that were forced to use 292 that recursive resolver type. 294 A second reason to avoid a DNS in the URL is when an inhouse content- 295 distribution system is involved that involves on-demand instances 296 being added (or removed) from a cloud computing architecture. 298 But, there are many problems with use of IP address literals for the 299 location of the firmware. 301 The first is that the update service server must decide whether to 302 provide an IPv4 or an IPv6 literal. A DNS name can contain both 303 kinds of addresses, and can also contain many different IP addresses 304 of each kind. 306 The second problem is that it forces the MUD file definition to 307 contain the exact same IP address literals. It must also contain an 308 ACL for each address literal. DNS provides a useful indirection 309 method that naturally aggregates the addresses. 311 A third problem involves the use of HTTPS. IP address literals do 312 not provide enough context for TLS ServerNameIndicator to be useful 313 [RFC6066]. This limits the firmware repository to be a single tenant 314 on that IP address, and for IPv4 (at least), this is no longer a 315 sustainable use of IP addresses. 317 And with any non-determistic name or address that is returned, the 318 MUD controller is not challenged to validate the transaction, as it 319 can not see into the communication. 321 Third-party content-distribution networks (CDN) tend to use DNS names 322 in order to isolate the content-owner from changes to the 323 distribution network. 325 4.2. Use of non-deterministic DNS names in-protocol 327 A second pattern is for a control protocol to connect to a known HTTP 328 end point. This is easily described in MUD. Within that control 329 protocol references are made to additional content at other URLs. 330 The values of those URLs do not fit any easily described pattern and 331 may point at arbitrary names. 333 Those names are often within some third-party Content-Distribution- 334 Network (CDN) system, or may be arbitrary names in a cloud-provider 335 storage system such as Amazon S3 (such [AmazonS3], or [Akamai]). 337 Since it is not possible to predict a name for where the content will 338 be, it is not possible to include that into the MUD file. 340 This applies to the firmware update situation as well. 342 4.3. Use of a too inclusive DNS name 344 Some CDNs make all customer content at a single URL (such as 345 s3.amazonaws.com). This seems to be ideal from a MUD point of view: 346 a completely predictable URL. The problem is that a compromised 347 device could then connect to any S3 bucket, potentially attacking 348 other buckets. 350 Amazon has recognized the problems associated with this practice, and 351 aims to change it to a virtual hosting model, as per 352 [awss3virtualhosting]. 354 The MUD ACLs provide only for permitting end points (hostnames and 355 ports), but do not filter URLs (nor could filtering be enforced 356 within HTTPS). 358 5. DNS privacy and outsourcing versus MUD controllers 360 [RFC7858] and [RFC8094] provide for DNS over TLS (DoT) and DNS over 361 HTTPS (DoH). [I-D.ietf-dnsop-terminology-ter] details the terms. 362 But, even with traditional DNS over Port-53 (Do53), it is possible to 363 outsource DNS queries to other public services, such as those 364 operated by Google, CloudFlare, Verisign, etc. 366 There are significant privacy issues with having IoT devices sending 367 their DNS queries to an outside entity. Doing it over a secure 368 transport (DoT/DoH) is clearly better than doing so on port 53. The 369 providers of the secure resolver service will, however, still see the 370 IoT device queries. 372 A described above in Section 3 the MUD controller needs to have 373 access to the same resolver(s) as the IoT device. Use of the QuadX 374 resolvers (such as Google's 8.8.8.8) at first seems to present less 375 of a problem than use of some other less well known resolver. While 376 any system may use QuadX, in most cases those services are massively 377 replicated via anycast: there is no guarantee that a MUD controller 378 will speak to the same instance, or get the same geographic anycast 379 result. 381 XXX - THIS NEEDS WAY MORE EXPLANATION. 383 6. Recommendations to IoT device manufacturer on MUD and DNS usage 385 Inclusion of a MUD file with IoT devices is operationally quite 386 simple. It requires only a few small changes to the DHCP client code 387 to express the MUD URL. It can even be done without code changes via 388 the use of a QR code affixed to the packaging (see 389 [I-D.richardson-mud-qrcode]. 391 The difficult part is determining what to put into the MUD file 392 itself. There are currently tools that help with the definition and 393 analysis of MUD files, see [mudmaker]. The remaining difficulty is 394 now the semantic contents of what is in the MUD file. An IoT 395 manufacturer must now spend some time reviewing what the network 396 communications that their device does. 398 This document has discussed a number of challenges that occur 399 relating to how DNS requests are made and resolved, and it is the 400 goal of this section to make recommendations on how to modify IoT 401 systems to work well with MUD. 403 6.1. Consistently use DNS 405 The first recommendation is to avoid using IP address literals in any 406 protocol. Names should always be used. 408 6.2. Use primary DNS names controlled by the manufacturer 410 The second recommendation is to allocate and use names within zones 411 controlled by the manufacturer. These names can be populated with an 412 alias (see [RFC8499] section 2) that points to the production system. 413 Ideally, a different name is used for each logical function, allowing 414 for different rules in the MUD file to be enabled and disabled. 416 While it used to be costly to have a large number of aliases in a web 417 server certificate, this is no longer the case. Wildcard 418 certificates are also commonly available which allowed for an 419 infinite number of possible names. 421 6.3. Use Content-Distribution Network with stable names 423 When aliases point to a Content-Distribution Network (CDN), prefer to 424 use stable names that point to appropriately load balanced targets. 425 CDNs that employ very low time-to-live (TTL) values for DNS make it 426 harder for the MUD controller to get the same answer as the IoT 427 Device. A CDN that always returns the same set of A and AAAA 428 records, but permutes them to provide the best one first provides a 429 more reliable answer. 431 6.4. Do not use geofenced names 433 Due the problems with different answers from different DNS servers, 434 described above, a strong recommendation is to avoid using such 435 things. 437 6.5. Prefer DNS servers learnt from DHCP/Route Advertisements 439 XXX - it has been suggested that this will not help, thus previous 440 recommendation. 442 IoT Devices should prefer doing DNS to the network provided DNS 443 servers. Whether this is restricted to Classic DNS (Do53) or also 444 includes using DoT/DoH is a local decision, but a locally provided 445 DoT server SHOULD be used, as recommended by 446 [I-D.reddy-dprive-bootstrap-dns-server] and [I-D.peterson-doh-dhcp]. 448 The ADD WG is currently only focusing on insecure discovery 449 mechanisms like DHCP/RA [I-D.btw-add-home] and DNS based discovery 450 mechanisms ({?{I-D.pauly-add-deer}}). Secure discovery of network 451 provided DoH/DoT resolver is possible using the mechanisms discussed 452 in [I-D.reddy-add-enterprise] section-4. 454 Use of public QuadX resolver instead of the provided DNS resolver, 455 whether Do53, DoT or DoH is discouraged. Should the network provide 456 such a resolver for use, then there is no reason not to use it, as 457 the network operator has clearly thought about this. 459 Some manufacturers would like to have a fallback to using a public 460 resolver to mitigate against local misconfiguration. There are a 461 number of reasons to avoid this, or at least do this very carefully. 462 The recommendation here is to do this only when the provided 463 resolvers provide no answers to any queries at all, and do so 464 repeatedly. The use of the operator provided resolvers SHOULD be 465 retried on a periodic basis, and once they answer, there should be no 466 further attempts to contact public resolvers. 468 Finally, the list of public resolvers that might be contacted MUST be 469 listed in the MUD file as destinations that are to be permitted! 470 This should include the port numbers (53, 853 for DoT, 443 for DoH) 471 that will be used as well. 473 7. Privacy Considerations 475 The use of non-local DNS servers exposes the list of names resolved 476 to a third parties, including passive eavesdroppers. 478 The use of DoT and DoH eliminates the minimizes threat from passive 479 eavesdropped, but still exposes the list to the operator of the DoT 480 or DoH server. There are additional methods, such as described by 481 [I-D.pauly-dprive-oblivious-doh]. 483 The use of unencrypted (Do53) requests to a local DNS server exposes 484 the list to any internal passive eavesdroppers, and for some 485 situations that may be significant, particularly if unencrypted WiFi 486 is used. Use of Encrypted DNS connection to a local DNS recursive 487 resolver is a preferred choice, assuming that the trust anchor for 488 the local DNS server can be obtained, such as via 489 [I-D.reddy-dprive-bootstrap-dns-server]. 491 IoT devices that reach out to the manufacturer at regular intervals 492 to check for firmware updates are informing passive eavesdroppers of 493 the existence of a specific manufacturer's device being present at 494 the origin location. 496 Identifying the IoT device type empowers the attacker to launch 497 targeted attacks to the IoT device (e.g., Attacker can advantage of 498 the device vulnerability). 500 While possession of a Large (Kitchen) Appliance at a residence may be 501 uninteresting to most, possession of intimate personal devices (e.g., 502 "sex toys") may be a cause for embarrassment. 504 IoT device manufacturers are encouraged to find ways to anonymize 505 their update queries. For instance, contracting out the update 506 notification service to a third party that deals with a large variety 507 of devices would provide a level of defense against passive 508 eavesdropping. Other update mechanisms should be investigated, 509 including use of DNSSEC signed TXT records with current version 510 information. This would permit DoT or DoH to convey the update 511 notification in a private fashion. This is particularly powerful if 512 a local recursive DoT server is used, which then communicates using 513 DoT over the Internet. 515 The more complex case of section Section 4.1 postulates that the 516 version number needs to be provided to an intelligent agent that can 517 decided the correct route to do upgrades. The current 518 [I-D.ietf-suit-architecture] specification provides a wide variety of 519 ways to accomplish the same thing without having to divulge the 520 current version number. 522 The use of a publically specified firmware update protocol would also 523 enhance privacy of IoT devices. In such a system the IoT device 524 would never contact the manufacturer for version information or for 525 firmware itself. Instead, details of how to query and where to get 526 the firmware would be provided as a MUD extension, and a Enterprise- 527 wide mechanism would retrieve firmware, and then distribute it 528 internally. Aside from the bandwidth savings of downloading the 529 firmware only once, this also makes the number of devices active 530 confidential, and provides some evidence about which devices have 531 been upgraded and which ones might still be vulnerable. (The 532 unpatched devices might be lurking, powered off, lost in a closet) 534 8. Security Considerations 536 This document deals with conflicting Security requirements: 538 1. devices which an operator wants to manage using [RFC8520] 540 2. requirements for the devices to get access to network resources 541 that may be critical to their continued safe operation. 543 This document takes the view that the two requirements do not need to 544 be in conflict, but resolving the conflict requires some advance 545 planning by all parties. 547 9. References 549 9.1. Normative References 551 [Akamai] "Akamai", 2019, 552 . 554 [AmazonS3] "Amazon S3", 2019, 555 . 557 [I-D.ietf-dnsop-terminology-ter] 558 Hoffman, P., "Terminology for DNS Transports and 559 Location", Work in Progress, Internet-Draft, draft-ietf- 560 dnsop-terminology-ter-02, 3 August 2020, 561 . 564 [I-D.ietf-suit-architecture] 565 Moran, B., Tschofenig, H., Brown, D., and M. Meriac, "A 566 Firmware Update Architecture for Internet of Things", Work 567 in Progress, Internet-Draft, draft-ietf-suit-architecture- 568 16, 27 January 2021, . 571 [I-D.peterson-doh-dhcp] 572 Peterson, T., "DNS over HTTP resolver announcement Using 573 DHCP or Router Advertisements", Work in Progress, 574 Internet-Draft, draft-peterson-doh-dhcp-01, 21 October 575 2019, . 578 [I-D.reddy-dprive-bootstrap-dns-server] 579 Reddy, T., Wing, D., Richardson, M. C., and M. Boucadair, 580 "A Bootstrapping Procedure to Discover and Authenticate 581 DNS-over-TLS and DNS-over-HTTPS Servers", Work in 582 Progress, Internet-Draft, draft-reddy-dprive-bootstrap- 583 dns-server-08, 6 March 2020, 584 . 587 [RFC1794] Brisco, T., "DNS Support for Load Balancing", RFC 1794, 588 DOI 10.17487/RFC1794, April 1995, 589 . 591 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 592 Requirement Levels", BCP 14, RFC 2119, 593 DOI 10.17487/RFC2119, March 1997, 594 . 596 [RFC6146] Bagnulo, M., Matthews, P., and I. van Beijnum, "Stateful 597 NAT64: Network Address and Protocol Translation from IPv6 598 Clients to IPv4 Servers", RFC 6146, DOI 10.17487/RFC6146, 599 April 2011, . 601 [RFC7858] Hu, Z., Zhu, L., Heidemann, J., Mankin, A., Wessels, D., 602 and P. Hoffman, "Specification for DNS over Transport 603 Layer Security (TLS)", RFC 7858, DOI 10.17487/RFC7858, May 604 2016, . 606 [RFC8094] Reddy, T., Wing, D., and P. Patil, "DNS over Datagram 607 Transport Layer Security (DTLS)", RFC 8094, 608 DOI 10.17487/RFC8094, February 2017, 609 . 611 [RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC 612 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, 613 May 2017, . 615 [RFC8499] Hoffman, P., Sullivan, A., and K. Fujiwara, "DNS 616 Terminology", BCP 219, RFC 8499, DOI 10.17487/RFC8499, 617 January 2019, . 619 [RFC8520] Lear, E., Droms, R., and D. Romascanu, "Manufacturer Usage 620 Description Specification", RFC 8520, 621 DOI 10.17487/RFC8520, March 2019, 622 . 624 9.2. Informative References 626 [antipatterns] 627 "AntiPattern", 12 July 2021, 628 . 630 [awss3virtualhosting] 631 "Down to the Wire: AWS Delays 'Path-Style' S3 Deprecation 632 at Last Minute", 12 July 2021, 633 . 636 [I-D.btw-add-home] 637 Boucadair, M., Reddy, T., Wing, D., Cook, N., and T. 638 Jensen, "DHCP and Router Advertisement Options for 639 Encrypted DNS Discovery", Work in Progress, Internet- 640 Draft, draft-btw-add-home-12, 22 January 2021, 641 . 644 [I-D.pauly-dprive-oblivious-doh] 645 Kinnear, E., McManus, P., Pauly, T., Verma, T., and C. A. 646 Wood, "Oblivious DNS Over HTTPS", Work in Progress, 647 Internet-Draft, draft-pauly-dprive-oblivious-doh-06, 8 648 March 2021, . 651 [I-D.reddy-add-enterprise] 652 Reddy, T. and D. Wing, "DNS-over-HTTPS and DNS-over-TLS 653 Server Deployment Considerations for Enterprise Networks", 654 Work in Progress, Internet-Draft, draft-reddy-add- 655 enterprise-00, 23 June 2020, 656 . 659 [I-D.richardson-mud-qrcode] 660 Richardson, M., Latour, J., and H. H. Gharakheili, "On 661 loading MUD URLs from QR codes", Work in Progress, 662 Internet-Draft, draft-richardson-mud-qrcode-00, 17 663 December 2020, . 666 [mudmaker] "Mud Maker", 2019, . 668 [RFC6066] Eastlake 3rd, D., "Transport Layer Security (TLS) 669 Extensions: Extension Definitions", RFC 6066, 670 DOI 10.17487/RFC6066, January 2011, 671 . 673 Appendix A. Appendices 675 Authors' Addresses 677 Michael Richardson 678 Sandelman Software Works 680 Email: mcr+ietf@sandelman.ca 682 Wei Pan 683 Huawei Technologies 685 Email: william.panwei@huawei.com