draft-ietf-opsawg-mud-iot-dns-considerations-13.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 September 2024 Huawei Technologies | Expires: 4 January 2025 Huawei Technologies | |||
21 March 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-13 | draft-ietf-opsawg-mud-iot-dns-considerations-16 | |||
Abstract | Abstract | |||
This document details concerns about how Internet of Things (IoT) | This document details considerations about how Internet of Things | |||
devices use IP addresses and DNS names. These concerns become acute | (IoT) devices use IP addresses and DNS names. These concerns become | |||
as network operators begin deploying RFC 8520 Manufacturer Usage | acute as network operators begin deploying RFC 8520 Manufacturer | |||
Description (MUD) definitions to control device access. | Usage Description (MUD) definitions to control device access. | |||
Alos, this document makes recommendations on when and how to use DNS | Also, this document makes recommendations on when and how to use DNS | |||
names in MUD files. | names in MUD files. | |||
About This Document | About This Document | |||
This note is to be removed before publishing as an RFC. | This note is to be removed before publishing as an RFC. | |||
Status information for this document may be found at | Status information for this document may be found at | |||
https://datatracker.ietf.org/doc/draft-ietf-opsawg-mud-iot-dns- | https://datatracker.ietf.org/doc/draft-ietf-opsawg-mud-iot-dns- | |||
considerations/. | considerations/. | |||
Discussion of this document takes place on the opsawg Working Group | Discussion of this document takes place on the opsawg Working Group | |||
mailing list (mailto:opsawg@ietf.org), which is archived at | mailing list (mailto:opsawg@ietf.org), which is archived at | |||
https://mailarchive.ietf.org/arch/browse/opsawg/. | 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 | Source for this draft and an issue tracker can be found at | |||
https://github.com/mcr/iot-mud-dns-considerations. | https://github.com/mcr/iot-mud-dns-considerations. | |||
Status of This Memo | Status of This Memo | |||
This Internet-Draft is submitted in full conformance with the | This Internet-Draft is submitted in full conformance with the | |||
provisions of BCP 78 and BCP 79. | provisions of BCP 78 and BCP 79. | |||
Internet-Drafts are working documents of the Internet Engineering | Internet-Drafts are working documents of the Internet Engineering | |||
Task Force (IETF). Note that other groups may also distribute | Task Force (IETF). Note that other groups may also distribute | |||
working documents as Internet-Drafts. The list of current Internet- | working documents as Internet-Drafts. The list of current Internet- | |||
Drafts is at https://datatracker.ietf.org/drafts/current/. | Drafts is at https://datatracker.ietf.org/drafts/current/. | |||
Internet-Drafts are draft documents valid for a maximum of six months | Internet-Drafts are draft documents valid for a maximum of six months | |||
and may be updated, replaced, or obsoleted by other documents at any | and may be updated, replaced, or obsoleted by other documents at any | |||
time. It is inappropriate to use Internet-Drafts as reference | time. It is inappropriate to use Internet-Drafts as reference | |||
material or to cite them other than as "work in progress." | material or to cite them other than as "work in progress." | |||
This Internet-Draft will expire on 22 September 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. A model for MUD controller mapping of names to addresses . . 4 | 3. A model for MUD controller mapping of DNS names to | |||
3.1. Non-Deterministic Mappings . . . . . . . . . . . . . . . 4 | addresses . . . . . . . . . . . . . . . . . . . . . . . . 4 | |||
4. DNS and IP Anti-Patterns for IoT Device Manufacturers . . . . 6 | 3.1. Non-Deterministic Mappings . . . . . . . . . . . . . . . 5 | |||
4.1. Use of IP Address Literals in-protocol . . . . . . . . . 6 | 4. DNS and IP Anti-Patterns for IoT Device Manufacturers . . . . 7 | |||
4.1. Use of IP Address Literals . . . . . . . . . . . . . . . 7 | ||||
4.2. Use of Non-deterministic DNS Names in-protocol . . . . . 8 | 4.2. Use of Non-deterministic DNS Names in-protocol . . . . . 8 | |||
4.3. Use of a Too Generic DNS Name . . . . . . . . . . . . . . 9 | 4.3. Use of a Too Generic DNS Name . . . . . . . . . . . . . . 9 | |||
5. DNS Privacy and Outsourcing versus MUD Controllers . . . . . 9 | 5. DNS Privacy and Outsourcing versus MUD Controllers . . . . . 10 | |||
6. Recommendations To IoT Device Manufacturers on MUD and DNS | 6. Recommendations To IoT Device Manufacturers on MUD and DNS | |||
Usage . . . . . . . . . . . . . . . . . . . . . . . . . . 10 | Usage . . . . . . . . . . . . . . . . . . . . . . . . . . 10 | |||
6.1. Consistently use DNS . . . . . . . . . . . . . . . . . . 10 | 6.1. Consistently use DNS . . . . . . . . . . . . . . . . . . 10 | |||
6.2. Use Primary DNS Names Controlled By The Manufacturer . . 10 | 6.2. Use Primary DNS Names Controlled By The Manufacturer . . 11 | |||
6.3. Use Content-Distribution Network with Stable Names . . . 10 | 6.3. Use Content-Distribution Network with Stable DNS Names . 11 | |||
6.4. Do Not Use Tailored Responses to answer DNS Names . . . . 11 | 6.4. Do Not Use Tailored Responses to answer DNS Names . . . . 11 | |||
6.5. Prefer DNS Servers Learnt From DHCP/Route | 6.5. Prefer DNS Servers Learnt From DHCP/Router | |||
Advertisements . . . . . . . . . . . . . . . . . . . . . 11 | Advertisements . . . . . . . . . . . . . . . . . . . . . 12 | |||
7. Privacy Considerations . . . . . . . . . . . . . . . . . . . 12 | 7. Interactions with mDNS and DNSSD . . . . . . . . . . . . . . 12 | |||
8. Security Considerations . . . . . . . . . . . . . . . . . . . 13 | 8. Privacy Considerations . . . . . . . . . . . . . . . . . . . 13 | |||
9. References . . . . . . . . . . . . . . . . . . . . . . . . . 13 | 9. Security Considerations . . . . . . . . . . . . . . . . . . . 14 | |||
9.1. Normative References . . . . . . . . . . . . . . . . . . 13 | 10. References . . . . . . . . . . . . . . . . . . . . . . . . . 14 | |||
9.2. Informative References . . . . . . . . . . . . . . . . . 14 | 10.1. Normative References . . . . . . . . . . . . . . . . . . 15 | |||
Appendix A. A Failing Strategy --- Anti-Patterns . . . . . . . . 16 | 10.2. Informative References . . . . . . . . . . . . . . . . . 15 | |||
A.1. Too Slow . . . . . . . . . . . . . . . . . . . . . . . . 16 | Appendix A. A Failing Strategy --- Anti-Patterns . . . . . . . . 18 | |||
A.2. Reveals Patterns of Usage . . . . . . . . . . . . . . . . 16 | A.1. Too Slow . . . . . . . . . . . . . . . . . . . . . . . . 18 | |||
A.3. Mappings Are Often Incomplete . . . . . . . . . . . . . . 17 | A.2. Reveals Patterns of Usage . . . . . . . . . . . . . . . . 18 | |||
A.4. Forward Names Can Have Wildcards . . . . . . . . . . . . 17 | A.3. Mappings Are Often Incomplete . . . . . . . . . . . . . . 19 | |||
Contributors . . . . . . . . . . . . . . . . . . . . . . . . . . 18 | A.4. Forward DNS Names Can Have Wildcards . . . . . . . . . . 19 | |||
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 18 | 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 RFC 8520 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 their | (MUD) file that permit a device to access Internet resources by their | |||
DNS names or IP addresses. | DNS names or IP addresses. | |||
Use of a DNS name rather than an IP address in an 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 a name to IP address(es) to be changed over time, it also | of a name to IP address(es) to be changed over time, it also | |||
generalizes automatically to IPv4 and IPv6 addresses, as well as | generalizes automatically to IPv4 and IPv6 addresses, as well as | |||
permitting a variety of load balancing strategies, including multi- | permitting a variety of load balancing strategies, including multi- | |||
CDN deployments wherein load balancing can account for geography and | CDN deployments wherein load balancing can account for geography and | |||
load. | load. | |||
However, the use of DNS names has implications on how ACL are | However, the use of DNS names has implications on how ACL are | |||
executed at the MUD policy enforcement point (typically, a firewall). | executed at the MUD policy enforcement point (typically, a firewall). | |||
Conceretely, the firewall has access only to the Layer 3 headers of | Concretely, the firewall has access only to the Layer 3 headers of | |||
the packet. This includes the source and destination IP address, and | the packet. This includes the source and destination IP address, and | |||
if not encrypted by IPsec, the destination UDP or TCP port number | 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! | |||
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 IP addresses. | mapping between the names in the ACLs and IP addresses. | |||
In order for manufacturers to understand how to configure DNS | In order for manufacturers to understand how to configure DNS | |||
associated with name based ACLs, a model of how the DNS resolution | associated with name based ACLs, a model of how the DNS resolution | |||
will be done by MUD controllers is necessary. Section 3 models some | will be done by MUD controllers is necessary. Section 3 models some | |||
skipping to change at page 4, line 9 ¶ | skipping to change at page 4, line 14 ¶ | |||
Section 5 details how current trends in DNS resolution such as public | Section 5 details how current trends in DNS resolution such as public | |||
DNS servers, DNS over TLS (DoT) [RFC7858], DNS over HTTPS (DoH) | DNS servers, DNS over TLS (DoT) [RFC7858], DNS over HTTPS (DoH) | |||
[RFC8484], or DNS over QUIC (DoQ) [RFC9250] can cause problems with | [RFC8484], or DNS over QUIC (DoQ) [RFC9250] can cause problems with | |||
the strategies employed. | the strategies employed. | |||
The core of this document, is Section 6, which makes a series of | The core of this document, is Section 6, which makes a series of | |||
recommendations ("best current practices") for manufacturers on how | recommendations ("best current practices") for manufacturers on how | |||
to use DNS and IP addresses with MUD supporting IoT devices. | to use DNS and IP addresses with MUD supporting IoT devices. | |||
Section 7 discusses a set of privacy issues that encrypted DNS (DoT, | Section 8 discusses a set of privacy issues that encrypted DNS (DoT, | |||
DoH, for example) are frequently used to deal with. How these | DoH, for example) are frequently used to deal with. 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. | |||
Section 8 also covers some of the negative outcomes should MUD/ | Section 9 also covers some of the negative outcomes should MUD/ | |||
firewall managers and IoT manufacturers choose not to cooperate. | firewall managers and IoT manufacturers choose 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. | |||
This document makes use of terms defined in [RFC8520] and | This document makes use of terms defined in [RFC8520] and | |||
[I-D.ietf-dnsop-rfc8499bis]. | [I-D.ietf-dnsop-rfc8499bis]. | |||
The term "anti-pattern" comes from agile software design literature, | The term "anti-pattern" comes from agile software design literature, | |||
as per [antipatterns]. | as per [antipatterns]. | |||
3. A model for MUD controller mapping of names to addresses | CDN refers to Content Distribution Networks, such as described by | |||
[RFC6707], Section 1.1. | ||||
3. A model for MUD controller mapping of DNS names to addresses | ||||
This section details a strategy that a MUD controller could take. | This section details a strategy that a MUD controller could take. | |||
Within the limits of DNS use detailed in Section 6, this process can | Within the limits of DNS use detailed in Section 6, this process can | |||
work. The methods detailed in Appendix A just will not work. | 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 | |||
actual ACLs. | actual ACLs. | |||
There a number of possible failures, and the goal of this section is | There a number of possible failures, and the goal of this section is | |||
to explain how some common DNS usages may fail. | to explain how some common DNS usages may fail. | |||
3.1. Non-Deterministic Mappings | 3.1. Non-Deterministic Mappings | |||
The most important one is that the mapping of the names to IP | The most important one is that the mapping of the DNS names to IP | |||
addresses may be non-deterministic. | addresses may be non-deterministic. | |||
[RFC1794] describes the very common mechanism that returns DNS A (or | [RFC1794] describes the very common mechanism that returns DNS A (or | |||
reasonably AAAA) records in a permuted order. This is known as Round | reasonably AAAA) records in a permuted order. This is known as Round | |||
Robin DNS, and it has been used for many decades. The historical | 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 | 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 | that is returned. As each query results in addresses in a different | |||
ordering, the effect is to split the load among many servers. | 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/ | |||
skipping to change at page 6, line 28 ¶ | 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. | |||
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 | 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 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 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 an 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 (CDNs) 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. References within that | endpoint. This is easily described in MUD. References within that | |||
control protocol are made to additional content at other URLs. The | control protocol are made to additional content at other URLs. The | |||
values of those URLs do not fit any easily described pattern and may | values of those URLs do not fit any easily described pattern and may | |||
point at arbitrary names. | point at arbitrary DNS names. | |||
Those names are often within some third-party CDN system, or may be | ||||
arbitrary names in a cloud-provider storage system (e.g., [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, to a name that might look like "g7.a.example", with the | of the device manufacturer. The device manufacturer is asked to | |||
expectation that the CDN vendors DNS will do all the appropriate work | point a CNAME to the CDN, to a name that might look like | |||
to geolocate the transfer. This can be fine for a MUD file, as the | "g7.a.example", with the expectation that the CDN vendors DNS will do | |||
MUD controller, if located in the same geography as the IoT device, | all the appropriate work to geolocate the transfer. This can be fine | |||
can follow the CNAME, and can collect the set of resulting IP | for a MUD file, as the MUD controller, if located in the same | |||
addresses, along with the TTL for each. The MUD controller can then | geography as the IoT device, can follow the CNAME, and can collect | |||
take charge of refreshing that mapping at intervals driven by the | the set of resulting IP addresses, along with the TTL for each. The | |||
TTL. | 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 | 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 in the DNS for the the name that it lists in the MUD file. | device manufacturer can list all those IP addresses in the DNS for | |||
As 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.example.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. | |||
skipping to change at page 9, line 50 ¶ | skipping to change at page 10, line 19 ¶ | |||
unencrypted DNS (a.k.a. Do53), it is possible to outsource DNS | unencrypted DNS (a.k.a. Do53), it is possible to outsource DNS | |||
queries to other public services, such as those operated by Google, | queries to other public services, such as those operated by Google, | |||
CloudFlare, Verisign, etc. | CloudFlare, Verisign, etc. | |||
For some users and classes of devices, 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. | ||||
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 | 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 | |||
skipping to change at page 10, 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 CDN, prefer stable names that point to | When aliases point to a CDN, prefer stable DNS names that point to | |||
appropriately load balanced targets. CDNs that employ very low time- | appropriately load balanced targets. CDNs that employ very low time- | |||
to-live (TTL) values for DNS make it harder for the MUD controller to | to-live (TTL) values for DNS make it harder for the MUD controller to | |||
get the same answer as the IoT Device. A CDN that always returns the | get the same answer as the IoT Device. A CDN that always returns the | |||
same set of A and AAAA records, but permutes them to provide the best | same set of A and AAAA records, but permutes them to provide the best | |||
one first provides a more reliable answer. | one first provides a more reliable answer. | |||
6.4. Do Not Use Tailored Responses to answer DNS Names | 6.4. Do Not Use Tailored Responses to answer DNS Names | |||
[RFC7871] defines the edns-client-subnet (ECS) EDNS0 option, and | [RFC7871] defines the edns-client-subnet (ECS) EDNS0 option, and | |||
explains how authoritative servers sometimes answer queries | explains how authoritative servers sometimes answer queries | |||
differently based upon the IP address of the end system making the | differently based upon the IP address of the end system making the | |||
request. Ultimately, the decision is based upon some topological | request. Ultimately, the decision is based upon some topological | |||
notion of closeness. This is often used to provide tailored | notion of closeness. This is often used to provide tailored | |||
responses to clients, providing them with a geographically | responses to clients, providing them with a geographically | |||
advantageous answer. | advantageous answer. | |||
When the MUD controller makes it's DNS query, it is critical that it | When the MUD controller makes its DNS query, it is critical that it | |||
receive an answer which is based upon the same topological decision | receive an answer which is based upon the same topological decision | |||
as when the IoT device makes its query. | as when the IoT device makes its query. | |||
There are probably ways in which the MUD controller could use the | There are probably ways in which the MUD controller could use the | |||
edns-client-subnet option to make a query that would get the same | 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 | treatment as when the IoT device makes its query. If this worked | |||
then it would receive the same answer as the IoT device. | then it would receive the same answer as the IoT device. | |||
In practice it could be quite difficult if the IoT device uses a | In practice it could be quite difficult if the IoT device uses a | |||
different Internet connection, a different firewall, or a different | different Internet connection, a different firewall, or a different | |||
recursive DNS server. The edns-client-server might be ignored or | recursive DNS server. The edns-client-server might be ignored or | |||
overridden by any of the DNS infrastructure. | overridden by any of the DNS infrastructure. | |||
Some tailored responses might only re-order the replies so that the | Some tailored responses might only re-order the replies so that the | |||
most preferred address is first. Such a system would be acceptable | most preferred address is first. Such a system would be acceptable | |||
if the MUD controller had a way to know that the list was complete. | if the MUD controller had a way to know that the list was complete. | |||
But, due to the above problems, a strong recommendation is to avoid | But, due to the above problems, a strong recommendation is to avoid | |||
using tailored responses as part of the names in the MUD file. | using tailored responses as part of the DNS names in the MUD file. | |||
6.5. Prefer DNS Servers Learnt From DHCP/Route Advertisements | 6.5. Prefer DNS Servers Learnt From DHCP/Router Advertisements | |||
IoT Devices SHOULD prefer doing DNS with the DHCP provided DNS | The best practice is for IoT Devices to do DNS with the DHCP provided | |||
servers. | DNS servers, or DNS servers learnt from Router Advertisements | |||
[RFC8106]. | ||||
The ADD WG has written [RFC9463] and [RFC9462] to provide information | The ADD WG has written [RFC9463] and [RFC9462] to provide information | |||
to end devices on how to find locally provisioned secure/private DNS | to end devices on how to find locally provisioned secure/private DNS | |||
servers. | servers. | |||
Use of public resolvers instead of the provided DNS resolver, whether | Use of public resolvers instead of the locally provided DNS resolver, | |||
Do53, DoQ, DoT or DoH is discouraged. Should the network provide | whether Do53, DoQ, DoT or DoH is discouraged. | |||
such a resolver for use, then there is no reason not to use it, as | ||||
the network operator has clearly thought about this. | ||||
Some manufacturers would like to have a fallback to using a public | Some manufacturers would like to have a fallback to using a public | |||
resolver to mitigate against local misconfiguration. There are a | resolver to mitigate against local misconfiguration. There are a | |||
number of reasons to avoid this, or at least do this very carefully. | number of reasons to avoid this, 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 13, line 8 ¶ | 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) | ||||
While a vendor proprietary scheme to distribute firmware updates | ||||
would satisfy some of these criteria, operators/Enterprises are less | ||||
likely to install one of these for every single device class. Home | ||||
(residential) users are unlikely to install any system that did not | ||||
provide service to all their devices (and came pre-installed on a | ||||
home router or other home network management system, such as a home | ||||
Network Attached Storage device), so only a system that was non- | ||||
proprietary is likely to be present. | ||||
8. Security Considerations | 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>. | |||
skipping to change at page 14, line 29 ¶ | skipping to change at page 15, line 30 ¶ | |||
[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-snac-simple] | ||||
Lemon, T. and J. Hui, "Automatically Connecting Stub | ||||
Networks to Unmanaged Infrastructure", Work in Progress, | ||||
Internet-Draft, draft-ietf-snac-simple-04, 4 March 2024, | ||||
<https://datatracker.ietf.org/doc/html/draft-ietf-snac- | ||||
simple-04>. | ||||
[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., | [RFC7858] Hu, Z., Zhu, L., Heidemann, J., Mankin, A., Wessels, D., | |||
and P. Hoffman, "Specification for DNS over Transport | and P. Hoffman, "Specification for DNS over Transport | |||
Layer Security (TLS)", RFC 7858, DOI 10.17487/RFC7858, May | Layer Security (TLS)", RFC 7858, DOI 10.17487/RFC7858, May | |||
2016, <https://www.rfc-editor.org/info/rfc7858>. | 2016, <https://www.rfc-editor.org/info/rfc7858>. | |||
[RFC7871] Contavalli, C., van der Gaast, W., Lawrence, D., and W. | [RFC7871] Contavalli, C., van der Gaast, W., Lawrence, D., and W. | |||
Kumari, "Client Subnet in DNS Queries", RFC 7871, | Kumari, "Client Subnet in DNS Queries", RFC 7871, | |||
DOI 10.17487/RFC7871, May 2016, | DOI 10.17487/RFC7871, May 2016, | |||
<https://www.rfc-editor.org/info/rfc7871>. | <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 | [RFC8484] Hoffman, P. and P. McManus, "DNS Queries over HTTPS | |||
(DoH)", RFC 8484, DOI 10.17487/RFC8484, October 2018, | (DoH)", RFC 8484, DOI 10.17487/RFC8484, October 2018, | |||
<https://www.rfc-editor.org/info/rfc8484>. | <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>. | |||
skipping to change at page 16, line 13 ¶ | skipping to change at page 18, line 7 ¶ | |||
<https://www.rfc-editor.org/info/rfc9462>. | <https://www.rfc-editor.org/info/rfc9462>. | |||
[RFC9463] Boucadair, M., Ed., Reddy.K, T., Ed., Wing, D., Cook, N., | [RFC9463] Boucadair, M., Ed., Reddy.K, T., Ed., Wing, D., Cook, N., | |||
and T. Jensen, "DHCP and Router Advertisement Options for | and T. Jensen, "DHCP and Router Advertisement Options for | |||
the Discovery of Network-designated Resolvers (DNR)", | the Discovery of Network-designated Resolvers (DNR)", | |||
RFC 9463, DOI 10.17487/RFC9463, November 2023, | RFC 9463, DOI 10.17487/RFC9463, November 2023, | |||
<https://www.rfc-editor.org/info/rfc9463>. | <https://www.rfc-editor.org/info/rfc9463>. | |||
Appendix A. A Failing Strategy --- Anti-Patterns | Appendix A. A Failing Strategy --- Anti-Patterns | |||
Attempts to map IP addresses to names in real time fails for a number | Attempts to map IP addresses to DNS names in real time often fails | |||
of reasons: | for a number of reasons: | |||
1. it can not be done fast enough, | 1. it can not be done fast enough, | |||
2. it reveals usage patterns of the devices, | 2. it reveals usage patterns of the devices, | |||
3. the mappings are often incomplete, | 3. the mappings are often incomplete, | |||
4. Even if the mapping is present, due to virtual hosting, it may | 4. Even if the mapping is present, due to virtual hosting, it may | |||
not map back to the name used in the ACL. | not map back to the name used in the ACL. | |||
This is not a successful strategy, it MUST NOT be used for the | This is not a successful strategy, it MUST NOT be used for the | |||
reasons explained below. | reasons explained below. | |||
A.1. Too Slow | A.1. Too Slow | |||
Mappings of IP addresses to names requires a DNS lookup in the in- | Mappings of IP addresses to DNS names requires a DNS lookup in the | |||
addr.arpa or ip6.arpa space. For a cold DNS cache, this will | 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 | 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, | 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 | this easily adds up to significant time before the packet that caused | |||
the lookup can be released. | the lookup can be released. | |||
While subsequent connections to the same site (and subsequent packets | While subsequent connections to the same site (and subsequent packets | |||
in the same flow) will not be affected if the results are cached, the | 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 | 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 | 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 | repeated, e.g, in a few hours or days,when the cached IP address to | |||
skipping to change at page 17, line 7 ¶ | skipping to change at page 19, line 7 ¶ | |||
A.2. Reveals Patterns of Usage | A.2. Reveals Patterns of Usage | |||
By doing the DNS lookups when the traffic occurs, then a passive | 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 | 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 | 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 | not. This does not require access to all on-path data, just to the | |||
DNS requests to the bottom level of the DNS tree. | DNS requests to the bottom level of the DNS tree. | |||
A.3. Mappings Are Often Incomplete | A.3. Mappings Are Often Incomplete | |||
A service provider that fails to include an A or AAAA record as part | An IoT manufacturer with a cloud service provider that fails to | |||
of their forward name publication will find that the new server is | include an A or AAAA record as part of their forward name publication | |||
simply not used. The operational feedback for that mistake is | will find that the new server is simply not used. The operational | |||
immediate. The same is not true for reverse names: they can often be | feedback for that mistake is immediate. The same is not true for | |||
incomplete or incorrect for months or even years without visible | reverse DNS mappings: they can often be incomplete or incorrect for | |||
effect on operations. | months or even years without visible effect on operations. | |||
Service providers often find it difficult to update reverse maps in a | IoT manufacturer cloud service providers often find it difficult to | |||
timely fashion, assuming that they can do it at all. Many cloud | update reverse DNS maps in a timely fashion, assuming that they can | |||
based solutions dynamically assign IP addresses to services, often as | do it at all. Many cloud based solutions dynamically assign IP | |||
the service grows and shrinks, reassigning those IP addresses to | addresses to services, often as the service grows and shrinks, | |||
other services quickly. The use of HTTP 1.1 Virtual Hosting may | reassigning those IP addresses to other services quickly. The use of | |||
allow addresses and entire front-end systems to be re-used | HTTP 1.1 Virtual Hosting may allow addresses and entire front-end | |||
dynamically without even reassigning the IP addresses. | systems to be re-used dynamically without even reassigning the IP | |||
addresses. | ||||
In some cases there are multiple layers of CNAME between the original | 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 | 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 | balancing layer in the DNS, followed by a load balancing layer at the | |||
HTTP level. | HTTP level. | |||
The reverse name for the IP address of the load balancer usually does | The reverse DNS mapping for the IP address of the load balancer | |||
not change. If hundreds of web services are funneled through the | usually does not change. If hundreds of web services are funneled | |||
load balancer, it would require hundreds of PTR records to be | through the load balancer, it would require hundreds of PTR records | |||
deployed. This would easily exceed the UDP/DNS and EDNS0 limits, and | to be deployed. This would easily exceed the UDP/DNS and EDNS0 | |||
require all queries to use TCP, which would further slow down loading | limits, and require all queries to use TCP, which would further slow | |||
of the records. | down loading of the records. | |||
The enumeration of all services/sites that have been at that load | The enumeration of all services/sites that have been at that load | |||
balancer might also constitute a security concern. To limit churn of | balancer might also constitute a security concern. To limit churn of | |||
DNS PTR records, and reduce failures of the MUD ACLs, operators would | 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 | want to add all possible DNS names for each reverse DNS mapping, | |||
the DNS load balancing in the forward DNS space lists that end-point | whether or not the DNS load balancing in the forward DNS space lists | |||
at that moment. | that end-point at that moment. | |||
A.4. Forward Names Can Have Wildcards | A.4. Forward DNS Names Can Have Wildcards | |||
In some large hosting providers content is hosted through a domain | In some large hosting providers content is hosted through a domain | |||
name that is published as a DNS wildcard (and uses a wildcard | name that is published as a DNS wildcard (and uses a wildcard | |||
certificate). For instance, github.io, which is used for hosted | certificate). For instance, github.io, which is used for hosted | |||
content, including the Editors' copy of internet drafts stored on | content, including the Editors' copy of internet drafts stored on | |||
github, does not actually publish any names. Instead, a wildcard | github, does not actually publish any DNS names. Instead, a wildcard | |||
exists to answer all potential names: requests are routed appropriate | exists to answer all potential DNS names: requests are routed | |||
once they are received. | appropriate once they are received. | |||
This kind of system works well for self-managed hosted content. | This kind of system works well for self-managed hosted content. | |||
However, while it is possible to insert up to a few dozen PTR | However, while it is possible to insert up to a few dozen PTR | |||
records, many thousand entries are not possible, nor is it possible | records, many thousand entries are not possible, nor is it possible | |||
to deal with the unlimited (infinite) number of possibilities that a | to deal with the unlimited (infinite) number of possibilities that a | |||
wildcard supports. | wildcard supports. | |||
It would be therefore impossible for the PTR reverse lookup to ever | It would be therefore impossible for the PTR reverse lookup to ever | |||
work with these wildcard names. | 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. 67 change blocks. | ||||
209 lines changed or deleted | 296 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/ |