draft-ietf-opsawg-mud-iot-dns-considerations-03.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: 22 July 2022 Huawei Technologies | Expires: 4 January 2025 Huawei Technologies | |||
18 January 2022 | 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-03 | 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 | ||||
This note is to be removed before publishing as an RFC. | ||||
Status information for this document may be found at | ||||
https://datatracker.ietf.org/doc/draft-ietf-opsawg-mud-iot-dns- | ||||
considerations/. | ||||
Discussion of this document takes place on the opsawg Working Group | ||||
mailing list (mailto:opsawg@ietf.org), which is archived at | ||||
https://mailarchive.ietf.org/arch/browse/opsawg/. Subscribe at | ||||
https://www.ietf.org/mailman/listinfo/opsawg/. | ||||
Source for this draft and an issue tracker can be found at | ||||
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 22 July 2022. | This Internet-Draft will expire on 4 January 2025. | |||
Copyright Notice | Copyright Notice | |||
Copyright (c) 2022 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 . . . . . . . . . . . . . . . . . . . . . . . . 2 | 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 | |||
4. DNS and IP Anti-Patterns for IoT device Manufacturers . . . . 6 | addresses . . . . . . . . . . . . . . . . . . . . . . . . 4 | |||
4.1. Use of IP address literals in-protocol . . . . . . . . . 6 | 3.1. Non-Deterministic Mappings . . . . . . . . . . . . . . . 5 | |||
4.2. Use of non-deterministic DNS names in-protocol . . . . . 8 | 4. DNS and IP Anti-Patterns for IoT Device Manufacturers . . . . 7 | |||
4.3. Use of a too inclusive DNS name . . . . . . . . . . . . . 8 | 4.1. Use of IP Address Literals . . . . . . . . . . . . . . . 7 | |||
5. DNS privacy and outsourcing versus MUD controllers . . . . . 8 | 4.2. Use of Non-deterministic DNS Names in-protocol . . . . . 8 | |||
6. Recommendations to IoT device manufacturer on MUD and DNS | 4.3. Use of a Too Generic DNS Name . . . . . . . . . . . . . . 9 | |||
usage . . . . . . . . . . . . . . . . . . . . . . . . . . 9 | 5. DNS Privacy and Outsourcing versus MUD Controllers . . . . . 10 | |||
6.1. Consistently use DNS . . . . . . . . . . . . . . . . . . 9 | 6. Recommendations To IoT Device Manufacturers on MUD and DNS | |||
6.2. Use primary DNS names controlled by the manufacturer . . 10 | Usage . . . . . . . . . . . . . . . . . . . . . . . . . . 10 | |||
6.3. Use Content-Distribution Network with stable names . . . 10 | 6.1. Consistently use DNS . . . . . . . . . . . . . . . . . . 10 | |||
6.4. Do not use geofenced names . . . . . . . . . . . . . . . 10 | 6.2. Use Primary DNS Names Controlled By The Manufacturer . . 11 | |||
6.5. Prefer DNS servers learnt from DHCP/Route | 6.3. Use Content-Distribution Network with Stable DNS Names . 11 | |||
Advertisements . . . . . . . . . . . . . . . . . . . . . 10 | 6.4. Do Not Use Tailored Responses to answer DNS Names . . . . 11 | |||
7. Privacy Considerations . . . . . . . . . . . . . . . . . . . 11 | 6.5. Prefer DNS Servers Learnt From DHCP/Router | |||
8. Security Considerations . . . . . . . . . . . . . . . . . . . 12 | Advertisements . . . . . . . . . . . . . . . . . . . . . 12 | |||
9. References . . . . . . . . . . . . . . . . . . . . . . . . . 12 | 7. Interactions with mDNS and DNSSD . . . . . . . . . . . . . . 12 | |||
9.1. Normative References . . . . . . . . . . . . . . . . . . 13 | 8. Privacy Considerations . . . . . . . . . . . . . . . . . . . 13 | |||
9.2. Informative References . . . . . . . . . . . . . . . . . 14 | 9. Security Considerations . . . . . . . . . . . . . . . . . . . 14 | |||
Appendix A. Appendices . . . . . . . . . . . . . . . . . . . . . 15 | 10. References . . . . . . . . . . . . . . . . . . . . . . . . . 14 | |||
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 15 | 10.1. Normative References . . . . . . . . . . . . . . . . . . 15 | |||
10.2. Informative References . . . . . . . . . . . . . . . . . 15 | ||||
Appendix A. A Failing Strategy --- Anti-Patterns . . . . . . . . 18 | ||||
A.1. Too Slow . . . . . . . . . . . . . . . . . . . . . . . . 18 | ||||
A.2. Reveals Patterns of Usage . . . . . . . . . . . . . . . . 18 | ||||
A.3. Mappings Are Often Incomplete . . . . . . . . . . . . . . 19 | ||||
A.4. Forward DNS Names Can Have Wildcards . . . . . . . . . . 19 | ||||
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. | 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 | generalizes automatically to IPv4 and IPv6 addresses, as well as | |||
loading balancing of traffic by many different common ways, including | permitting a variety of load balancing strategies, including multi- | |||
geography. | 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 only access 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 | ||||
forced intermediate for the TLS connections. This could in theory 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. But, TLS 1.3 provides | ||||
options to encrypt the SNI as the ESNI, which renders the practice | ||||
useless in the end. | ||||
So in order to implement these name based ACLs, there must be a | So in order to implement these name based ACLs, there must be a | |||
mapping between the names in the ACLs and layer-3 IP addresses. The | mapping between the names in the ACLs and IP addresses. | |||
first section of this document details a few strategies that are | ||||
used. | ||||
The second section of this document details how common manufacturer | In order for manufacturers to understand how to configure DNS | |||
anti-patterns get in the way this mapping. | associated with name based ACLs, a model of how the DNS resolution | |||
will be done by MUD controllers is necessary. Section 3 models some | ||||
good strategies that are used. | ||||
The third section of this document details how current trends in DNS | This model is non-normative: but is included so that IoT device | |||
presolution such as public DNS servers, DNS over TLS (DoT), and DNS | manufacturers can understand how the DNS will be used to resolve the | |||
over HTTPS (DoH) cause problems for the strategies employed. Poor | names they use. | |||
interactions with content-distribution networks is a frequent | ||||
pathology that can result. | ||||
The fourth section of this document makes a series of recommendations | There are some ways of using DNS that will present problems for MUD | |||
("best current practices") for manufacturers on how to use DNS, and | controllers, which Section 4 explains. | |||
IP addresses with specific purpose IoT devices. | ||||
The Privacy Considerations section concerns itself with issues that | Section 5 details how current trends in DNS resolution such as public | |||
DNS-over-TLS and DNS-over-HTTPS are frequently used to deal with. | DNS servers, DNS over TLS (DoT) [RFC7858], DNS over HTTPS (DoH) | |||
How these concerns apply to IoT devices located within a residence or | [RFC8484], or DNS over QUIC (DoQ) [RFC9250] can cause problems with | |||
the strategies employed. | ||||
The core of this document, is Section 6, which makes a series of | ||||
recommendations ("best current practices") for manufacturers on how | ||||
to use DNS and IP addresses with MUD supporting IoT devices. | ||||
Section 8 discusses a set of privacy issues that encrypted DNS (DoT, | ||||
DoH, for example) are frequently used to deal with. How these | ||||
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. This 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 | The term "anti-pattern" comes from agile software design literature, | |||
not map back to the name used in the ACL. | as per [antipatterns]. | |||
This is not a successful strategy, its use is NOT RECOMMENDED. | CDN refers to Content Distribution Networks, such as described by | |||
[RFC6707], Section 1.1. | ||||
XXX -- explain in detail how this can fail. | 3. A model for MUD controller mapping of DNS names to addresses | |||
XXX -- explain N:1 vs 1:1 for virtual hosting. | 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 is 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 in the mapping of the names to IP addresses | 3.1. Non-Deterministic Mappings | |||
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 | |||
permutted 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 setup 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 | |||
system. 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 does 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 | |||
do DNS lookups. These lookups need to be rate limited in order to | perform DNS lookups in order to never have stale data. These lookups | |||
avoid load. It may be necessary to avoid recursive DNS servers in | must be rate limited to avoid excessive load on the DNS servers, and | |||
order to avoid receiving cached data. Properly designed recursive | it may be necessary to avoid local recursive resolvers. The MUD | |||
servers should cache data for many minutes to days, while the | controller SHOULD incorporate its own recursive caching DNS server. | |||
underlying DNS data can change at a higher frequency, providing | Properly designed recursive servers should cache data for at least | |||
different answers to different queries! | some number of minutes, up to some number of days (respecting the | |||
TTL), while the underlying DNS data can change at a higher frequency, | ||||
providing different answers to different queries! | ||||
A MUD controller that is aware of which recursive DNS server that the | A MUD controller that is aware of which recursive DNS server the IoT | |||
IoT device will use can instead query that server on a periodic | device will use can instead query that server on a periodic basis. | |||
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. | |||
2. the resulting name to IP address mapping in the recursive name | 2. The resulting name to IP address mapping in the recursive name | |||
server will be cached, and will remain the same for the entire | server will be cached, and will remain the same for the entire | |||
advertised Time-To-Live reported in the DNS query return. This | advertised Time-To-Live reported in the DNS query return. This | |||
also allows the MUD controller to avoid doing unnecessary | also allows the MUD controller to avoid doing unnecessary | |||
queries. | queries. | |||
3. if any addresses have been omitted in a round-robin DNS process, | 3. if any addresses have been omitted in a round-robin DNS process, | |||
the cache will have the set of addresses that were returned. | the cache will have the same set of addresses that were returned. | |||
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 controllers 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 the 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 Enteprise, or remotely in a cloud such as | the MUD controller is located elsewhere in an Enterprise, or remotely | |||
when a Software Defines 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 recusive | known to the MUD controller, nor the MUD controller be even permitted | |||
queries that server if it is known. In this case, additional | to make recursive queries to that server if it is known. In this | |||
installation specific mechanisms are probably needed to get the right | case, additional installation specific mechanisms are probably needed | |||
view of 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 with IoT manufacturers have | This section describes a number of things which IoT manufacturers | |||
been observed to do in the field, each of which presents difficulties | have been observed to do in the field, each of which presents | |||
for MUD enforcement points. | difficulties for MUD enforcement points. | |||
4.1. Use of IP address literals in-protocol | 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 or not 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 end point is queried which provides the name and URL of the | an HTTPS endpoint is queried which provides the name and URL of the | |||
most 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 | practice is that firmware is either signed internally ([RFC9019]) so | |||
([I-D.ietf-suit-architecture]) so that it can be verified, or a hash | that it can be verified, or a hash of the blob is provided. | |||
of the blob is provided. | ||||
An authoritative server might be tempted to provided an IP address | ||||
literal inside the protocol: there are two arguments (anti-patterns) | ||||
for doing this. | ||||
One is that it eliminates problems to firmware updates that might be | ||||
caused by lack of DNS, or incompatibilities with DNS. For instance | ||||
the bug that causes interoperability issues with some recursive | ||||
servers would become unpatchable for devices that were forced to use | ||||
that recursive resolver type. | ||||
A second reason to avoid a DNS in the URL is when an inhouse content- | An authoritative server might be tempted to provide an IP address | |||
distribution system is involved that involves on-demand instances | literal inside the protocol. An argument for doing this is that it | |||
being added (or removed) from a cloud computing architecture. | eliminates problems with firmware updates that might be caused by | |||
lack of DNS, or incompatibilities with DNS. For instance a bug that | ||||
causes interoperability issues with some recursive servers would | ||||
become unpatchable for devices that were forced to use that recursive | ||||
resolver type. | ||||
But, there are many 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. | ||||
And with any non-determistic name or address that is returned, the | Finally, it is common in some Content Distribution Networks (CDNs) to | |||
MUD controller is not challenged to validate the transaction, as it | use multiple layers of DNS CNAMEs in order to isolate the content- | |||
can not see into the communication. | owner's naming system from changes in how the distribution network is | |||
organized. | ||||
Third-party content-distribution networks (CDN) tend to use DNS names | When a name or address is returned within an update protocol for | |||
in order to isolate the content-owner from changes to the | which a MUD rule cannot be written, then the MUD controller is unable | |||
distribution network. | to authorize the connection. In order for the connection to be | |||
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 | |||
end point. 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- | Those DNS names are often within some third-party CDN system, or may | |||
Network (CDN) system, or may be arbitrary names in a cloud-provider | be arbitrary DNS names in a cloud-provider storage system (e.g., | |||
storage system such as Amazon S3 (such [AmazonS3], or [Akamai]). | [AmazonS3], or [Akamai]). Some of the name components may be | |||
specified by the third party CDN provider. | ||||
Since it is not possible to predict a name for where the content will | Such DNS names may be unpredictably chosen by the CDN, and not the | |||
be, it is not possible to include that into the MUD file. | 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 applies to the firmware update situation as well. | Even if the CDN provider's chosen DNS names are deterministic they | |||
may change at a rate much faster than MUD files can be updated. | ||||
4.3. Use of a too inclusive DNS name | This situation applies to firmware updates, but also applies to many | |||
other kinds of content: video content, in-game content, etc. | ||||
Some CDNs make all customer content at a single URL (such as | A solution may be to use a deterministic DNS name, within the control | |||
s3.amazonaws.com). This seems to be ideal from a MUD point of view: | of the device manufacturer. The device manufacturer is asked to | |||
a completely predictable URL. The problem is that a compromised | point a CNAME to the CDN, to a name that might look like | |||
device could then connect to any S3 bucket, potentially attacking | "g7.a.example", with the expectation that the CDN vendors DNS will do | |||
other buckets. | all the appropriate work to geolocate the transfer. This can be fine | |||
for a MUD file, as the MUD controller, if located in the same | ||||
geography as the IoT device, can follow the CNAME, and can collect | ||||
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. | ||||
In some cases, a complete set of geographically distributed servers | ||||
may be known ahead of time (or that it changes very slowly), and the | ||||
device manufacturer can list all those IP addresses in the DNS for | ||||
the the name that it lists in the MUD file. 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 content download itself. | ||||
4.3. Use of a Too Generic DNS Name | ||||
Some CDNs make all customer content available at a single URL (such | ||||
as "s3.example.com"). This seems to be ideal from a MUD point of | ||||
view: a completely predictable URL. | ||||
The problem is that a compromised device could then connect to the | ||||
contents of any bucket, potentially attacking the data from other | ||||
customers. | ||||
Exactly what the risk is depends upon what the other customers are | ||||
doing: it could be limited to simply causing a distributed denial-of- | ||||
service attack resulting in high costs to those customers, or such an | ||||
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-terminology-ter] details the terms. | [I-D.ietf-dnsop-rfc8499bis] details the terms. But, even with the | |||
But, 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. | |||
There are significant privacy issues with having IoT devices sending | For some users and classes of devices, revealing the DNS queries to | |||
their DNS queries to an outside entity. Doing it over a secure | those outside entities may constitute a privacy concern. For other | |||
transport (DoT/DoH) is clearly better than doing so on port 53. The | users the use of an insecure local resolver may constitute a privacy | |||
providers of the secure resolver service will, however, still see the | concern. | |||
IoT device queries. | ||||
A 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. Use of the QuadX | access to the same resolver(s) as the IoT device. If the IoT device | |||
resolvers (such as Google's 8.8.8.8) at first seems to present less | does not use the DNS servers provided to it via DHCP or Router | |||
of a problem than use of some other less well known resolver. While | Advertisements, then the MUD controller will need to be told which | |||
any system may use QuadX, in most cases those services are massively | servers will in fact be used. As yet, there is no protocol to do | |||
replicated via anycast: there is no guarantee that a MUD controller | this, but future work could provide this as an extension to MUD. | |||
will speak to the same instance, or get the same geographic anycast | ||||
result. | ||||
XXX - THIS NEEDS WAY MORE EXPLANATION. | 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 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 | the use of a QR code affixed to the packaging (see [RFC9238]) | |||
[I-D.richardson-mud-qrcode]. | ||||
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 semantic contents of what is in the MUD file. An IoT | now the actual list of expected connections to put in the MUD file. | |||
manufacturer must now spend some time reviewing what the network | An IoT manufacturer must now spend some time reviewing the network | |||
communications that their device does. | communications by their device. | |||
This document has discussed a number of challenges that occur | This document discusses a number of challenges that occur relating to | |||
relating to how DNS requests are made and resolved, and it is the | how DNS requests are made and resolved, and the goal of this section | |||
goal of this section to make recommendations on how to modify IoT | is to make recommendations on how to modify IoT systems to work well | |||
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 [RFC8499] section 2) that points to the production system. | populated with an alias (see [I-D.ietf-dnsop-rfc8499bis] section 2) | |||
Ideally, a different name is used for each logical function, allowing | that points to the production system. Ideally, a different name is | |||
for different rules in the MUD file to be enabled and disabled. | used for each logical function, allowing for different rules in the | |||
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 allowed for an | certificates are also commonly available which allow for an infinite | |||
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 to | When aliases point to a CDN, prefer stable DNS names that point to | |||
use stable names that point to appropriately load balanced targets. | appropriately load balanced targets. CDNs that employ very low time- | |||
CDNs that employ very low time-to-live (TTL) values for DNS make it | to-live (TTL) values for DNS make it harder for the MUD controller to | |||
harder for the MUD controller to get the same answer as the IoT | get the same answer as the IoT Device. A CDN that always returns the | |||
Device. A CDN that always returns the same set of A and AAAA | same set of A and AAAA records, but permutes them to provide the best | |||
records, but permutes them to provide the best one first provides a | one first provides a more reliable answer. | |||
more reliable answer. | ||||
6.4. Do not use geofenced names | 6.4. Do Not Use Tailored Responses to answer DNS Names | |||
Due the problems with different answers from different DNS servers, | [RFC7871] defines the edns-client-subnet (ECS) EDNS0 option, and | |||
described above, a strong recommendation is to avoid using such | explains how authoritative servers sometimes answer queries | |||
things. | 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. | ||||
XXX - it has been suggested that this will not help, thus previous | There are probably ways in which the MUD controller could use the | |||
recommendation. | 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. | ||||
IoT Devices should prefer doing DNS to the network provided DNS | In practice it could be quite difficult if the IoT device uses a | |||
servers. Whether this is restricted to Classic DNS (Do53) or also | different Internet connection, a different firewall, or a different | |||
includes using DoT/DoH is a local decision, but a locally provided | recursive DNS server. The edns-client-server might be ignored or | |||
DoT server SHOULD be used, as recommended by | overridden by any of the DNS infrastructure. | |||
[I-D.reddy-dprive-bootstrap-dns-server] and [I-D.peterson-doh-dhcp]. | ||||
The ADD WG is currently only focusing on insecure discovery | Some tailored responses might only re-order the replies so that the | |||
mechanisms like DHCP/RA [I-D.btw-add-home] and DNS based discovery | most preferred address is first. Such a system would be acceptable | |||
mechanisms ({?{I-D.pauly-add-deer}}). Secure discovery of network | if the MUD controller had a way to know that the list was complete. | |||
provided DoH/DoT resolver is possible using the mechanisms discussed | ||||
in [I-D.reddy-add-enterprise] section-4. | ||||
Use of public QuadX resolver instead of the provided DNS resolver, | But, due to the above problems, a strong recommendation is to avoid | |||
whether Do53, DoT or DoH is discouraged. Should the network provide | using tailored responses as part of the DNS names in the MUD file. | |||
such a resolver for use, then there is no reason not to use it, as | ||||
the network operator has clearly thought about this. | 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 | |||
The recommendation here is to do this only when the provided | resolver might not return the same tailored names that the MUD | |||
resolvers provide no answers to any queries at all, and do so | controller would get. | |||
repeatedly. The use of the operator provided resolvers SHOULD be | ||||
retried on a periodic basis, and once they answer, there should be no | ||||
further attempts to contact public resolvers. | ||||
Finally, the list of public resolvers that might be contacted MUST be | It is recommended that use of non-local resolvers is only done when | |||
listed in the MUD file as destinations that are to be permitted! | the locally provided resolvers provide no answers to any queries at | |||
This should include the port numbers (53, 853 for DoT, 443 for DoH) | all, and do so repeatedly. The status of the operator provided | |||
that will be used as well. | resolvers needs to be re-evaluated on a periodic basis. | |||
7. Privacy Considerations | Finally, if a device will ever attempt to use a non-local resolvers, | |||
then the address of that resolver needs to be listed in the MUD file | ||||
as destinations that are to be permitted. This needs to include the | ||||
port numbers (i.e., 53, 853 for DoT, 443 for DoH) that will be used | ||||
as well. | ||||
The use of non-local DNS servers exposes the list of names resolved | 7. Interactions with mDNS and DNSSD | |||
to a third parties, including passive eavesdroppers. | ||||
The use of DoT and DoH eliminates the minimizes threat from passive | Unicast DNS requests are not the only way to map names to IP | |||
eavesdropped, but still exposes the list to the operator of the DoT | addresses. IoT devices might also use mDNS [RFC6762], both to be | |||
or DoH server. There are additional methods, such as described by | discovered by other devices, and also to discover other devices. | |||
[I-D.pauly-dprive-oblivious-doh]. | ||||
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 | ||||
eavesdropping, but still exposes the list to the operator of the DoT | ||||
or DoH server. There are additional methods to help preserve | ||||
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 WiFi | 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 a preferred choice, assuming that the trust anchor for | ||||
the local DNS server can be obtained, such as via | Use of Encrypted DNS connection to a local DNS recursive resolver is | |||
[I-D.reddy-dprive-bootstrap-dns-server]. | 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 advantage of | targeted attacks to the IoT device (e.g., Attacker can take advantage | |||
the device vulnerability). | of any known vulnerability on the device). | |||
While possession of a Large (Kitchen) Appliance at a residence may be | While possession of a Large (Kitchen) Appliance at a residence may be | |||
uninteresting to most, possession of intimate personal devices (e.g., | uninteresting to most, possession of intimate personal devices (e.g., | |||
"sex toys") may be a cause for embarrassment. | "sex toys") may be a cause for embarrassment. | |||
IoT device manufacturers are encouraged to find ways to anonymize | IoT device manufacturers are encouraged to find ways to anonymize | |||
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 | |||
decided the correct route to do upgrades. The current | the correct route to do upgrades. [RFC9019] provides a wide variety | |||
[I-D.ietf-suit-architecture] specification provides a wide variety of | of ways to accomplish the same thing without having to divulge the | |||
ways to accomplish the same thing without having to divulge the | ||||
current version number. | current version number. | |||
The use of a publically specified firmware update protocol would also | 9. Security Considerations | |||
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 a 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 | ||||
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 some advance | be in conflict, but resolving the conflict requires careful planning | |||
planning by all parties. | on how the DNS can be safely and effectively used by MUD controllers | |||
and IoT devices. | ||||
9. References | ||||
9.1. Normative References | ||||
[Akamai] "Akamai", 2019, | ||||
<https://en.wikipedia.org/wiki/Akamai_Technologies>. | ||||
[AmazonS3] "Amazon S3", 2019, | ||||
<https://en.wikipedia.org/wiki/Amazon_S3>. | ||||
[I-D.ietf-dnsop-terminology-ter] | ||||
Hoffman, P., "Terminology for DNS Transports and | ||||
Location", Work in Progress, Internet-Draft, draft-ietf- | ||||
dnsop-terminology-ter-02, 3 August 2020, | ||||
<https://www.ietf.org/archive/id/draft-ietf-dnsop- | ||||
terminology-ter-02.txt>. | ||||
[I-D.ietf-suit-architecture] | ||||
Moran, B., Tschofenig, H., Brown, D., and M. Meriac, "A | ||||
Firmware Update Architecture for Internet of Things", Work | ||||
in Progress, Internet-Draft, draft-ietf-suit-architecture- | ||||
16, 27 January 2021, <https://www.ietf.org/archive/id/ | ||||
draft-ietf-suit-architecture-16.txt>. | ||||
[I-D.peterson-doh-dhcp] | 10. References | |||
Peterson, T., "DNS over HTTP resolver announcement Using | 10.1. Normative References | |||
DHCP or Router Advertisements", Work in Progress, | ||||
Internet-Draft, draft-peterson-doh-dhcp-01, 21 October | ||||
2019, <https://www.ietf.org/archive/id/draft-peterson-doh- | ||||
dhcp-01.txt>. | ||||
[I-D.reddy-dprive-bootstrap-dns-server] | [I-D.ietf-dnsop-rfc8499bis] | |||
Reddy, T., Wing, D., Richardson, M. C., and M. Boucadair, | Hoffman, P. E. and K. Fujiwara, "DNS Terminology", Work in | |||
"A Bootstrapping Procedure to Discover and Authenticate | Progress, Internet-Draft, draft-ietf-dnsop-rfc8499bis-10, | |||
DNS-over-TLS and DNS-over-HTTPS Servers", Work in | 25 September 2023, <https://datatracker.ietf.org/doc/html/ | |||
Progress, Internet-Draft, draft-reddy-dprive-bootstrap- | draft-ietf-dnsop-rfc8499bis-10>. | |||
dns-server-08, 6 March 2020, | ||||
<https://www.ietf.org/archive/id/draft-reddy-dprive- | ||||
bootstrap-dns-server-08.txt>. | ||||
[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>. | |||
[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>. | ||||
[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>. | |||
[RFC8499] Hoffman, P., Sullivan, A., and K. Fujiwara, "DNS | [RFC8250] Elkins, N., Hamilton, R., and M. Ackermann, "IPv6 | |||
Terminology", BCP 219, RFC 8499, DOI 10.17487/RFC8499, | Performance and Diagnostic Metrics (PDM) Destination | |||
January 2019, <https://www.rfc-editor.org/info/rfc8499>. | 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>. | |||
9.2. Informative References | [RFC9019] Moran, B., Tschofenig, H., Brown, D., and M. Meriac, "A | |||
Firmware Update Architecture for Internet of Things", | ||||
RFC 9019, DOI 10.17487/RFC9019, April 2021, | ||||
<https://www.rfc-editor.org/info/rfc9019>. | ||||
10.2. Informative References | ||||
[Akamai] "Akamai", 2019, | ||||
<https://en.wikipedia.org/wiki/Akamai_Technologies>. | ||||
[AmazonS3] "Amazon S3", 2019, | ||||
<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.btw-add-home] | [I-D.ietf-snac-simple] | |||
Boucadair, M., Reddy, T., Wing, D., Cook, N., and T. | Lemon, T. and J. Hui, "Automatically Connecting Stub | |||
Jensen, "DHCP and Router Advertisement Options for | Networks to Unmanaged Infrastructure", Work in Progress, | |||
Encrypted DNS Discovery", Work in Progress, Internet- | Internet-Draft, draft-ietf-snac-simple-04, 4 March 2024, | |||
Draft, draft-btw-add-home-12, 22 January 2021, | <https://datatracker.ietf.org/doc/html/draft-ietf-snac- | |||
<https://www.ietf.org/archive/id/draft-btw-add-home- | simple-04>. | |||
12.txt>. | ||||
[I-D.pauly-dprive-oblivious-doh] | ||||
Kinnear, E., McManus, P., Pauly, T., Verma, T., and C. A. | ||||
Wood, "Oblivious DNS Over HTTPS", Work in Progress, | ||||
Internet-Draft, draft-pauly-dprive-oblivious-doh-09, 5 | ||||
January 2022, <https://www.ietf.org/archive/id/draft- | ||||
pauly-dprive-oblivious-doh-09.txt>. | ||||
[I-D.reddy-add-enterprise] | ||||
Reddy, T. and D. Wing, "DNS-over-HTTPS and DNS-over-TLS | ||||
Server Deployment Considerations for Enterprise Networks", | ||||
Work in Progress, Internet-Draft, draft-reddy-add- | ||||
enterprise-00, 23 June 2020, | ||||
<https://www.ietf.org/archive/id/draft-reddy-add- | ||||
enterprise-00.txt>. | ||||
[I-D.richardson-mud-qrcode] | ||||
Richardson, M., Latour, J., and H. H. Gharakheili, "On | ||||
loading MUD URLs from QR codes", Work in Progress, | ||||
Internet-Draft, draft-richardson-mud-qrcode-03, 11 January | ||||
2022, <https://www.ietf.org/archive/id/draft-richardson- | ||||
mud-qrcode-03.txt>. | ||||
[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>. | |||
Appendix A. Appendices | [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. | ||||
Wood, "Oblivious DNS over HTTPS", RFC 9230, | ||||
DOI 10.17487/RFC9230, June 2022, | ||||
<https://www.rfc-editor.org/info/rfc9230>. | ||||
[RFC9238] Richardson, M., Latour, J., and H. Habibi Gharakheili, | ||||
"Loading Manufacturer Usage Description (MUD) URLs from QR | ||||
Codes", RFC 9238, DOI 10.17487/RFC9238, May 2022, | ||||
<https://www.rfc-editor.org/info/rfc9238>. | ||||
[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 | ||||
Tirumaleswar Reddy | ||||
Nokia | ||||
Authors' Addresses | Authors' Addresses | |||
Michael Richardson | Michael Richardson | |||
Sandelman Software Works | Sandelman Software Works | |||
Email: mcr+ietf@sandelman.ca | Email: mcr+ietf@sandelman.ca | |||
Wei Pan | Wei Pan | |||
Huawei Technologies | Huawei Technologies | |||
Email: william.panwei@huawei.com | Email: william.panwei@huawei.com | |||
End of changes. 102 change blocks. | ||||
390 lines changed or deleted | 627 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/ |