draft-ietf-opsawg-mud-iot-dns-considerations-02.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: 12 January 2022 Huawei Technologies Expires: 4 January 2025 Huawei Technologies
11 July 2021 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-02 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 explains the problem through a series of examples of Also, this document makes recommendations on when and how to use DNS
what can go wrong, and then provides some advice on how a device names in MUD files.
manufacturer can best make deal with these issues. The
recommendations have an impact upon device and network protocol
design.
{RFC-EDITOR, please remove. Markdown and issue tracker for this About This Document
document is at https://github.com/mcr/iot-mud-dns-considerations.git
} 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 12 January 2022. This Internet-Draft will expire on 4 January 2025.
Copyright Notice Copyright Notice
Copyright (c) 2021 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 Simplified BSD License text extracted from this document must include Revised BSD License text as
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 Simplified 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 . . . . . 7 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 . . 9 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 . . . . . . . . . . . . . . . . . . 12 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
anti-patterns get in the way this mapping.
The third section of this document details how current trends in DNS
presolution such as public DNS servers, DNS over TLS (DoT), and DNS
over HTTPS (DoH) cause problems for the strategies employed. Poor
interactions with content-distribution networks is a frequent
pathology that can result.
The fourth section of this document makes a series of recommendations
("best current practices") for manufacturers on how to use DNS, and
IP addresses with specific purpose IoT devices.
The Privacy Considerations section concerns itself with issues that In order for manufacturers to understand how to configure DNS
DNS-over-TLS and DNS-over-HTTPS are frequently used to deal with. associated with name based ACLs, a model of how the DNS resolution
How these concerns apply to IoT devices located within a residence or will be done by MUD controllers is necessary. Section 3 models some
enterprise is a key concern. good strategies that are used.
The Security Considerations section covers some of the negative This model is non-normative: but is included so that IoT device
outcomes should MUD/firewall managers and IoT manufacturers choose manufacturers can understand how the DNS will be used to resolve the
not to cooperate. names they use.
2. Terminology There are some ways of using DNS that will present problems for MUD
controllers, which Section 4 explains.
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", Section 5 details how current trends in DNS resolution such as public
"SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and DNS servers, DNS over TLS (DoT) [RFC7858], DNS over HTTPS (DoH)
"OPTIONAL" in this document are to be interpreted as described in [RFC8484], or DNS over QUIC (DoQ) [RFC9250] can cause problems with
BCP 14 [RFC2119] [RFC8174] when, and only when, they appear in all the strategies employed.
capitals, as shown here.
This document is a Best Current Practices (BCP) document. It uses The core of this document, is Section 6, which makes a series of
the above language where it needs to make a normative requirement on recommendations ("best current practices") for manufacturers on how
implementations. to use DNS and IP addresses with MUD supporting IoT devices.
3. Strategies to map names 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.
The most naive method is to try to map IP addresses to names using Section 9 also covers some of the negative outcomes should MUD/
the in-addr.arpa (IPv4), and ipv6.arpa (IPv6) mappings. This fails firewall managers and IoT manufacturers choose not to cooperate.
for a number of reasons:
1. it can not be done fast enough, 2. Terminology
2. it reveals usage patterns of the devices, Although this document is not an IETF Standards Track publication, it
adopts the conventions for normative language to provide clarity of
instructions to the implementer. The key words "MUST", "MUST NOT",
"REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT",
"RECOMMENDED", "NOT RECOMMENDED", "MAY", and "OPTIONAL" in this
document are to be interpreted as described in BCP 14 [RFC2119]
[RFC8174] when, and only when, they appear in all capitals, as shown
here.
3. the mapping are often incomplete, This document makes use of terms defined in [RFC8520] and
[I-D.ietf-dnsop-rfc8499bis].
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, and do not use it. 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 an HTTPS, sometimes with a POST, but the method is immaterial) to a
authoritatve server. (What is this) The current firmware model of vendor system that knows whether an update is required.
the device is sometimes provided and then the authoritative server
provides a determination if a new version is required, and if so, The current firmware model of the device is sometimes provided and
what version. In simpler cases, an HTTPS end point is queried which then the vendor's authoritative server provides a determination if a
provides the name and URL of the most recent firmware. new version is required and, if so, what version. In simpler cases,
an HTTPS endpoint is queried which provides the name and URL of the
most 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
The first recommendation is to avoid using IP address literals in any For the reasons explained in Section 4.1, the most important
protocol. Names should always be used. recommendation is to avoid using IP address literals in any protocol.
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-06, 8
March 2021, <https://www.ietf.org/archive/id/draft-pauly-
dprive-oblivious-doh-06.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-00, 17
December 2020, <https://www.ietf.org/archive/id/draft-
richardson-mud-qrcode-00.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. 106 change blocks. 
412 lines changed or deleted 643 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/