draft-ietf-opsawg-mud-iot-dns-considerations-12.txt | draft-ietf-opsawg-mud-iot-dns-considerations-16.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: 4 January 2025 Huawei Technologies | |||
8 February 2024 | 3 July 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-16 | |||
Abstract | Abstract | |||
This document details concerns about how Internet of Things devices | This document details considerations about how Internet of Things | |||
use IP addresses and DNS names. The issue becomes acute as network | (IoT) devices use IP addresses and DNS names. These concerns become | |||
operators begin deploying RFC8520 Manufacturer Usage Description | acute as network operators begin deploying RFC 8520 Manufacturer | |||
(MUD) definitions to control device access. | Usage Description (MUD) definitions to control device access. | |||
This document makes recommendations on when and how to use DNS names | Also, 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 | |||
skipping to change at page 2, line 10 ¶ | skipping to change at page 2, line 10 ¶ | |||
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 4 January 2025. | |||
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 DNS names to | |||
3.1. Failing strategy . . . . . . . . . . . . . . . . . . . . 4 | addresses . . . . . . . . . . . . . . . . . . . . . . . . 4 | |||
3.1.1. Too slow . . . . . . . . . . . . . . . . . . . . . . 5 | 3.1. Non-Deterministic Mappings . . . . . . . . . . . . . . . 5 | |||
3.1.2. Reveals patterns of usage . . . . . . . . . . . . . . 5 | 4. DNS and IP Anti-Patterns for IoT Device Manufacturers . . . . 7 | |||
3.1.3. Mappings are often incomplete . . . . . . . . . . . . 5 | 4.1. Use of IP Address Literals . . . . . . . . . . . . . . . 7 | |||
3.1.4. Forward names can have wildcards . . . . . . . . . . 6 | 4.2. Use of Non-deterministic DNS Names in-protocol . . . . . 8 | |||
3.2. A successful strategy . . . . . . . . . . . . . . . . . . 6 | 4.3. Use of a Too Generic DNS Name . . . . . . . . . . . . . . 9 | |||
4. DNS and IP Anti-Patterns for IoT device Manufacturers . . . . 8 | 5. DNS Privacy and Outsourcing versus MUD Controllers . . . . . 10 | |||
4.1. Use of IP address literals inprotocol . . . . . . . . . . 8 | 6. Recommendations To IoT Device Manufacturers on MUD and DNS | |||
4.2. Use of non-deterministic DNS names in-protocol . . . . . 10 | Usage . . . . . . . . . . . . . . . . . . . . . . . . . . 10 | |||
4.3. Use of a too generic DNS name . . . . . . . . . . . . . . 11 | 6.1. Consistently use DNS . . . . . . . . . . . . . . . . . . 10 | |||
5. DNS privacy and outsourcing versus MUD controllers . . . . . 11 | 6.2. Use Primary DNS Names Controlled By The Manufacturer . . 11 | |||
6. Recommendations to IoT device manufacturer on MUD and DNS | 6.3. Use Content-Distribution Network with Stable DNS Names . 11 | |||
usage . . . . . . . . . . . . . . . . . . . . . . . . . . 12 | 6.4. Do Not Use Tailored Responses to answer DNS Names . . . . 11 | |||
6.1. Consistently use DNS . . . . . . . . . . . . . . . . . . 12 | 6.5. Prefer DNS Servers Learnt From DHCP/Router | |||
6.2. Use primary DNS names controlled by the manufacturer . . 12 | Advertisements . . . . . . . . . . . . . . . . . . . . . 12 | |||
6.3. Use Content-Distribution Network with stable names . . . 12 | 7. Interactions with mDNS and DNSSD . . . . . . . . . . . . . . 12 | |||
6.4. Do not use geofenced names . . . . . . . . . . . . . . . 13 | 8. Privacy Considerations . . . . . . . . . . . . . . . . . . . 13 | |||
6.5. Prefer DNS servers learnt from DHCP/Route | 9. Security Considerations . . . . . . . . . . . . . . . . . . . 14 | |||
Advertisements . . . . . . . . . . . . . . . . . . . . . 13 | 10. References . . . . . . . . . . . . . . . . . . . . . . . . . 14 | |||
7. Privacy Considerations . . . . . . . . . . . . . . . . . . . 13 | 10.1. Normative References . . . . . . . . . . . . . . . . . . 15 | |||
8. Security Considerations . . . . . . . . . . . . . . . . . . . 15 | 10.2. Informative References . . . . . . . . . . . . . . . . . 15 | |||
9. References . . . . . . . . . . . . . . . . . . . . . . . . . 15 | Appendix A. A Failing Strategy --- Anti-Patterns . . . . . . . . 18 | |||
9.1. Normative References . . . . . . . . . . . . . . . . . . 15 | A.1. Too Slow . . . . . . . . . . . . . . . . . . . . . . . . 18 | |||
9.2. Informative References . . . . . . . . . . . . . . . . . 16 | A.2. Reveals Patterns of Usage . . . . . . . . . . . . . . . . 18 | |||
Appendix A. Appendices . . . . . . . . . . . . . . . . . . . . . 17 | A.3. Mappings Are Often Incomplete . . . . . . . . . . . . . . 19 | |||
Contributors . . . . . . . . . . . . . . . . . . . . . . . . . . 17 | A.4. Forward DNS Names Can Have Wildcards . . . . . . . . . . 19 | |||
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 17 | Contributors . . . . . . . . . . . . . . . . . . . . . . . . . . 20 | |||
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 20 | ||||
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 | Concretely, 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 8 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 9 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 | The term "anti-pattern" comes from agile software design literature, | |||
name that is published as a DNS wildcard (and uses a wildcard | as per [antipatterns]. | |||
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. | CDN refers to Content Distribution Networks, such as described by | |||
However, while it is possible to insert up to a few dozen PTR | [RFC6707], Section 1.1. | |||
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 DNS 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 DNS 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. | ||||
The most important one is that the mapping of the names to IP | 3.1. Non-Deterministic Mappings | |||
addresses may be non-deterministic. [RFC1794] describes the very | ||||
common mechanism that returns DNS A (or reasonably AAAA) records in a | The most important one is that the mapping of the DNS names to IP | |||
permuted order. This is known as Round Robin DNS, and it has been | addresses may be non-deterministic. | |||
used for many decades. The device is intended to use the first IP | ||||
address that is returned, and each query returns addresses in a | [RFC1794] describes the very common mechanism that returns DNS A (or | |||
different ordering, splitting the load among many servers. | reasonably AAAA) records in a permuted order. This is known as Round | |||
Robin DNS, and it has been used for many decades. The historical | ||||
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 23 ¶ | skipping to change at page 6, line 35 ¶ | |||
The solution of using the same caching recursive resolver as the | The solution of using the same caching recursive resolver as the | |||
target device is very simple when the MUD controller is located in a | target device is very simple when the MUD controller is located in a | |||
residential CPE device. The device is usually also the policy | residential CPE device. The device is usually also the policy | |||
enforcement point for the ACLs, and a caching resolver is typically | enforcement point for the ACLs, and a caching resolver is typically | |||
located on the same device. In addition to convenience, there is a | located on the same device. In addition to convenience, there is a | |||
shared fate advantage: as all three components are running on the | shared fate advantage: as all three components are running on the | |||
same device, if the device is rebooted, clearing the cache, then all | same device, if the device is rebooted, clearing the cache, then all | |||
three components will get restarted when the device is restarted. | three components will get restarted when the device is restarted. | |||
Where the solution is more complex is when the MUD controller is | Where the solution is more complex and sometimes more fragile is when | |||
located elsewhere in an Enterprise, or remotely in a cloud such as | the MUD controller is located elsewhere in an Enterprise, or remotely | |||
when a Software Defined Network (SDN) is used to manage the ACLs. | in a cloud such as when a Software Defined Network (SDN) is used to | |||
The DNS servers for a particular device may not be known to the MUD | manage the ACLs. The DNS servers for a particular device may not be | |||
controller, nor the MUD controller be even permitted to make | known to the MUD controller, nor the MUD controller be even permitted | |||
recursive queries to that server if it is known. In this case, | to make recursive queries to that server if it is known. In this | |||
additional installation specific mechanisms are probably needed to | case, additional installation specific mechanisms are probably needed | |||
get the right view of the DNS. | to get the right view of the DNS. | |||
4. DNS and IP Anti-Patterns for IoT device Manufacturers | A critical failure can occur when the device makes a new DNS request | |||
and receives a new set of IP addresses, but the MUD controller's copy | ||||
of the addresses has not yet reached their time to live. In that | ||||
case, the MUD controller still has the old address(es) implemented in | ||||
the ACLs, but the IoT device has a new address not previously | ||||
returned to the MUD controller. This can result in a connectivity | ||||
failure. | ||||
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 | |||
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 vendor's authoritative server provides a determination if a | |||
version is required and, if so, what version. In simpler cases, an | new version is required and, if so, what version. In simpler cases, | |||
HTTPS endpoint is queried which provides the name and URL of the most | an HTTPS endpoint is queried which provides the name and URL of the | |||
recent firmware. | most recent firmware. | |||
The authoritative upgrade server then responds with a URL of a | The authoritative upgrade server then responds with a URL of a | |||
firmware blob that the device should download and install. Best | firmware blob that the device should download and install. Best | |||
practice is that firmware is either signed internally ([RFC9019]) so | practice is that firmware is either signed internally ([RFC9019]) so | |||
that it can be verified, or a hash of the blob is provided. | that it can be verified, or a hash of the blob is provided. | |||
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. An argument for doing this is that it | |||
for doing this. | eliminates problems with firmware updates that might be caused by | |||
lack of DNS, or incompatibilities with DNS. For instance a bug that | ||||
The first is that it eliminates problems with firmware updates that | causes interoperability issues with some recursive servers would | |||
might be caused by lack of DNS, or incompatibilities with DNS. For | become unpatchable for devices that were forced to use that recursive | |||
instance a bug that causes interoperability issues with some | resolver type. | |||
recursive servers would become unpatchable for devices that were | ||||
forced to use that recursive resolver type. | ||||
The second reason to avoid a IP address literal in the URL is when an | ||||
inhouse content-distribution system is involved that involves on- | ||||
demand instances being added (or removed) from a cloud computing | ||||
architecture. | ||||
But, there are more problems with use of IP address literals for the | But, there are several problems with the use of IP address literals | |||
location of the firmware. | for the 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, assuming that only one URL can be | |||
kinds of addresses, and can also contain many different IP addresses | provided. A DNS name can contain both kinds of addresses, and can | |||
of each kind. | also contain many different IP addresses of each kind. An update | |||
server might believe that if the connection was on IPv4, that an IPv4 | ||||
literate would be acceptable, but due to NAT64 [RFC6146] a device | ||||
with only IPv6 connectivity will often be able to reach an IPv4 | ||||
firmware update server by name (through DNS64 [RFC6147]), but not be | ||||
able to reach arbitrary IPv4 address. | ||||
The second problem is that it forces the MUD file definition to | A MUD file definition for this access would need to resolve to the | |||
contain the exact same IP address literals. It must also contain an | set of IP addresses that might be returned by the update server. | |||
ACL for each address literal. DNS provides a useful indirection | This can be done with IP address literals in the MUD file, but this | |||
method that naturally aggregates the addresses. | may require continuing updates to the MUD file if the addresses | |||
change frequently. A DNS name in the MUD could resolve to the set of | ||||
all possible IPv4 and IPv6 addresses that would be used, with DNS | ||||
providing a level of indirection that obviates the need to update the | ||||
MUD file itself. | ||||
A third problem involves the use of HTTPS. IP address literals do | A third problem involves the use of HTTPS. It is often more | |||
not provide enough context for TLS ServerNameIndicator to be useful | difficult to get TLS certificates for an IP address, and so it is | |||
[RFC6066]. This limits the firmware repository to be a single tenant | less likely that the firmware download will be protected by TLS. An | |||
on that IP address, and for IPv4 (at least), this is no longer a | IP address literal in the TLS ServerNameIndicator [RFC6066], might | |||
sustainable use of IP addresses. | not provide enough context for a web server to distinguish which of | |||
potentially many tenants, the client wishes to reach. This then | ||||
drives the use of an IP address per-tenant, and for IPv4 (at least), | ||||
this is no longer a 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 | When a name or address is returned within an update protocol for | |||
update protocol, the MUD controller is unable to know what the name | which a MUD rule cannot be written, then the MUD controller is unable | |||
is. It is therefore unable to make sure that the communication to | to authorize the connection. In order for the connection to be | |||
retrieve the new firmware is permitted by the MUD enforcement point. | authorized, the set of names returned within the update protocol | |||
needs to be known ahead of time, and must be from a finite set of | ||||
possibilities. Such a set of names or addresses can be placed into | ||||
the MUD file as an ACL in advance, and the connections authorized. | ||||
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 DNS names. | |||
Those names are often within some third-party Content-Distribution- | ||||
Network (CDN) system, or may be arbitrary names in a cloud-provider | ||||
storage system (i.e., [AmazonS3], or [Akamai]). Some of the name | ||||
components may be specified by the provider. | ||||
Such names may be unpredictably chosen by the content provider, and | Those DNS names are often within some third-party CDN system, or may | |||
not the content owner, and so impossible to insert into a MUD file. | be arbitrary DNS names in a cloud-provider storage system (e.g., | |||
[AmazonS3], or [Akamai]). Some of the name components may be | ||||
specified by the third party CDN provider. | ||||
Even if the content provider chosen names are deterministic they may | Such DNS names may be unpredictably chosen by the CDN, and not the | |||
change at a rate much faster than MUD files can be updated. | device manufacturer, and so impossible to insert into a MUD file. | |||
Implementation of the CDN system may also involve HTTP redirections | ||||
to downstream CDN systems. | ||||
This in particular may apply to the location where firmware updates | Even if the CDN provider's chosen DNS names are deterministic they | |||
may be retrieved. | may change at a rate much faster than MUD files can be updated. | |||
A solution is to use a deterministic DNS name, within the control of | This situation applies to firmware updates, but also applies to many | |||
the firmware vendor. This may be a problem if the content | other kinds of content: video content, in-game content, etc. | |||
distribution network needs to reorganize which IP address is | ||||
responsible for which content, or if there is a desire to provide | ||||
content in geographically relevant ways. | ||||
The firmware vendor is therefore likely to be asked to point a CNAME | A solution may be to use a deterministic DNS name, within the control | |||
to the CDN network, to a name that might look like "g7.a.example", | of the device manufacturer. The device manufacturer is asked to | |||
with the expectation that the CDN vendors DNS will do all the | point a CNAME to the CDN, to a name that might look like | |||
appropriate work to geolocate the transfer. This can be fine for a | "g7.a.example", with the expectation that the CDN vendors DNS will do | |||
MUD file, as the MUD controller, if located in the same geography as | all the appropriate work to geolocate the transfer. This can be fine | |||
the IoT device, can follow the CNAME, and can collect the set of | for a MUD file, as the MUD controller, if located in the same | |||
resulting IP addresses, along with the TTL for each. The MUD | geography as the IoT device, can follow the CNAME, and can collect | |||
controller can then take charge of refreshing that mapping at | the set of resulting IP addresses, along with the TTL for each. The | |||
MUD controller can then take charge of refreshing that mapping at | ||||
intervals driven by the TTL. | intervals driven by the 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 | may be known ahead of time (or that it changes very slowly), and the | |||
addresses DNS for the the name that it lists in the MUD file. As | device manufacturer can list all those IP addresses in the DNS for | |||
long as the active set of addresses used by the CDN is a strict | the the name that it lists in the MUD file. As long as the active | |||
subset of that list, then the geolocated name can be used for the | set of addresses used by the CDN is a strict subset of that list, | |||
firmware download itself. This use of two addresses is ripe for | then the geolocated name can be used for the content download itself. | |||
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. If the IoT device | |||
does not use the DNS servers provided to it via DHCP or Router | ||||
Advertisements, then the MUD controller will need to be told which | ||||
servers will in fact be used. As yet, there is no protocol to do | ||||
this, but future work could provide this as an extension to MUD. | ||||
6. Recommendations to IoT device manufacturer on MUD and DNS usage | Until such time as such a protocol exists, the best practice is for | |||
the IoT device to always use the DNS servers provided by DHCP or | ||||
Router Advertisements. | ||||
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 28 ¶ | skipping to change at page 10, line 52 ¶ | |||
This document discusses a number of challenges that occur relating to | This document discusses a number of challenges that occur relating to | |||
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. | DNS 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 DNS names within | |||
controlled by the manufacturer. These names can be populated with an | zones controlled by the manufacturer. These DNS names can be | |||
alias (see [I-D.ietf-dnsop-rfc8499bis] section 2) that points to the | populated with an alias (see [I-D.ietf-dnsop-rfc8499bis] section 2) | |||
production system. Ideally, a different name is used for each | that points to the production system. Ideally, a different name is | |||
logical function, allowing for different rules in the MUD file to be | used for each logical function, allowing for different rules in the | |||
enabled and disabled. | MUD file to be 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 DNS names. | |||
6.3. Use Content-Distribution Network with stable names | 6.3. Use Content-Distribution Network with Stable DNS Names | |||
When aliases point to a Content-Distribution Network (CDN), prefer | When aliases point to a CDN, prefer stable DNS 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 its 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. | ||||
IoT Devices SHOULD prefer doing DNS with the DHCP provided DNS | There are probably ways in which the MUD controller could use the | |||
servers. | 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. | ||||
The ADD WG has written [I-D.ietf-add-dnr] and [I-D.ietf-add-ddr] to | In practice it could be quite difficult if the IoT device uses a | |||
provide information to end devices on how to find locally provisioned | different Internet connection, a different firewall, or a different | |||
secure/private DNS servers. | recursive DNS server. The edns-client-server might be ignored or | |||
overridden by any of the DNS infrastructure. | ||||
Use of public resolvers instead of the provided DNS resolver, whether | Some tailored responses might only re-order the replies so that the | |||
Do53, DoQ, DoT or DoH is discouraged. Should the network provide | most preferred address is first. Such a system would be acceptable | |||
such a resolver for use, then there is no reason not to use it, as | if the MUD controller had a way to know that the list was complete. | |||
the network operator has clearly thought about this. | ||||
But, due to the above problems, a strong recommendation is to avoid | ||||
using tailored responses as part of the DNS names in the MUD file. | ||||
6.5. Prefer DNS Servers Learnt From DHCP/Router Advertisements | ||||
The best practice is for IoT Devices to do DNS with the DHCP provided | ||||
DNS servers, or DNS servers learnt from Router Advertisements | ||||
[RFC8106]. | ||||
The ADD WG has written [RFC9463] and [RFC9462] to provide information | ||||
to end devices on how to find locally provisioned secure/private DNS | ||||
servers. | ||||
Use of public resolvers instead of the locally provided DNS resolver, | ||||
whether Do53, DoQ, DoT or DoH is discouraged. | ||||
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, detailed in Section 6.4. The public | |||
resolver might not return the same tailored names that the MUD | ||||
controller would get. | ||||
It is recommended that use of non-local resolvers is only done when | It is recommended that use of non-local resolvers is only done when | |||
the locally provided resolvers provide no answers to any queries at | the locally provided resolvers provide no answers to any queries at | |||
all, and do so repeatedly. The use of the operator provided | all, and do so repeatedly. The status of the operator provided | |||
resolvers SHOULD be retried on a periodic basis, and once they | resolvers needs to be re-evaluated on a periodic basis. | |||
answer, there SHOULD be no further attempts to contact public | ||||
resolvers. | ||||
Finally, the list of public resolvers that might be contacted MUST be | Finally, if a device will ever attempt to use a non-local resolvers, | |||
listed in the MUD file as destinations that are to be permitted! | then the address of that resolver needs to be listed in the MUD file | |||
This should include the port numbers (i.e., 53, 853 for DoT, 443 for | as destinations that are to be permitted. This needs to include the | |||
DoH) that will be used as well. | port numbers (i.e., 53, 853 for DoT, 443 for DoH) that will be used | |||
as well. | ||||
7. Privacy Considerations | 7. Interactions with mDNS and DNSSD | |||
The use of non-local DNS servers exposes the list of names resolved | Unicast DNS requests are not the only way to map names to IP | |||
to a third party, including passive eavesdroppers. | addresses. IoT devices might also use mDNS [RFC6762], both to be | |||
discovered by other devices, and also to discover other devices. | ||||
mDNS replies include A and AAAA records, and it is conceivable that | ||||
these replies contain addresses which are not local to the link on | ||||
which they are made. This could be the result of another device | ||||
which contains malware. An unsuspecting IoT device could be led to | ||||
contact some external host as a result. Protecting against such | ||||
things is one of the benefits of MUD. | ||||
In the unlikely case that the external host has been listed as a | ||||
legitimate destination in a MUD file, then communication will | ||||
continue as expected. As an example of this, an IoT device might | ||||
look for a name like "update.local" in order to find a source of | ||||
firmware updates. It could be led to connect to some external host | ||||
that was listed as "update.example" in the MUD file. This should | ||||
work fine if the name "update.example" does not require any kind of | ||||
tailored reply. | ||||
In residential networks there has typically not been more than one | ||||
network (although this is changing through work like | ||||
[I-D.ietf-snac-simple]), but on campus or enterprise networks, having | ||||
more than one network is not unusual. In such networks, mDNS is | ||||
being replaced with DNS-SD [RFC8882], and in such a situation, | ||||
connections could be initiated to other parts of the network. Such | ||||
connections might traverse the MUD policy enforcement point (an | ||||
intra-department firewall), and could very well be rejected because | ||||
the MUD controller did not know about that interaction. | ||||
[RFC8250] includes a number of provisions for controlling internal | ||||
communications, including complex communications like same | ||||
manufacturer ACLs. To date, this aspect of MUD has been difficult to | ||||
describe. This document does not consider internal communications to | ||||
be in scope. | ||||
8. Privacy Considerations | ||||
The use of non-local DNS servers exposes the list of DNS names | ||||
resolved to a third party, including passive eavesdroppers. | ||||
The use of DoT and DoH eliminates the threat from passive | The use of DoT and DoH eliminates the threat from passive | |||
eavesdropping, but still exposes the list to the operator of the DoT | eavesdropping, but still exposes the list to the operator of the DoT | |||
or DoH server. There are additional methods to help preserve | or DoH server. There are additional methods to help preserve | |||
privacy, such as described by [RFC9230]. | privacy, such as described by [RFC9230]. | |||
The use of unencrypted (Do53) requests to a local DNS server exposes | The use of unencrypted (Do53) requests to a local DNS server exposes | |||
the list to any internal passive eavesdroppers, and for some | the list to any internal passive eavesdroppers, and for some | |||
situations that may be significant, particularly if unencrypted Wi-Fi | situations that may be significant, particularly if unencrypted Wi-Fi | |||
is used. Use of Encrypted DNS connection to a local DNS recursive | is used. | |||
resolver is the preferred choice. | ||||
Use of Encrypted DNS connection to a local DNS recursive resolver is | ||||
the preferred choice. | ||||
IoT devices that reach out to the manufacturer at regular intervals | IoT devices that reach out to the manufacturer at regular intervals | |||
to check for firmware updates are informing passive eavesdroppers of | to check for firmware updates are informing passive eavesdroppers of | |||
the existence of a specific manufacturer's device being present at | the existence of a specific manufacturer's device being present at | |||
the origin location. | the origin location. | |||
Identifying the IoT device type empowers the attacker to launch | Identifying the IoT device type empowers the attacker to launch | |||
targeted attacks to the IoT device (e.g., Attacker can take advantage | targeted attacks to the IoT device (e.g., Attacker can take advantage | |||
of any known vulnerability on the device). | of any known vulnerability on the device). | |||
skipping to change at page 14, line 35 ¶ | skipping to change at page 14, line 32 ¶ | |||
their update queries. For instance, contracting out the update | their update queries. For instance, contracting out the update | |||
notification service to a third party that deals with a large variety | notification service to a third party that deals with a large variety | |||
of devices would provide a level of defense against passive | of devices would provide a level of defense against passive | |||
eavesdropping. Other update mechanisms should be investigated, | eavesdropping. Other update mechanisms should be investigated, | |||
including use of DNSSEC signed TXT records with current version | including use of DNSSEC signed TXT records with current version | |||
information. This would permit DoT or DoH to convey the update | information. This would permit DoT or DoH to convey the update | |||
notification in a private fashion. This is particularly powerful if | notification in a private fashion. This is particularly powerful if | |||
a local recursive DoT server is used, which then communicates using | a local recursive DoT server is used, which then communicates using | |||
DoT over the Internet. | DoT over the Internet. | |||
The more complex case of section Section 4.1 postulates that the | The more complex case of Section 4.1 postulates that the version | |||
version number needs to be provided to an intelligent agent that can | number needs to be provided to an intelligent agent that can decide | |||
decide the correct route to do upgrades. [RFC9019] provides a wide | the correct route to do upgrades. [RFC9019] provides a wide variety | |||
variety of ways to accomplish the same thing without having to | of ways to accomplish the same thing without having to divulge the | |||
divulge the current version number. | current version number. | |||
The use of a publicly specified firmware update protocol would also | ||||
enhance privacy of IoT devices. In such a system, the IoT device | ||||
would never contact the manufacturer for version information or for | ||||
firmware itself. Instead, details of how to query and where to get | ||||
the firmware would be provided as a MUD extension, and an Enterprise- | ||||
wide mechanism would retrieve firmware, and then distribute it | ||||
internally. Aside from the bandwidth savings of downloading the | ||||
firmware only once, this also makes the number of devices active | ||||
confidential, and provides some evidence about which devices have | ||||
been upgraded and which ones might still be vulnerable. (The | ||||
unpatched devices might be lurking, powered off, lost in a closet) | ||||
8. Security Considerations | 9. 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 | |||
be in conflict, but resolving the conflict requires careful planning | be in conflict, but resolving the conflict requires careful planning | |||
on how the DNS can be safely and effectively used by MUD controllers | on how the DNS can be safely and effectively used by MUD controllers | |||
and IoT devices. | and IoT devices. | |||
9. References | 10. References | |||
10.1. Normative References | ||||
9.1. Normative References | ||||
[I-D.ietf-dnsop-rfc8499bis] | [I-D.ietf-dnsop-rfc8499bis] | |||
Hoffman, P. E. and K. Fujiwara, "DNS Terminology", Work in | Hoffman, P. E. and K. Fujiwara, "DNS Terminology", Work in | |||
Progress, Internet-Draft, draft-ietf-dnsop-rfc8499bis-10, | Progress, Internet-Draft, draft-ietf-dnsop-rfc8499bis-10, | |||
25 September 2023, <https://datatracker.ietf.org/doc/html/ | 25 September 2023, <https://datatracker.ietf.org/doc/html/ | |||
draft-ietf-dnsop-rfc8499bis-10>. | draft-ietf-dnsop-rfc8499bis-10>. | |||
[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>. | |||
[RFC8250] Elkins, N., Hamilton, R., and M. Ackermann, "IPv6 | ||||
Performance and Diagnostic Metrics (PDM) Destination | ||||
Option", RFC 8250, DOI 10.17487/RFC8250, September 2017, | ||||
<https://www.rfc-editor.org/info/rfc8250>. | ||||
[RFC8520] Lear, E., Droms, R., and D. Romascanu, "Manufacturer Usage | [RFC8520] Lear, E., Droms, R., and D. Romascanu, "Manufacturer Usage | |||
Description Specification", RFC 8520, | Description Specification", RFC 8520, | |||
DOI 10.17487/RFC8520, March 2019, | DOI 10.17487/RFC8520, March 2019, | |||
<https://www.rfc-editor.org/info/rfc8520>. | <https://www.rfc-editor.org/info/rfc8520>. | |||
[RFC9019] Moran, B., Tschofenig, H., Brown, D., and M. Meriac, "A | [RFC9019] Moran, B., Tschofenig, H., Brown, D., and M. Meriac, "A | |||
Firmware Update Architecture for Internet of Things", | Firmware Update Architecture for Internet of Things", | |||
RFC 9019, DOI 10.17487/RFC9019, April 2021, | RFC 9019, DOI 10.17487/RFC9019, April 2021, | |||
<https://www.rfc-editor.org/info/rfc9019>. | <https://www.rfc-editor.org/info/rfc9019>. | |||
9.2. Informative References | 10.2. Informative References | |||
[Akamai] "Akamai", 2019, | [Akamai] "Akamai", 2019, | |||
<https://en.wikipedia.org/wiki/Akamai_Technologies>. | <https://en.wikipedia.org/wiki/Akamai_Technologies>. | |||
[AmazonS3] "Amazon S3", 2019, | [AmazonS3] "Amazon S3", 2019, | |||
<https://en.wikipedia.org/wiki/Amazon_S3>. | <https://en.wikipedia.org/wiki/Amazon_S3>. | |||
[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] | [I-D.ietf-snac-simple] | |||
Pauly, T., Kinnear, E., Wood, C. A., McManus, P., and T. | Lemon, T. and J. Hui, "Automatically Connecting Stub | |||
Jensen, "Discovery of Designated Resolvers", Work in | Networks to Unmanaged Infrastructure", Work in Progress, | |||
Progress, Internet-Draft, draft-ietf-add-ddr-10, 5 August | Internet-Draft, draft-ietf-snac-simple-04, 4 March 2024, | |||
2022, <https://datatracker.ietf.org/doc/html/draft-ietf- | <https://datatracker.ietf.org/doc/html/draft-ietf-snac- | |||
add-ddr-10>. | simple-04>. | |||
[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>. | |||
[RFC6146] Bagnulo, M., Matthews, P., and I. van Beijnum, "Stateful | ||||
NAT64: Network Address and Protocol Translation from IPv6 | ||||
Clients to IPv4 Servers", RFC 6146, DOI 10.17487/RFC6146, | ||||
April 2011, <https://www.rfc-editor.org/info/rfc6146>. | ||||
[RFC6147] Bagnulo, M., Sullivan, A., Matthews, P., and I. van | ||||
Beijnum, "DNS64: DNS Extensions for Network Address | ||||
Translation from IPv6 Clients to IPv4 Servers", RFC 6147, | ||||
DOI 10.17487/RFC6147, April 2011, | ||||
<https://www.rfc-editor.org/info/rfc6147>. | ||||
[RFC6707] Niven-Jenkins, B., Le Faucheur, F., and N. Bitar, "Content | ||||
Distribution Network Interconnection (CDNI) Problem | ||||
Statement", RFC 6707, DOI 10.17487/RFC6707, September | ||||
2012, <https://www.rfc-editor.org/info/rfc6707>. | ||||
[RFC6762] Cheshire, S. and M. Krochmal, "Multicast DNS", RFC 6762, | ||||
DOI 10.17487/RFC6762, February 2013, | ||||
<https://www.rfc-editor.org/info/rfc6762>. | ||||
[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>. | ||||
[RFC8106] Jeong, J., Park, S., Beloeil, L., and S. Madanapalli, | ||||
"IPv6 Router Advertisement Options for DNS Configuration", | ||||
RFC 8106, DOI 10.17487/RFC8106, March 2017, | ||||
<https://www.rfc-editor.org/info/rfc8106>. | ||||
[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>. | ||||
[RFC8882] Huitema, C. and D. Kaiser, "DNS-Based Service Discovery | ||||
(DNS-SD) Privacy and Security Requirements", RFC 8882, | ||||
DOI 10.17487/RFC8882, September 2020, | ||||
<https://www.rfc-editor.org/info/rfc8882>. | ||||
[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 DNS names in real time often 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 DNS 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 | ||||
An IoT manufacturer with a cloud 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 DNS mappings: they can often be incomplete or incorrect for | ||||
months or even years without visible effect on operations. | ||||
IoT manufacturer cloud service providers often find it difficult to | ||||
update reverse DNS 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 DNS mapping 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 DNS names for each reverse DNS mapping, | ||||
whether or not the DNS load balancing in the forward DNS space lists | ||||
that end-point at that moment. | ||||
A.4. Forward DNS 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 DNS names. Instead, a wildcard | ||||
exists to answer all potential DNS 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 DNS 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. 83 change blocks. | ||||
379 lines changed or deleted | 513 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/ |