draft-ietf-opsawg-mud-iot-dns-considerations-12.txt | draft-ietf-opsawg-mud-iot-dns-considerations-13.txt | |||
---|---|---|---|---|
OPSAWG Working Group M. Richardson | OPSAWG Working Group M. Richardson | |||
Internet-Draft Sandelman Software Works | Internet-Draft Sandelman Software Works | |||
Intended status: Best Current Practice W. Pan | Intended status: Best Current Practice W. Pan | |||
Expires: 11 August 2024 Huawei Technologies | Expires: 22 September 2024 Huawei Technologies | |||
8 February 2024 | 21 March 2024 | |||
Operational Considerations for use of DNS in IoT devices | Operational Considerations for Use of DNS in IoT Devices | |||
draft-ietf-opsawg-mud-iot-dns-considerations-12 | draft-ietf-opsawg-mud-iot-dns-considerations-13 | |||
Abstract | Abstract | |||
This document details concerns about how Internet of Things devices | This document details concerns about how Internet of Things (IoT) | |||
use IP addresses and DNS names. The issue becomes acute as network | devices use IP addresses and DNS names. These concerns become acute | |||
operators begin deploying RFC8520 Manufacturer Usage Description | as network operators begin deploying RFC 8520 Manufacturer Usage | |||
(MUD) definitions to control device access. | Description (MUD) definitions to control device access. | |||
This document makes recommendations on when and how to use DNS names | Alos, this document makes recommendations on when and how to use DNS | |||
in MUD files. | names in MUD files. | |||
About This Document | About This Document | |||
This note is to be removed before publishing as an RFC. | This note is to be removed before publishing as an RFC. | |||
Status information for this document may be found at | Status information for this document may be found at | |||
https://datatracker.ietf.org/doc/draft-ietf-opsawg-mud-iot-dns- | https://datatracker.ietf.org/doc/draft-ietf-opsawg-mud-iot-dns- | |||
considerations/. | considerations/. | |||
Discussion of this document takes place on the opsawg Working Group | Discussion of this document takes place on the opsawg Working Group | |||
mailing list (mailto:opsawg@ietf.org), which is archived at | mailing list (mailto:opsawg@ietf.org), which is archived at | |||
https://mailarchive.ietf.org/arch/browse/opsawg/. Subscribe at | https://mailarchive.ietf.org/arch/browse/opsawg/. | |||
https://www.ietf.org/mailman/listinfo/opsawg/. | ||||
Source for this draft and an issue tracker can be found at | Source for this draft and an issue tracker can be found at | |||
https://github.com/mcr/iot-mud-dns-considerations. | https://github.com/mcr/iot-mud-dns-considerations. | |||
Status of This Memo | Status of This Memo | |||
This Internet-Draft is submitted in full conformance with the | This Internet-Draft is submitted in full conformance with the | |||
provisions of BCP 78 and BCP 79. | provisions of BCP 78 and BCP 79. | |||
Internet-Drafts are working documents of the Internet Engineering | Internet-Drafts are working documents of the Internet Engineering | |||
Task Force (IETF). Note that other groups may also distribute | Task Force (IETF). Note that other groups may also distribute | |||
working documents as Internet-Drafts. The list of current Internet- | working documents as Internet-Drafts. The list of current Internet- | |||
Drafts is at https://datatracker.ietf.org/drafts/current/. | Drafts is at https://datatracker.ietf.org/drafts/current/. | |||
Internet-Drafts are draft documents valid for a maximum of six months | Internet-Drafts are draft documents valid for a maximum of six months | |||
and may be updated, replaced, or obsoleted by other documents at any | and may be updated, replaced, or obsoleted by other documents at any | |||
time. It is inappropriate to use Internet-Drafts as reference | time. It is inappropriate to use Internet-Drafts as reference | |||
material or to cite them other than as "work in progress." | material or to cite them other than as "work in progress." | |||
This Internet-Draft will expire on 11 August 2024. | This Internet-Draft will expire on 22 September 2024. | |||
Copyright Notice | Copyright Notice | |||
Copyright (c) 2024 IETF Trust and the persons identified as the | Copyright (c) 2024 IETF Trust and the persons identified as the | |||
document authors. All rights reserved. | document authors. All rights reserved. | |||
This document is subject to BCP 78 and the IETF Trust's Legal | This document is subject to BCP 78 and the IETF Trust's Legal | |||
Provisions Relating to IETF Documents (https://trustee.ietf.org/ | Provisions Relating to IETF Documents (https://trustee.ietf.org/ | |||
license-info) in effect on the date of publication of this document. | license-info) in effect on the date of publication of this document. | |||
Please review these documents carefully, as they describe your rights | Please review these documents carefully, as they describe your rights | |||
and restrictions with respect to this document. Code Components | and restrictions with respect to this document. Code Components | |||
extracted from this document must include Revised BSD License text as | extracted from this document must include Revised BSD License text as | |||
described in Section 4.e of the Trust Legal Provisions and are | described in Section 4.e of the Trust Legal Provisions and are | |||
provided without warranty as described in the Revised BSD License. | provided without warranty as described in the Revised BSD License. | |||
Table of Contents | Table of Contents | |||
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3 | 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3 | |||
2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 4 | 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 4 | |||
3. Strategies to map names . . . . . . . . . . . . . . . . . . . 4 | 3. A model for MUD controller mapping of names to addresses . . 4 | |||
3.1. Failing strategy . . . . . . . . . . . . . . . . . . . . 4 | 3.1. Non-Deterministic Mappings . . . . . . . . . . . . . . . 4 | |||
3.1.1. Too slow . . . . . . . . . . . . . . . . . . . . . . 5 | 4. DNS and IP Anti-Patterns for IoT Device Manufacturers . . . . 6 | |||
3.1.2. Reveals patterns of usage . . . . . . . . . . . . . . 5 | 4.1. Use of IP Address Literals in-protocol . . . . . . . . . 6 | |||
3.1.3. Mappings are often incomplete . . . . . . . . . . . . 5 | 4.2. Use of Non-deterministic DNS Names in-protocol . . . . . 8 | |||
3.1.4. Forward names can have wildcards . . . . . . . . . . 6 | 4.3. Use of a Too Generic DNS Name . . . . . . . . . . . . . . 9 | |||
3.2. A successful strategy . . . . . . . . . . . . . . . . . . 6 | 5. DNS Privacy and Outsourcing versus MUD Controllers . . . . . 9 | |||
4. DNS and IP Anti-Patterns for IoT device Manufacturers . . . . 8 | 6. Recommendations To IoT Device Manufacturers on MUD and DNS | |||
4.1. Use of IP address literals inprotocol . . . . . . . . . . 8 | Usage . . . . . . . . . . . . . . . . . . . . . . . . . . 10 | |||
4.2. Use of non-deterministic DNS names in-protocol . . . . . 10 | 6.1. Consistently use DNS . . . . . . . . . . . . . . . . . . 10 | |||
4.3. Use of a too generic DNS name . . . . . . . . . . . . . . 11 | 6.2. Use Primary DNS Names Controlled By The Manufacturer . . 10 | |||
5. DNS privacy and outsourcing versus MUD controllers . . . . . 11 | 6.3. Use Content-Distribution Network with Stable Names . . . 10 | |||
6. Recommendations to IoT device manufacturer on MUD and DNS | 6.4. Do Not Use Tailored Responses to answer DNS Names . . . . 11 | |||
usage . . . . . . . . . . . . . . . . . . . . . . . . . . 12 | 6.5. Prefer DNS Servers Learnt From DHCP/Route | |||
6.1. Consistently use DNS . . . . . . . . . . . . . . . . . . 12 | Advertisements . . . . . . . . . . . . . . . . . . . . . 11 | |||
6.2. Use primary DNS names controlled by the manufacturer . . 12 | 7. Privacy Considerations . . . . . . . . . . . . . . . . . . . 12 | |||
6.3. Use Content-Distribution Network with stable names . . . 12 | 8. Security Considerations . . . . . . . . . . . . . . . . . . . 13 | |||
6.4. Do not use geofenced names . . . . . . . . . . . . . . . 13 | 9. References . . . . . . . . . . . . . . . . . . . . . . . . . 13 | |||
6.5. Prefer DNS servers learnt from DHCP/Route | 9.1. Normative References . . . . . . . . . . . . . . . . . . 13 | |||
Advertisements . . . . . . . . . . . . . . . . . . . . . 13 | 9.2. Informative References . . . . . . . . . . . . . . . . . 14 | |||
7. Privacy Considerations . . . . . . . . . . . . . . . . . . . 13 | Appendix A. A Failing Strategy --- Anti-Patterns . . . . . . . . 16 | |||
8. Security Considerations . . . . . . . . . . . . . . . . . . . 15 | A.1. Too Slow . . . . . . . . . . . . . . . . . . . . . . . . 16 | |||
9. References . . . . . . . . . . . . . . . . . . . . . . . . . 15 | A.2. Reveals Patterns of Usage . . . . . . . . . . . . . . . . 16 | |||
9.1. Normative References . . . . . . . . . . . . . . . . . . 15 | A.3. Mappings Are Often Incomplete . . . . . . . . . . . . . . 17 | |||
9.2. Informative References . . . . . . . . . . . . . . . . . 16 | A.4. Forward Names Can Have Wildcards . . . . . . . . . . . . 17 | |||
Appendix A. Appendices . . . . . . . . . . . . . . . . . . . . . 17 | Contributors . . . . . . . . . . . . . . . . . . . . . . . . . . 18 | |||
Contributors . . . . . . . . . . . . . . . . . . . . . . . . . . 17 | Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 18 | |||
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 17 | ||||
1. Introduction | 1. Introduction | |||
[RFC8520] provides a standardized way to describe how a specific | [RFC8520] provides a standardized way to describe how a specific | |||
purpose device makes use of Internet resources. Access Control Lists | purpose device makes use of Internet resources. Access Control Lists | |||
(ACLs) can be defined in an RFC8520 Manufacturer Usage Description | (ACLs) can be defined in an RFC 8520 Manufacturer Usage Description | |||
(MUD) file that permit a device to access Internet resources by DNS | (MUD) file that permit a device to access Internet resources by their | |||
name or IP address. | DNS names or IP addresses. | |||
Use of a DNS name rather than IP address in the ACL has many | Use of a DNS name rather than an IP address in an ACL has many | |||
advantages: not only does the layer of indirection permit the mapping | advantages: not only does the layer of indirection permit the mapping | |||
of name to IP address to be changed over time, it also generalizes | of a name to IP address(es) to be changed over time, it also | |||
automatically to IPv4 and IPv6 addresses, as well as permitting a | generalizes automatically to IPv4 and IPv6 addresses, as well as | |||
variety of load balancing strategies, including multi-CDN deployments | permitting a variety of load balancing strategies, including multi- | |||
wherein load balancing can account for geography and load. | CDN deployments wherein load balancing can account for geography and | |||
load. | ||||
At the MUD policy enforcement point -- the firewall -- there is a | However, the use of DNS names has implications on how ACL are | |||
problem. The firewall has access only to the layer-3 headers of the | executed at the MUD policy enforcement point (typically, a firewall). | |||
packet. This includes the source and destination IP address, and if | Conceretely, the firewall has access only to the Layer 3 headers of | |||
not encrypted by IPsec, the destination UDP or TCP port number | the packet. This includes the source and destination IP address, and | |||
if not encrypted by IPsec, the destination UDP or TCP port number | ||||
present in the transport header. The DNS name is not present! | present in the transport header. The DNS name is not present! | |||
It has been suggested that one answer to this problem is to provide a | So in order to implement these name based ACLs, there must be a | |||
forced intermediate for the TLS connections. In theory, this could | mapping between the names in the ACLs and IP addresses. | |||
be done for TLS 1.2 connections. The MUD policy enforcement point | ||||
could observe the Server Name Identifier (SNI) [RFC6066]. Some | ||||
Enterprises do this already. But, as this involves active | ||||
termination of the TCP connection (a forced circuit proxy) in order | ||||
to see enough of the traffic, it requires significant effort. | ||||
In TLS 1.3, with or without the use of ECH, middleboxes cannot rely | In order for manufacturers to understand how to configure DNS | |||
on SNI inspection because malware could lie about the SNI. In | associated with name based ACLs, a model of how the DNS resolution | |||
addition, middleboxes do not have visibility into the server | will be done by MUD controllers is necessary. Section 3 models some | |||
certificate unless they are acting as TLS proxies. | good strategies that are used. | |||
So in order to implement these name based ACLs, there must be a | This model is non-normative: but is included so that IoT device | |||
mapping between the names in the ACLs and layer-3 IP addresses. The | manufacturers can understand how the DNS will be used to resolve the | |||
first section of this document details a few strategies that are | names they use. | |||
used. | ||||
The second section of this document details how common manufacturer | There are some ways of using DNS that will present problems for MUD | |||
anti-patterns get in the way of this mapping. The term "anti- | controllers, which Section 4 explains. | |||
pattern" comes from agile software design literature, as per | ||||
[antipatterns]. | ||||
The third section of this document details how current trends in DNS | Section 5 details how current trends in DNS resolution such as public | |||
resolution such as public DNS servers, DNS over TLS (DoT), DNS over | DNS servers, DNS over TLS (DoT) [RFC7858], DNS over HTTPS (DoH) | |||
QUIC (DoQ), and DNS over HTTPS (DoH) cause problems for the | [RFC8484], or DNS over QUIC (DoQ) [RFC9250] can cause problems with | |||
strategies employed. | the strategies employed. | |||
The fourth section of this document makes a series of recommendations | The core of this document, is Section 6, which makes a series of | |||
("best current practices") for manufacturers on how to use DNS and IP | recommendations ("best current practices") for manufacturers on how | |||
addresses with MUD supporting IoT devices. | to use DNS and IP addresses with MUD supporting IoT devices. | |||
The Privacy Considerations section concerns itself with issues that | Section 7 discusses a set of privacy issues that encrypted DNS (DoT, | |||
DNS-over-TLS and DNS-over-HTTPS are frequently used to deal with. | DoH, for example) are frequently used to deal with. How these | |||
How these concerns apply to IoT devices located within a residence or | concerns apply to IoT devices located within a residence or | |||
enterprise is a key concern. | enterprise is a key concern. | |||
The Security Considerations section covers some of the negative | Section 8 also covers some of the negative outcomes should MUD/ | |||
outcomes should MUD/firewall managers and IoT manufacturers choose | firewall managers and IoT manufacturers choose not to cooperate. | |||
not to cooperate. | ||||
2. Terminology | 2. Terminology | |||
Although this document is not an IETF Standards Track publication, it | Although this document is not an IETF Standards Track publication, it | |||
adopts the conventions for normative language to provide clarity of | adopts the conventions for normative language to provide clarity of | |||
instructions to the implementer. The key words "MUST", "MUST NOT", | instructions to the implementer. The key words "MUST", "MUST NOT", | |||
"REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", | "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", | |||
"RECOMMENDED", "NOT RECOMMENDED", "MAY", and "OPTIONAL" in this | "RECOMMENDED", "NOT RECOMMENDED", "MAY", and "OPTIONAL" in this | |||
document are to be interpreted as described in BCP 14 [RFC2119] | document are to be interpreted as described in BCP 14 [RFC2119] | |||
[RFC8174] when, and only when, they appear in all capitals, as shown | [RFC8174] when, and only when, they appear in all capitals, as shown | |||
here. | here. | |||
3. Strategies to map names | This document makes use of terms defined in [RFC8520] and | |||
[I-D.ietf-dnsop-rfc8499bis]. | ||||
The most naive method is to try to map IP addresses to names using | ||||
the in-addr.arpa (IPv4), and ipv6.arpa (IPv6) mappings at the time | ||||
the packet is seen. | ||||
3.1. Failing strategy | ||||
Attempts to map IP address to names in real time fails for a number | ||||
of reasons: | ||||
1. it can not be done fast enough, | ||||
2. it reveals usage patterns of the devices, | ||||
3. the mapping are often incomplete, | ||||
4. Even if the mapping is present, due to virtual hosting, it may | ||||
not map back to the name used in the ACL. | ||||
This is not a successful strategy, its use is NOT RECOMMENDED for the | ||||
reasons explained below. | ||||
3.1.1. Too slow | ||||
Mapping of IP addresses to names requires a DNS lookup in the in- | ||||
addr.arpa or ip6.arpa space. For a cold DNS cache, this will | ||||
typically require 2 to 3 NS record lookups to locate the DNS server | ||||
that holds the information required. At 20 to 100 ms per round trip, | ||||
this easily adds up to significant time before the packet that caused | ||||
the lookup can be released. | ||||
While subsequent connections to the same site (and subsequent packets | ||||
in the same flow) will not be affected if the results are cached, the | ||||
effects will be felt. The ACL results can be cached for a period of | ||||
time given by the TTL of the DNS results, but the DNS lookup must be | ||||
repeated, e.g, in a few hours or days,when the cached IP address to | ||||
name binding expires. | ||||
3.1.2. Reveals patterns of usage | ||||
By doing the DNS lookups when the traffic occurs, then a passive | ||||
attacker can see when the device is active, and may be able to derive | ||||
usage patterns. They could determine when a home was occupied or | ||||
not. This does not require access to all on-path data, just to the | ||||
DNS requests to the bottom level of the DNS tree. | ||||
3.1.3. Mappings are often incomplete | ||||
A service provider that fails to include an A or AAAA record as part | ||||
of their forward name publication will find that the new server is | ||||
simply not used. The operational feedback for that mistake is | ||||
immediate. The same is not true for reverse names: they can often be | ||||
incomplete or incorrect for months or even years without visible | ||||
effect on operations. | ||||
Service providers often find it difficult to update reverse maps in a | ||||
timely fashion, assuming that they can do it at all. Many cloud | ||||
based solutions dynamically assign IP addresses to services, often as | ||||
the service grows and shrinks, reassigning those IP addresses to | ||||
other services quickly. The use of HTTP 1.1 Virtual Hosting may | ||||
allow addresses and entire front-end systems to be re-used | ||||
dynamically without even reassigning the IP addresses. | ||||
In some cases there are multiple layers of CNAME between the original | ||||
name and the target service name. This is often due to a load | ||||
balancing layer in the DNS, followed by a load balancing layer at the | ||||
HTTP level. | ||||
The reverse name for the IP address of the load balancer usually does | ||||
not change. If hundreds of web services are funneled through the | ||||
load balancer, it would require hundreds of PTR records to be | ||||
deployed. This would easily exceed the UDP/DNS and EDNS0 limits, and | ||||
require all queries to use TCP, which would further slow down loading | ||||
of the records. | ||||
The enumeration of all services/sites that have been at that load | ||||
balancer might also constitute a security concern. To limit churn of | ||||
DNS PTR records, and reduce failures of the MUD ACLs, operators would | ||||
want to add all possible names for each reverse name, whether or not | ||||
the DNS load balancing in the forward DNS space lists that end-point | ||||
at that moment. | ||||
3.1.4. Forward names can have wildcards | ||||
In some large hosting providers content is hosted through a domain | ||||
name that is published as a DNS wildcard (and uses a wildcard | ||||
certificate). For instance, github.io, which is used for hosted | ||||
content, including the Editors' copy of internet drafts stored on | ||||
github, does not actually publish any names. Instead, a wildcard | ||||
exists to answer all potential names: requests are routed appropriate | ||||
once they are received. | ||||
This kind of system works well for self-managed hosted content. | The term "anti-pattern" comes from agile software design literature, | |||
However, while it is possible to insert up to a few dozen PTR | as per [antipatterns]. | |||
records, many thousand entries are not possible, nor is it possible | ||||
to deal with the unlimited (infinite) number of possibilities that a | ||||
wildcard supports. | ||||
It would be therefore impossible for the PTR reverse lookup to ever | 3. A model for MUD controller mapping of names to addresses | |||
work with these wildcard names. | ||||
3.2. A successful strategy | This section details a strategy that a MUD controller could take. | |||
Within the limits of DNS use detailed in Section 6, this process can | ||||
work. The methods detailed in Appendix A just will not work. | ||||
The simplest successful strategy for translating names for a MUD | The simplest successful strategy for translating names for a MUD | |||
controller to take is to do a DNS lookup on the name (a forward | controller to take is to do a DNS lookup on the name (a forward | |||
lookup), and then use the resulting IP addresses to populate the | lookup), and then use the resulting IP addresses to populate the | |||
physical ACLs. | actual ACLs. | |||
There are still a number of failures possible. | There a number of possible failures, and the goal of this section is | |||
to explain how some common DNS usages may fail. | ||||
3.1. Non-Deterministic Mappings | ||||
The most important one is that the mapping of the names to IP | The most important one is that the mapping of the names to IP | |||
addresses may be non-deterministic. [RFC1794] describes the very | addresses may be non-deterministic. | |||
common mechanism that returns DNS A (or reasonably AAAA) records in a | ||||
permuted order. This is known as Round Robin DNS, and it has been | [RFC1794] describes the very common mechanism that returns DNS A (or | |||
used for many decades. The device is intended to use the first IP | reasonably AAAA) records in a permuted order. This is known as Round | |||
address that is returned, and each query returns addresses in a | Robin DNS, and it has been used for many decades. The historical | |||
different ordering, splitting the load among many servers. | intent is that the requestor will tend to use the first IP address | |||
that is returned. As each query results in addresses in a different | ||||
ordering, the effect is to split the load among many servers. | ||||
This situation does not result in failures as long as all possible A/ | This situation does not result in failures as long as all possible A/ | |||
AAAA records are returned. The MUD controller and the device get a | AAAA records are returned. The MUD controller and the device get a | |||
matching set, and the ACLs that are set up cover all possibilities. | matching set, and the ACLs that are set up cover all possibilities. | |||
There are a number of circumstances in which the list is not | There are a number of circumstances in which the list is not | |||
exhaustive. The simplest is when the round-robin does not return all | exhaustive. The simplest is when the round-robin does not return all | |||
addresses. This is routinely done by geographical DNS load balancing | addresses. This is routinely done by geographical DNS load balancing | |||
systems. It can also happen if there are more addresses than will | systems: only the addresses that the balancing system wishes to be | |||
conveniently fit into a DNS reply. The reply will be marked as | used are returned. | |||
truncated. (If DNSSEC resolution will be done, then the entire RR | ||||
must be retrieved over TCP (or using a larger EDNS(0) size) before | It can also happen if there are more addresses than will conveniently | |||
being validated) | fit into a DNS reply. The reply will be marked as truncated. (If | |||
DNSSEC resolution will be done, then the entire RR must be retrieved | ||||
over TCP (or using a larger EDNS(0) size) before being validated) | ||||
However, in a geographical DNS load balancing system, different | However, in a geographical DNS load balancing system, different | |||
answers are given based upon the locality of the system asking. | answers are given based upon the locality of the system asking. | |||
There may also be further layers of round-robin indirection. | There may also be further layers of round-robin indirection. | |||
Aside from the list of records being incomplete, the list may have | Aside from the list of records being incomplete, the list may have | |||
changed between the time that the MUD controller did the lookup and | changed between the time that the MUD controller did the lookup and | |||
the time that the IoT device did the lookup, and this change can | the time that the IoT device did the lookup, and this change can | |||
result in a failure for the ACL to match. | result in a failure for the ACL to match. If the IoT device did not | |||
use the same recursive servers as the MUD controller, then geofencing | ||||
and/or truncated round-robin results could return a different, and | ||||
non-overlapping set of addresses. | ||||
In order to compensate for this, the MUD controller SHOULD regularly | In order to compensate for this, the MUD controller SHOULD regularly | |||
perform DNS lookups in order to never have stale data. These lookups | perform DNS lookups in order to never have stale data. These lookups | |||
must be rate limited to avoid excessive load on the DNS servers, and | must be rate limited to avoid excessive load on the DNS servers, and | |||
it may be necessary to avoid local recursive resolvers. The MUD | it may be necessary to avoid local recursive resolvers. The MUD | |||
controller SHOULD incorporate its own recursive caching DNS server. | controller SHOULD incorporate its own recursive caching DNS server. | |||
Properly designed recursive servers should cache data for at least | Properly designed recursive servers should cache data for at least | |||
some number of minutes, up to some number of days, while the | some number of minutes, up to some number of days (respecting the | |||
underlying DNS data can change at a higher frequency, providing | TTL), while the underlying DNS data can change at a higher frequency, | |||
different answers to different queries! | providing different answers to different queries! | |||
A MUD controller that is aware of which recursive DNS server the IoT | A MUD controller that is aware of which recursive DNS server the IoT | |||
device will use can instead query that server on a periodic basis. | device will use can instead query that server on a periodic basis. | |||
Doing so provides three advantages: | Doing so provides three advantages: | |||
1. Any geographic load balancing will base the decision on the | 1. Any geographic load balancing will base the decision on the | |||
geolocation of the recursive DNS server, and the recursive name | geolocation of the recursive DNS server, and the recursive name | |||
server will provide the same answer to the MUD controller as to | server will provide the same answer to the MUD controller as to | |||
the IoT device. | the IoT device. | |||
skipping to change at page 8, line 32 ¶ | skipping to change at page 6, line 37 ¶ | |||
Where the solution is more complex is when the MUD controller is | Where the solution is more complex is when the MUD controller is | |||
located elsewhere in an Enterprise, or remotely in a cloud such as | located elsewhere in an Enterprise, or remotely in a cloud such as | |||
when a Software Defined Network (SDN) is used to manage the ACLs. | when a Software Defined Network (SDN) is used to manage the ACLs. | |||
The DNS servers for a particular device may not be known to the MUD | The DNS servers for a particular device may not be known to the MUD | |||
controller, nor the MUD controller be even permitted to make | controller, nor the MUD controller be even permitted to make | |||
recursive queries to that server if it is known. In this case, | recursive queries to that server if it is known. In this case, | |||
additional installation specific mechanisms are probably needed to | additional installation specific mechanisms are probably needed to | |||
get the right view of the DNS. | get the right view of the DNS. | |||
4. DNS and IP Anti-Patterns for IoT device Manufacturers | 4. DNS and IP Anti-Patterns for IoT Device Manufacturers | |||
In many design fields, there are good patterns that should be | In many design fields, there are good patterns that should be | |||
emulated, and often there are patterns that should not be emulated. | emulated, and often there are patterns that should not be emulated. | |||
The latter are called anti-patterns, as per [antipatterns]. | The latter are called anti-patterns, as per [antipatterns]. | |||
This section describes a number of things which IoT manufacturers | This section describes a number of things which IoT manufacturers | |||
have been observed to do in the field, each of which presents | have been observed to do in the field, each of which presents | |||
difficulties for MUD enforcement points. | difficulties for MUD enforcement points. | |||
4.1. Use of IP address literals inprotocol | 4.1. Use of IP Address Literals in-protocol | |||
A common pattern for a number of devices is to look for firmware | A common pattern for a number of devices is to look for firmware | |||
updates in a two-step process. An initial query is made (often over | updates in a two-step process. An initial query is made (often over | |||
HTTPS, sometimes with a POST, but the method is immaterial) to a | HTTPS, sometimes with a POST, but the method is immaterial) to a | |||
vendor system that knows whether an update is required. | vendor system that knows whether an update is required. | |||
The current firmware model of the device is sometimes provided and | The current firmware model of the device is sometimes provided and | |||
then the authoritative server provides a determination if a new | then the authoritative server provides a determination if a new | |||
version is required and, if so, what version. In simpler cases, an | version is required and, if so, what version. In simpler cases, an | |||
HTTPS endpoint is queried which provides the name and URL of the most | HTTPS endpoint is queried which provides the name and URL of the most | |||
skipping to change at page 9, line 26 ¶ | skipping to change at page 7, line 26 ¶ | |||
An authoritative server might be tempted to provide an IP address | An authoritative server might be tempted to provide an IP address | |||
literal inside the protocol: there are two arguments (anti-patterns) | literal inside the protocol: there are two arguments (anti-patterns) | |||
for doing this. | for doing this. | |||
The first is that it eliminates problems with firmware updates that | The first is that it eliminates problems with firmware updates that | |||
might be caused by lack of DNS, or incompatibilities with DNS. For | might be caused by lack of DNS, or incompatibilities with DNS. For | |||
instance a bug that causes interoperability issues with some | instance a bug that causes interoperability issues with some | |||
recursive servers would become unpatchable for devices that were | recursive servers would become unpatchable for devices that were | |||
forced to use that recursive resolver type. | forced to use that recursive resolver type. | |||
The second reason to avoid a IP address literal in the URL is when an | The second reason to avoid an IP address literal in the URL is when | |||
inhouse content-distribution system is involved that involves on- | an inhouse content-distribution system is involved that involves on- | |||
demand instances being added (or removed) from a cloud computing | demand instances being added (or removed) from a cloud computing | |||
architecture. | architecture. | |||
But, there are more problems with use of IP address literals for the | But, there are more problems with use of IP address literals for the | |||
location of the firmware. | location of the firmware. | |||
The first is that the update service server must decide whether to | The first is that the update service server must decide whether to | |||
provide an IPv4 or an IPv6 literal. A DNS name can contain both | provide an IPv4 or an IPv6 literal. A DNS name can contain both | |||
kinds of addresses, and can also contain many different IP addresses | kinds of addresses, and can also contain many different IP addresses | |||
of each kind. | of each kind. | |||
skipping to change at page 10, line 5 ¶ | skipping to change at page 8, line 5 ¶ | |||
contain the exact same IP address literals. It must also contain an | contain the exact same IP address literals. It must also contain an | |||
ACL for each address literal. DNS provides a useful indirection | ACL for each address literal. DNS provides a useful indirection | |||
method that naturally aggregates the addresses. | method that naturally aggregates the addresses. | |||
A third problem involves the use of HTTPS. IP address literals do | A third problem involves the use of HTTPS. IP address literals do | |||
not provide enough context for TLS ServerNameIndicator to be useful | not provide enough context for TLS ServerNameIndicator to be useful | |||
[RFC6066]. This limits the firmware repository to be a single tenant | [RFC6066]. This limits the firmware repository to be a single tenant | |||
on that IP address, and for IPv4 (at least), this is no longer a | on that IP address, and for IPv4 (at least), this is no longer a | |||
sustainable use of IP addresses. | sustainable use of IP addresses. | |||
Finally, it is common in some content-distribution networks (CDN) to | Finally, it is common in some Content Distribution Networks (CDNs) to | |||
use multiple layers of DNS CNAMEs in order to isolate the content- | use multiple layers of DNS CNAMEs in order to isolate the content- | |||
owner's naming system from changes in how the distribution network is | owner's naming system from changes in how the distribution network is | |||
organized. | organized. | |||
A non-deterministic name or address that is returned within the | A non-deterministic name or address that is returned within the | |||
update protocol, the MUD controller is unable to know what the name | update protocol, the MUD controller is unable to know what the name | |||
is. It is therefore unable to make sure that the communication to | is. It is therefore unable to make sure that the communication to | |||
retrieve the new firmware is permitted by the MUD enforcement point. | retrieve the new firmware is permitted by the MUD enforcement point. | |||
4.2. Use of non-deterministic DNS names in-protocol | 4.2. Use of Non-deterministic DNS Names in-protocol | |||
A second pattern is for a control protocol to connect to a known HTTP | A second pattern is for a control protocol to connect to a known HTTP | |||
endpoint. This is easily described in MUD. Within that control | endpoint. This is easily described in MUD. References within that | |||
protocol references are made to additional content at other URLs. | control protocol are made to additional content at other URLs. The | |||
The values of those URLs do not fit any easily described pattern and | values of those URLs do not fit any easily described pattern and may | |||
may point at arbitrary names. | point at arbitrary names. | |||
Those names are often within some third-party Content-Distribution- | Those names are often within some third-party CDN system, or may be | |||
Network (CDN) system, or may be arbitrary names in a cloud-provider | arbitrary names in a cloud-provider storage system (e.g., [AmazonS3], | |||
storage system (i.e., [AmazonS3], or [Akamai]). Some of the name | or [Akamai]). Some of the name components may be specified by the | |||
components may be specified by the provider. | provider. | |||
Such names may be unpredictably chosen by the content provider, and | Such names may be unpredictably chosen by the content provider, and | |||
not the content owner, and so impossible to insert into a MUD file. | not the content owner, and so impossible to insert into a MUD file. | |||
Even if the content provider chosen names are deterministic they may | Even if the content provider chosen names are deterministic they may | |||
change at a rate much faster than MUD files can be updated. | change at a rate much faster than MUD files can be updated. | |||
This in particular may apply to the location where firmware updates | This in particular may apply to the location where firmware updates | |||
may be retrieved. | may be retrieved. | |||
A solution is to use a deterministic DNS name, within the control of | A solution is to use a deterministic DNS name, within the control of | |||
the firmware vendor. This may be a problem if the content | the firmware vendor. This may be a problem if the content | |||
distribution network needs to reorganize which IP address is | distribution network needs to reorganize which IP address is | |||
responsible for which content, or if there is a desire to provide | responsible for which content, or if there is a desire to provide | |||
content in geographically relevant ways. | content in geographically relevant ways. | |||
The firmware vendor is therefore likely to be asked to point a CNAME | The firmware vendor is therefore likely to be asked to point a CNAME | |||
to the CDN network, to a name that might look like "g7.a.example", | to the CDN, to a name that might look like "g7.a.example", with the | |||
with the expectation that the CDN vendors DNS will do all the | expectation that the CDN vendors DNS will do all the appropriate work | |||
appropriate work to geolocate the transfer. This can be fine for a | to geolocate the transfer. This can be fine for a MUD file, as the | |||
MUD file, as the MUD controller, if located in the same geography as | MUD controller, if located in the same geography as the IoT device, | |||
the IoT device, can follow the CNAME, and can collect the set of | can follow the CNAME, and can collect the set of resulting IP | |||
resulting IP addresses, along with the TTL for each. The MUD | addresses, along with the TTL for each. The MUD controller can then | |||
controller can then take charge of refreshing that mapping at | take charge of refreshing that mapping at intervals driven by the | |||
intervals driven by the TTL. | TTL. | |||
In some cases, a complete set of geographically distributed servers | In some cases, a complete set of geographically distributed servers | |||
is known ahead of time, and the firmware vendor can list all those | is known ahead of time, and the firmware vendor can list all those | |||
addresses DNS for the the name that it lists in the MUD file. As | addresses in the DNS for the the name that it lists in the MUD file. | |||
long as the active set of addresses used by the CDN is a strict | As long as the active set of addresses used by the CDN is a strict | |||
subset of that list, then the geolocated name can be used for the | subset of that list, then the geolocated name can be used for the | |||
firmware download itself. This use of two addresses is ripe for | firmware download itself. This use of two addresses is ripe for | |||
confusion, however. | confusion, however. | |||
4.3. Use of a too generic DNS name | 4.3. Use of a Too Generic DNS Name | |||
Some CDNs make all customer content available at a single URL (such | Some CDNs make all customer content available at a single URL (such | |||
as s3.amazonaws.com). This seems to be ideal from a MUD point of | as "s3.example.com"). This seems to be ideal from a MUD point of | |||
view: a completely predictable URL. | view: a completely predictable URL. | |||
The problem is that a compromised device could then connect to the | The problem is that a compromised device could then connect to the | |||
contents of any bucket, potentially attacking the data from other | contents of any bucket, potentially attacking the data from other | |||
customers. | customers. | |||
Exactly what the risk is depends upon what the other customers are | Exactly what the risk is depends upon what the other customers are | |||
doing: it could be limited to simply causing a distributed denial-of- | doing: it could be limited to simply causing a distributed denial-of- | |||
service attack resulting in high costs to those customers, or such an | service attack resulting in high costs to those customers, or such an | |||
attack could potentially include writing content. | attack could potentially include writing content. | |||
Amazon has recognized the problems associated with this practice, and | Amazon has recognized the problems associated with this practice, and | |||
aims to change it to a virtual hosting model, as per | aims to change it to a virtual hosting model, as per | |||
[awss3virtualhosting]. | [awss3virtualhosting]. | |||
The MUD ACLs provide only for permitting end points (hostnames and | The MUD ACLs provide only for permitting end points (hostnames and | |||
ports), but do not filter URLs (nor could filtering be enforced | ports), but do not filter URLs (nor could filtering be enforced | |||
within HTTPS). | within HTTPS). | |||
5. DNS privacy and outsourcing versus MUD controllers | 5. DNS Privacy and Outsourcing versus MUD Controllers | |||
[RFC7858] and [RFC8094] provide for DNS over TLS (DoT) and DNS over | [RFC7858] and [RFC8094] provide for DoT and DoH. | |||
HTTPS (DoH). [I-D.ietf-dnsop-rfc8499bis] details the terms. But, | [I-D.ietf-dnsop-rfc8499bis] details the terms. But, even with the | |||
even with traditional DNS over Port-53 (Do53), it is possible to | unencrypted DNS (a.k.a. Do53), it is possible to outsource DNS | |||
outsource DNS queries to other public services, such as those | queries to other public services, such as those operated by Google, | |||
operated by Google, CloudFlare, Verisign, etc. | CloudFlare, Verisign, etc. | |||
For some users and classes of device, revealing the DNS queries to | For some users and classes of devices, revealing the DNS queries to | |||
those outside entities may constitute a privacy concern. For other | those outside entities may constitute a privacy concern. For other | |||
users the use of an insecure local resolver may constitute a privacy | users the use of an insecure local resolver may constitute a privacy | |||
concern. | concern. | |||
As described above in Section 3 the MUD controller needs to have | As described above in Section 3 the MUD controller needs to have | |||
access to the same resolver(s) as the IoT device. | access to the same resolver(s) as the IoT device. | |||
6. Recommendations to IoT device manufacturer on MUD and DNS usage | 6. Recommendations To IoT Device Manufacturers on MUD and DNS Usage | |||
Inclusion of a MUD file with IoT devices is operationally quite | Inclusion of a MUD file with IoT devices is operationally quite | |||
simple. It requires only a few small changes to the DHCP client code | simple. It requires only a few small changes to the DHCP client code | |||
to express the MUD URL. It can even be done without code changes via | to express the MUD URL. It can even be done without code changes via | |||
the use of a QR code affixed to the packaging (see [RFC9238]) | the use of a QR code affixed to the packaging (see [RFC9238]) | |||
The difficult part is determining what to put into the MUD file | The difficult part is determining what to put into the MUD file | |||
itself. There are currently tools that help with the definition and | itself. There are currently tools that help with the definition and | |||
analysis of MUD files, see [mudmaker]. The remaining difficulty is | analysis of MUD files, see [mudmaker]. The remaining difficulty is | |||
now the actual list of expected connections to put in the MUD file. | now the actual list of expected connections to put in the MUD file. | |||
skipping to change at page 12, line 30 ¶ | skipping to change at page 10, line 30 ¶ | |||
how DNS requests are made and resolved, and the goal of this section | how DNS requests are made and resolved, and the goal of this section | |||
is to make recommendations on how to modify IoT systems to work well | is to make recommendations on how to modify IoT systems to work well | |||
with MUD. | with MUD. | |||
6.1. Consistently use DNS | 6.1. Consistently use DNS | |||
For the reasons explained in Section 4.1, the most important | For the reasons explained in Section 4.1, the most important | |||
recommendation is to avoid using IP address literals in any protocol. | recommendation is to avoid using IP address literals in any protocol. | |||
Names should always be used. | Names should always be used. | |||
6.2. Use primary DNS names controlled by the manufacturer | 6.2. Use Primary DNS Names Controlled By The Manufacturer | |||
The second recommendation is to allocate and use names within zones | The second recommendation is to allocate and use names within zones | |||
controlled by the manufacturer. These names can be populated with an | controlled by the manufacturer. These names can be populated with an | |||
alias (see [I-D.ietf-dnsop-rfc8499bis] section 2) that points to the | alias (see [I-D.ietf-dnsop-rfc8499bis] section 2) that points to the | |||
production system. Ideally, a different name is used for each | production system. Ideally, a different name is used for each | |||
logical function, allowing for different rules in the MUD file to be | logical function, allowing for different rules in the MUD file to be | |||
enabled and disabled. | enabled and disabled. | |||
While it used to be costly to have a large number of aliases in a web | While it used to be costly to have a large number of aliases in a web | |||
server certificate, this is no longer the case. Wildcard | server certificate, this is no longer the case. Wildcard | |||
certificates are also commonly available which allow for an infinite | certificates are also commonly available which allow for an infinite | |||
number of possible names. | number of possible names. | |||
6.3. Use Content-Distribution Network with stable names | 6.3. Use Content-Distribution Network with Stable Names | |||
When aliases point to a Content-Distribution Network (CDN), prefer | When aliases point to a CDN, prefer stable names that point to | |||
stable names that point to appropriately load balanced targets. CDNs | appropriately load balanced targets. CDNs that employ very low time- | |||
that employ very low time-to-live (TTL) values for DNS make it harder | to-live (TTL) values for DNS make it harder for the MUD controller to | |||
for the MUD controller to get the same answer as the IoT Device. A | get the same answer as the IoT Device. A CDN that always returns the | |||
CDN that always returns the same set of A and AAAA records, but | same set of A and AAAA records, but permutes them to provide the best | |||
permutes them to provide the best one first provides a more reliable | one first provides a more reliable answer. | |||
answer. | ||||
6.4. Do not use geofenced names | 6.4. Do Not Use Tailored Responses to answer DNS Names | |||
Due to the problems with different answers from different DNS | [RFC7871] defines the edns-client-subnet (ECS) EDNS0 option, and | |||
servers, described above, a strong recommendation is to avoid using | explains how authoritative servers sometimes answer queries | |||
geofenced names. | differently based upon the IP address of the end system making the | |||
request. Ultimately, the decision is based upon some topological | ||||
notion of closeness. This is often used to provide tailored | ||||
responses to clients, providing them with a geographically | ||||
advantageous answer. | ||||
6.5. Prefer DNS servers learnt from DHCP/Route Advertisements | When the MUD controller makes it's DNS query, it is critical that it | |||
receive an answer which is based upon the same topological decision | ||||
as when the IoT device makes its query. | ||||
There are probably ways in which the MUD controller could use the | ||||
edns-client-subnet option to make a query that would get the same | ||||
treatment as when the IoT device makes its query. If this worked | ||||
then it would receive the same answer as the IoT device. | ||||
In practice it could be quite difficult if the IoT device uses a | ||||
different Internet connection, a different firewall, or a different | ||||
recursive DNS server. The edns-client-server might be ignored or | ||||
overridden by any of the DNS infrastructure. | ||||
Some tailored responses might only re-order the replies so that the | ||||
most preferred address is first. Such a system would be acceptable | ||||
if the MUD controller had a way to know that the list was complete. | ||||
But, due to the above problems, a strong recommendation is to avoid | ||||
using tailored responses as part of the names in the MUD file. | ||||
6.5. Prefer DNS Servers Learnt From DHCP/Route Advertisements | ||||
IoT Devices SHOULD prefer doing DNS with the DHCP provided DNS | IoT Devices SHOULD prefer doing DNS with the DHCP provided DNS | |||
servers. | servers. | |||
The ADD WG has written [I-D.ietf-add-dnr] and [I-D.ietf-add-ddr] to | The ADD WG has written [RFC9463] and [RFC9462] to provide information | |||
provide information to end devices on how to find locally provisioned | to end devices on how to find locally provisioned secure/private DNS | |||
secure/private DNS servers. | servers. | |||
Use of public resolvers instead of the provided DNS resolver, whether | Use of public resolvers instead of the provided DNS resolver, whether | |||
Do53, DoQ, DoT or DoH is discouraged. Should the network provide | Do53, DoQ, DoT or DoH is discouraged. Should the network provide | |||
such a resolver for use, then there is no reason not to use it, as | such a resolver for use, then there is no reason not to use it, as | |||
the network operator has clearly thought about this. | the network operator has clearly thought about this. | |||
Some manufacturers would like to have a fallback to using a public | Some manufacturers would like to have a fallback to using a public | |||
resolver to mitigate against local misconfiguration. There are a | resolver to mitigate against local misconfiguration. There are a | |||
number of reasons to avoid this, or at least do this very carefully. | number of reasons to avoid this, or at least do this very carefully. | |||
skipping to change at page 15, line 5 ¶ | skipping to change at page 13, line 26 ¶ | |||
would never contact the manufacturer for version information or for | would never contact the manufacturer for version information or for | |||
firmware itself. Instead, details of how to query and where to get | firmware itself. Instead, details of how to query and where to get | |||
the firmware would be provided as a MUD extension, and an Enterprise- | the firmware would be provided as a MUD extension, and an Enterprise- | |||
wide mechanism would retrieve firmware, and then distribute it | wide mechanism would retrieve firmware, and then distribute it | |||
internally. Aside from the bandwidth savings of downloading the | internally. Aside from the bandwidth savings of downloading the | |||
firmware only once, this also makes the number of devices active | firmware only once, this also makes the number of devices active | |||
confidential, and provides some evidence about which devices have | confidential, and provides some evidence about which devices have | |||
been upgraded and which ones might still be vulnerable. (The | been upgraded and which ones might still be vulnerable. (The | |||
unpatched devices might be lurking, powered off, lost in a closet) | unpatched devices might be lurking, powered off, lost in a closet) | |||
While a vendor proprietary scheme to distribute firmware updates | ||||
would satisfy some of these criteria, operators/Enterprises are less | ||||
likely to install one of these for every single device class. Home | ||||
(residential) users are unlikely to install any system that did not | ||||
provide service to all their devices (and came pre-installed on a | ||||
home router or other home network management system, such as a home | ||||
Network Attached Storage device), so only a system that was non- | ||||
proprietary is likely to be present. | ||||
8. Security Considerations | 8. Security Considerations | |||
This document deals with conflicting Security requirements: | This document deals with conflicting Security requirements: | |||
1. devices which an operator wants to manage using [RFC8520] | 1. devices which an operator wants to manage using [RFC8520] | |||
2. requirements for the devices to get access to network resources | 2. requirements for the devices to get access to network resources | |||
that may be critical to their continued safe operation. | that may be critical to their continued safe operation. | |||
This document takes the view that the two requirements do not need to | This document takes the view that the two requirements do not need to | |||
skipping to change at page 15, line 38 ¶ | skipping to change at page 14, line 20 ¶ | |||
[RFC1794] Brisco, T., "DNS Support for Load Balancing", RFC 1794, | [RFC1794] Brisco, T., "DNS Support for Load Balancing", RFC 1794, | |||
DOI 10.17487/RFC1794, April 1995, | DOI 10.17487/RFC1794, April 1995, | |||
<https://www.rfc-editor.org/info/rfc1794>. | <https://www.rfc-editor.org/info/rfc1794>. | |||
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate | [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate | |||
Requirement Levels", BCP 14, RFC 2119, | Requirement Levels", BCP 14, RFC 2119, | |||
DOI 10.17487/RFC2119, March 1997, | DOI 10.17487/RFC2119, March 1997, | |||
<https://www.rfc-editor.org/info/rfc2119>. | <https://www.rfc-editor.org/info/rfc2119>. | |||
[RFC7858] Hu, Z., Zhu, L., Heidemann, J., Mankin, A., Wessels, D., | ||||
and P. Hoffman, "Specification for DNS over Transport | ||||
Layer Security (TLS)", RFC 7858, DOI 10.17487/RFC7858, May | ||||
2016, <https://www.rfc-editor.org/info/rfc7858>. | ||||
[RFC8094] Reddy, T., Wing, D., and P. Patil, "DNS over Datagram | [RFC8094] Reddy, T., Wing, D., and P. Patil, "DNS over Datagram | |||
Transport Layer Security (DTLS)", RFC 8094, | Transport Layer Security (DTLS)", RFC 8094, | |||
DOI 10.17487/RFC8094, February 2017, | DOI 10.17487/RFC8094, February 2017, | |||
<https://www.rfc-editor.org/info/rfc8094>. | <https://www.rfc-editor.org/info/rfc8094>. | |||
[RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC | [RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC | |||
2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, | 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, | |||
May 2017, <https://www.rfc-editor.org/info/rfc8174>. | May 2017, <https://www.rfc-editor.org/info/rfc8174>. | |||
[RFC8520] Lear, E., Droms, R., and D. Romascanu, "Manufacturer Usage | [RFC8520] Lear, E., Droms, R., and D. Romascanu, "Manufacturer Usage | |||
skipping to change at page 16, line 33 ¶ | skipping to change at page 15, line 11 ¶ | |||
[antipatterns] | [antipatterns] | |||
"AntiPattern", 12 July 2021, | "AntiPattern", 12 July 2021, | |||
<https://www.agilealliance.org/glossary/antipattern>. | <https://www.agilealliance.org/glossary/antipattern>. | |||
[awss3virtualhosting] | [awss3virtualhosting] | |||
"Down to the Wire: AWS Delays 'Path-Style' S3 Deprecation | "Down to the Wire: AWS Delays 'Path-Style' S3 Deprecation | |||
at Last Minute", 12 July 2021, | at Last Minute", 12 July 2021, | |||
<https://techmonitor.ai/techonology/cloud/aws-s3-path- | <https://techmonitor.ai/techonology/cloud/aws-s3-path- | |||
deprecation>. | deprecation>. | |||
[I-D.ietf-add-ddr] | ||||
Pauly, T., Kinnear, E., Wood, C. A., McManus, P., and T. | ||||
Jensen, "Discovery of Designated Resolvers", Work in | ||||
Progress, Internet-Draft, draft-ietf-add-ddr-10, 5 August | ||||
2022, <https://datatracker.ietf.org/doc/html/draft-ietf- | ||||
add-ddr-10>. | ||||
[I-D.ietf-add-dnr] | ||||
Boucadair, M., Reddy.K, T., Wing, D., Cook, N., and T. | ||||
Jensen, "DHCP and Router Advertisement Options for the | ||||
Discovery of Network-designated Resolvers (DNR)", Work in | ||||
Progress, Internet-Draft, draft-ietf-add-dnr-16, 27 April | ||||
2023, <https://datatracker.ietf.org/doc/html/draft-ietf- | ||||
add-dnr-16>. | ||||
[mudmaker] "Mud Maker", 2019, <https://mudmaker.org>. | [mudmaker] "Mud Maker", 2019, <https://mudmaker.org>. | |||
[RFC6066] Eastlake 3rd, D., "Transport Layer Security (TLS) | [RFC6066] Eastlake 3rd, D., "Transport Layer Security (TLS) | |||
Extensions: Extension Definitions", RFC 6066, | Extensions: Extension Definitions", RFC 6066, | |||
DOI 10.17487/RFC6066, January 2011, | DOI 10.17487/RFC6066, January 2011, | |||
<https://www.rfc-editor.org/info/rfc6066>. | <https://www.rfc-editor.org/info/rfc6066>. | |||
[RFC7858] Hu, Z., Zhu, L., Heidemann, J., Mankin, A., Wessels, D., | ||||
and P. Hoffman, "Specification for DNS over Transport | ||||
Layer Security (TLS)", RFC 7858, DOI 10.17487/RFC7858, May | ||||
2016, <https://www.rfc-editor.org/info/rfc7858>. | ||||
[RFC7871] Contavalli, C., van der Gaast, W., Lawrence, D., and W. | ||||
Kumari, "Client Subnet in DNS Queries", RFC 7871, | ||||
DOI 10.17487/RFC7871, May 2016, | ||||
<https://www.rfc-editor.org/info/rfc7871>. | ||||
[RFC8484] Hoffman, P. and P. McManus, "DNS Queries over HTTPS | ||||
(DoH)", RFC 8484, DOI 10.17487/RFC8484, October 2018, | ||||
<https://www.rfc-editor.org/info/rfc8484>. | ||||
[RFC9230] Kinnear, E., McManus, P., Pauly, T., Verma, T., and C.A. | [RFC9230] Kinnear, E., McManus, P., Pauly, T., Verma, T., and C.A. | |||
Wood, "Oblivious DNS over HTTPS", RFC 9230, | Wood, "Oblivious DNS over HTTPS", RFC 9230, | |||
DOI 10.17487/RFC9230, June 2022, | DOI 10.17487/RFC9230, June 2022, | |||
<https://www.rfc-editor.org/info/rfc9230>. | <https://www.rfc-editor.org/info/rfc9230>. | |||
[RFC9238] Richardson, M., Latour, J., and H. Habibi Gharakheili, | [RFC9238] Richardson, M., Latour, J., and H. Habibi Gharakheili, | |||
"Loading Manufacturer Usage Description (MUD) URLs from QR | "Loading Manufacturer Usage Description (MUD) URLs from QR | |||
Codes", RFC 9238, DOI 10.17487/RFC9238, May 2022, | Codes", RFC 9238, DOI 10.17487/RFC9238, May 2022, | |||
<https://www.rfc-editor.org/info/rfc9238>. | <https://www.rfc-editor.org/info/rfc9238>. | |||
Appendix A. Appendices | [RFC9250] Huitema, C., Dickinson, S., and A. Mankin, "DNS over | |||
Dedicated QUIC Connections", RFC 9250, | ||||
DOI 10.17487/RFC9250, May 2022, | ||||
<https://www.rfc-editor.org/info/rfc9250>. | ||||
[RFC9462] Pauly, T., Kinnear, E., Wood, C. A., McManus, P., and T. | ||||
Jensen, "Discovery of Designated Resolvers", RFC 9462, | ||||
DOI 10.17487/RFC9462, November 2023, | ||||
<https://www.rfc-editor.org/info/rfc9462>. | ||||
[RFC9463] Boucadair, M., Ed., Reddy.K, T., Ed., Wing, D., Cook, N., | ||||
and T. Jensen, "DHCP and Router Advertisement Options for | ||||
the Discovery of Network-designated Resolvers (DNR)", | ||||
RFC 9463, DOI 10.17487/RFC9463, November 2023, | ||||
<https://www.rfc-editor.org/info/rfc9463>. | ||||
Appendix A. A Failing Strategy --- Anti-Patterns | ||||
Attempts to map IP addresses to names in real time fails for a number | ||||
of reasons: | ||||
1. it can not be done fast enough, | ||||
2. it reveals usage patterns of the devices, | ||||
3. the mappings are often incomplete, | ||||
4. Even if the mapping is present, due to virtual hosting, it may | ||||
not map back to the name used in the ACL. | ||||
This is not a successful strategy, it MUST NOT be used for the | ||||
reasons explained below. | ||||
A.1. Too Slow | ||||
Mappings of IP addresses to names requires a DNS lookup in the in- | ||||
addr.arpa or ip6.arpa space. For a cold DNS cache, this will | ||||
typically require 2 to 3 NS record lookups to locate the DNS server | ||||
that holds the information required. At 20 to 100 ms per round trip, | ||||
this easily adds up to significant time before the packet that caused | ||||
the lookup can be released. | ||||
While subsequent connections to the same site (and subsequent packets | ||||
in the same flow) will not be affected if the results are cached, the | ||||
effects will be felt. The ACL results can be cached for a period of | ||||
time given by the TTL of the DNS results, but the DNS lookup must be | ||||
repeated, e.g, in a few hours or days,when the cached IP address to | ||||
name binding expires. | ||||
A.2. Reveals Patterns of Usage | ||||
By doing the DNS lookups when the traffic occurs, then a passive | ||||
attacker can see when the device is active, and may be able to derive | ||||
usage patterns. They could determine when a home was occupied or | ||||
not. This does not require access to all on-path data, just to the | ||||
DNS requests to the bottom level of the DNS tree. | ||||
A.3. Mappings Are Often Incomplete | ||||
A service provider that fails to include an A or AAAA record as part | ||||
of their forward name publication will find that the new server is | ||||
simply not used. The operational feedback for that mistake is | ||||
immediate. The same is not true for reverse names: they can often be | ||||
incomplete or incorrect for months or even years without visible | ||||
effect on operations. | ||||
Service providers often find it difficult to update reverse maps in a | ||||
timely fashion, assuming that they can do it at all. Many cloud | ||||
based solutions dynamically assign IP addresses to services, often as | ||||
the service grows and shrinks, reassigning those IP addresses to | ||||
other services quickly. The use of HTTP 1.1 Virtual Hosting may | ||||
allow addresses and entire front-end systems to be re-used | ||||
dynamically without even reassigning the IP addresses. | ||||
In some cases there are multiple layers of CNAME between the original | ||||
name and the target service name. This is often due to a load | ||||
balancing layer in the DNS, followed by a load balancing layer at the | ||||
HTTP level. | ||||
The reverse name for the IP address of the load balancer usually does | ||||
not change. If hundreds of web services are funneled through the | ||||
load balancer, it would require hundreds of PTR records to be | ||||
deployed. This would easily exceed the UDP/DNS and EDNS0 limits, and | ||||
require all queries to use TCP, which would further slow down loading | ||||
of the records. | ||||
The enumeration of all services/sites that have been at that load | ||||
balancer might also constitute a security concern. To limit churn of | ||||
DNS PTR records, and reduce failures of the MUD ACLs, operators would | ||||
want to add all possible names for each reverse name, whether or not | ||||
the DNS load balancing in the forward DNS space lists that end-point | ||||
at that moment. | ||||
A.4. Forward Names Can Have Wildcards | ||||
In some large hosting providers content is hosted through a domain | ||||
name that is published as a DNS wildcard (and uses a wildcard | ||||
certificate). For instance, github.io, which is used for hosted | ||||
content, including the Editors' copy of internet drafts stored on | ||||
github, does not actually publish any names. Instead, a wildcard | ||||
exists to answer all potential names: requests are routed appropriate | ||||
once they are received. | ||||
This kind of system works well for self-managed hosted content. | ||||
However, while it is possible to insert up to a few dozen PTR | ||||
records, many thousand entries are not possible, nor is it possible | ||||
to deal with the unlimited (infinite) number of possibilities that a | ||||
wildcard supports. | ||||
It would be therefore impossible for the PTR reverse lookup to ever | ||||
work with these wildcard names. | ||||
Contributors | Contributors | |||
Tirumaleswar Reddy | Tirumaleswar Reddy | |||
Nokia | Nokia | |||
Authors' Addresses | Authors' Addresses | |||
Michael Richardson | Michael Richardson | |||
Sandelman Software Works | Sandelman Software Works | |||
End of changes. 56 change blocks. | ||||
273 lines changed or deleted | 320 lines changed or added | |||
This html diff was produced by rfcdiff 1.45. The latest version is available from http://tools.ietf.org/tools/rfcdiff/ |