< draft-ietf-opsawg-mud-iot-dns-considerations-03.txt   draft-ietf-opsawg-mud-iot-dns-considerations-04.txt >
OPSAWG Working Group M. Richardson OPSAWG Working Group M. Richardson
Internet-Draft Sandelman Software Works Internet-Draft Sandelman Software Works
Intended status: Best Current Practice W. Pan Intended status: Best Current Practice W. Pan
Expires: 22 July 2022 Huawei Technologies Expires: 28 September 2022 Huawei Technologies
18 January 2022 27 March 2022
Operational Considerations for use of DNS in IoT devices Operational Considerations for use of DNS in IoT devices
draft-ietf-opsawg-mud-iot-dns-considerations-03 draft-ietf-opsawg-mud-iot-dns-considerations-04
Abstract Abstract
This document details concerns about how Internet of Things devices This document details concerns about how Internet of Things devices
use IP addresses and DNS names. The issue becomes acute as network use IP addresses and DNS names. The issue becomes acute as network
operators begin deploying RFC8520 Manufacturer Usage Description operators begin deploying RFC8520 Manufacturer Usage Description
(MUD) definitions to control device access. (MUD) definitions to control device access.
This document makes recommendations on when and how to use DNS names This document makes recommendations on when and how to use DNS names
in MUD files. in MUD files.
About This Document
This note is to be removed before publishing as an RFC.
Status information for this document may be found at
https://datatracker.ietf.org/doc/draft-ietf-opsawg-mud-iot-dns-
considerations/.
Discussion of this document takes place on the opsawg Working Group
mailing list (mailto:opsawg@ietf.org), which is archived at
https://mailarchive.ietf.org/arch/browse/opsawg/.
Source for this draft and an issue tracker can be found at
https://github.com/mcr/iot-mud-dns-considerations.
Status of This Memo Status of This Memo
This Internet-Draft is submitted in full conformance with the This Internet-Draft is submitted in full conformance with the
provisions of BCP 78 and BCP 79. provisions of BCP 78 and BCP 79.
Internet-Drafts are working documents of the Internet Engineering Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF). Note that other groups may also distribute Task Force (IETF). Note that other groups may also distribute
working documents as Internet-Drafts. The list of current Internet- working documents as Internet-Drafts. The list of current Internet-
Drafts is at https://datatracker.ietf.org/drafts/current/. Drafts is at https://datatracker.ietf.org/drafts/current/.
Internet-Drafts are draft documents valid for a maximum of six months Internet-Drafts are draft documents valid for a maximum of six months
and may be updated, replaced, or obsoleted by other documents at any and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress." material or to cite them other than as "work in progress."
This Internet-Draft will expire on 22 July 2022. This Internet-Draft will expire on 28 September 2022.
Copyright Notice Copyright Notice
Copyright (c) 2022 IETF Trust and the persons identified as the Copyright (c) 2022 IETF Trust and the persons identified as the
document authors. All rights reserved. document authors. All rights reserved.
This document is subject to BCP 78 and the IETF Trust's Legal This document is subject to BCP 78 and the IETF Trust's Legal
Provisions Relating to IETF Documents (https://trustee.ietf.org/ Provisions Relating to IETF Documents (https://trustee.ietf.org/
license-info) in effect on the date of publication of this document. license-info) in effect on the date of publication of this document.
Please review these documents carefully, as they describe your rights Please review these documents carefully, as they describe your rights
and restrictions with respect to this document. Code Components and restrictions with respect to this document. Code Components
extracted from this document must include Revised BSD License text as extracted from this document must include Revised BSD License text as
described in Section 4.e of the Trust Legal Provisions and are described in Section 4.e of the Trust Legal Provisions and are
provided without warranty as described in the Revised BSD License. provided without warranty as described in the Revised BSD License.
Table of Contents Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3
2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 4 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 4
3. Strategies to map names . . . . . . . . . . . . . . . . . . . 4 3. Strategies to map names . . . . . . . . . . . . . . . . . . . 4
4. DNS and IP Anti-Patterns for IoT device Manufacturers . . . . 6 4. DNS and IP Anti-Patterns for IoT device Manufacturers . . . . 6
4.1. Use of IP address literals in-protocol . . . . . . . . . 6 4.1. Use of IP address literals in-protocol . . . . . . . . . 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 inclusive DNS name . . . . . . . . . . . . . 8 4.3. Use of a too inclusive DNS name . . . . . . . . . . . . . 8
5. DNS privacy and outsourcing versus MUD controllers . . . . . 8 5. DNS privacy and outsourcing versus MUD controllers . . . . . 9
6. Recommendations to IoT device manufacturer on MUD and DNS 6. Recommendations to IoT device manufacturer on MUD and DNS
usage . . . . . . . . . . . . . . . . . . . . . . . . . . 9 usage . . . . . . . . . . . . . . . . . . . . . . . . . . 9
6.1. Consistently use DNS . . . . . . . . . . . . . . . . . . 9 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 . . 10
6.3. Use Content-Distribution Network with stable names . . . 10 6.3. Use Content-Distribution Network with stable names . . . 10
6.4. Do not use geofenced names . . . . . . . . . . . . . . . 10 6.4. Do not use geofenced names . . . . . . . . . . . . . . . 10
6.5. Prefer DNS servers learnt from DHCP/Route 6.5. Prefer DNS servers learnt from DHCP/Route
Advertisements . . . . . . . . . . . . . . . . . . . . . 10 Advertisements . . . . . . . . . . . . . . . . . . . . . 10
7. Privacy Considerations . . . . . . . . . . . . . . . . . . . 11 7. Privacy Considerations . . . . . . . . . . . . . . . . . . . 11
8. Security Considerations . . . . . . . . . . . . . . . . . . . 12 8. Security Considerations . . . . . . . . . . . . . . . . . . . 12
9. References . . . . . . . . . . . . . . . . . . . . . . . . . 12 9. References . . . . . . . . . . . . . . . . . . . . . . . . . 12
9.1. Normative References . . . . . . . . . . . . . . . . . . 13 9.1. Normative References . . . . . . . . . . . . . . . . . . 13
9.2. Informative References . . . . . . . . . . . . . . . . . 14 9.2. Informative References . . . . . . . . . . . . . . . . . 14
skipping to change at page 3, line 10 skipping to change at page 3, line 18
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 RFC8520 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 DNS
name. name.
Use of a DNS name rather than IP address in the ACL has many Use of a DNS name rather than IP address in the 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 name to IP address to be changed over time, it also generalizes
automatically to IPv4 and IPv6 addresses, as well as permitting automatically to IPv4 and IPv6 addresses, as well as permitting
loading balancing of traffic by many different common ways, including loading balancing of traffic by many different common ways, including
geography. multi-CDN deployments wherein load balancing can account for
geography and load.
At the MUD policy enforcement point - the firewall - there is a At the MUD policy enforcement point -- the firewall -- there is a
problem. The firewall has only access to the layer-3 headers of the problem. The firewall has only access to the layer-3 headers of the
packet. This includes the source and destination IP address, and if packet. This includes the source and destination IP address, and if
not encrypted by IPsec, the destination UDP or TCP port number 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 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 forced intermediate for the TLS connections. This could in theory be
done for TLS 1.2 connections. The MUD policy enforcement point could done for TLS 1.2 connections. The MUD policy enforcement point could
observe the Server Name Identifier (SNI) [RFC6066]. Some Enterprises observe the Server Name Identifier (SNI) [RFC6066]. Some Enterprises
do this already. But, as this involves active termination of the TCP do this already. But, as this involves active termination of the TCP
skipping to change at page 4, line 37 skipping to change at page 4, line 46
2. it reveals usage patterns of the devices, 2. it reveals usage patterns of the devices,
3. the mapping are often incomplete, 3. the mapping 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, its use is NOT RECOMMENDED. This is not a successful strategy, its use is NOT RECOMMENDED.
XXX -- explain in detail how this can fail. XXX --- explain in detail how this can fail.
XXX -- explain N:1 vs 1:1 for virtual hosting. XXX --- explain N:1 vs 1:1 for virtual hosting.
The simplest successful strategy for translating names is for a MUD The simplest successful strategy for translating names is 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. physical ACLs.
There are still a number of failures possible. There are still a number of failures possible.
The most important one is in the mapping of the names to IP addresses The most important one is in the mapping of the names to IP addresses
may be non-deterministic. [RFC1794] describes the very common may be non-deterministic. [RFC1794] describes the very common
skipping to change at page 5, line 36 skipping to change at page 5, line 43
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 does the lookup, and this change can
result in a failure for the ACL to match. result in a failure for the ACL to match.
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 do DNS lookups in order to get never have stale data. These lookups
avoid load. It may be necessary to avoid recursive DNS servers in need to be rate limited in order to avoid load. It may be necessary
order to avoid receiving cached data. Properly designed recursive to avoid local recursive DNS servers. The MUD controller SHOULD
servers should cache data for many minutes to days, while the incorporate its own recursive caching DNS server. Properly designed
underlying DNS data can change at a higher frequency, providing recursive servers should cache data for many minutes to days, while
the underlying DNS data can change at a higher frequency, providing
different answers to different queries! 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 that the
IoT device will use can instead query that server on a periodic IoT device will use can instead query that server on a periodic
basis. Doing so provides three advantages: basis. 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
skipping to change at page 8, line 21 skipping to change at page 8, line 31
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 end point. This is easily described in MUD. Within that control
protocol references are made to additional content at other URLs. protocol references are made to additional content at other URLs.
The values of those URLs do not fit any easily described pattern and The values of those URLs do not fit any easily described pattern and
may point at arbitrary names. may point at arbitrary names.
Those names are often within some third-party Content-Distribution- Those names are often within some third-party Content-Distribution-
Network (CDN) system, or may be arbitrary names in a cloud-provider Network (CDN) system, or may be arbitrary names in a cloud-provider
storage system such as Amazon S3 (such [AmazonS3], or [Akamai]). storage system such as Amazon S3 (such [AmazonS3], or [Akamai]).
Since it is not possible to predict a name for where the content will Such names may be unpredictably chosen by the content provider, and
be, it is not possible to include that into the MUD file. not the content owner, and so impossible to insert into a MUD file.
This applies to the firmware update situation as well. Even if the content provider chosen names are deterministic they may
change at a rate much faster than MUD files can be updated.
This in particular may apply to the location where firmware updates
may be retrieved.
4.3. Use of a too inclusive DNS name 4.3. Use of a too inclusive DNS name
Some CDNs make all customer content at a single URL (such as Some CDNs make all customer content at a single URL (such as
s3.amazonaws.com). This seems to be ideal from a MUD point of view: s3.amazonaws.com). This seems to be ideal from a MUD point of view:
a completely predictable URL. The problem is that a compromised a completely predictable URL.
device could then connect to any S3 bucket, potentially attacking
other buckets. 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 to 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 DNS over TLS (DoT) and DNS over
HTTPS (DoH). [I-D.ietf-dnsop-terminology-ter] details the terms. HTTPS (DoH). [I-D.ietf-dnsop-terminology-ter] details the terms.
But, even with traditional DNS over Port-53 (Do53), it is possible to But, even with traditional DNS over Port-53 (Do53), it is possible to
outsource DNS queries to other public services, such as those outsource DNS queries to other public services, such as those
operated by Google, CloudFlare, Verisign, etc. operated by Google, CloudFlare, Verisign, etc.
There are significant privacy issues with having IoT devices sending For some users and classes of device, revealing the DNS queries to
their DNS queries to an outside entity. Doing it over a secure those outside entities may consititute 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 A 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.
resolvers (such as Google's 8.8.8.8) at first seems to present less
of a problem than use of some other less well known resolver. While
any system may use QuadX, in most cases those services are massively
replicated via anycast: there is no guarantee that a MUD controller
will speak to the same instance, or get the same geographic anycast
result.
XXX - THIS NEEDS WAY MORE EXPLANATION.
6. Recommendations to IoT device manufacturer on MUD and DNS usage 6. Recommendations to IoT device manufacturer 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
[I-D.richardson-mud-qrcode]. [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
skipping to change at page 10, line 36 skipping to change at page 10, line 42
more reliable answer. more reliable answer.
6.4. Do not use geofenced names 6.4. Do not use geofenced names
Due the problems with different answers from different DNS servers, Due the problems with different answers from different DNS servers,
described above, a strong recommendation is to avoid using such described above, a strong recommendation is to avoid using such
things. things.
6.5. Prefer DNS servers learnt from DHCP/Route Advertisements 6.5. Prefer DNS servers learnt from DHCP/Route Advertisements
XXX - it has been suggested that this will not help, thus previous
recommendation.
IoT Devices should prefer doing DNS to the network provided DNS IoT Devices should prefer doing DNS to the network provided DNS
servers. Whether this is restricted to Classic DNS (Do53) or also servers. Whether this is restricted to Classic DNS (Do53) or also
includes using DoT/DoH is a local decision, but a locally provided includes using DoT/DoH is a local decision, but a locally provided
DoT server SHOULD be used, as recommended by DoT server SHOULD be used, as recommended by
[I-D.reddy-dprive-bootstrap-dns-server] and [I-D.peterson-doh-dhcp]. [I-D.reddy-dprive-bootstrap-dns-server] and [I-D.peterson-doh-dhcp].
The ADD WG is currently only focusing on insecure discovery The ADD WG is currently only focusing on insecure discovery
mechanisms like DHCP/RA [I-D.btw-add-home] and DNS based discovery mechanisms like DHCP/RA [I-D.btw-add-home] and DNS based discovery
mechanisms ({?{I-D.pauly-add-deer}}). Secure discovery of network mechanisms ({?{I-D.pauly-add-deer}}). Secure discovery of network
provided DoH/DoT resolver is possible using the mechanisms discussed provided DoH/DoT resolver is possible using the mechanisms discussed
in [I-D.reddy-add-enterprise] section-4. in [I-D.reddy-add-enterprise] section-4.
Use of public QuadX resolver instead of the provided DNS resolver, Use of public QuadX resolver instead of the provided DNS resolver,
whether Do53, DoT or DoH is discouraged. Should the network provide whether Do53, DoT or DoH is discouraged. Should the network provide
such a resolver for use, then there is no reason not to use it, as such a resolver for use, then there is no reason not to use it, as
the network operator has clearly thought about this. the network operator has clearly thought about this.
Some manufacturers would like to have a fallback to using a public Some manufacturers would like to have a fallback to using a public
resolver to mitigate against local misconfiguration. There are a resolver to mitigate against local misconfiguration. There are a
number of reasons to avoid this, or at least do this very carefully. number of reasons to avoid this, or at least do this very carefully.
The recommendation here is to do this only when the provided
resolvers provide no answers to any queries at all, and do so It is recommended that use of non-local resolvers is only done when
repeatedly. The use of the operator provided resolvers SHOULD be the locally provided resolvers provide no answers to any queries at
retried on a periodic basis, and once they answer, there should be no all, and do so repeatedly. The use of the operator provided
further attempts to contact public resolvers. 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 Finally, the list of public resolvers that might be contacted MUST be
listed in the MUD file as destinations that are to be permitted! listed in the MUD file as destinations that are to be permitted!
This should include the port numbers (53, 853 for DoT, 443 for DoH) This should include the port numbers (53, 853 for DoT, 443 for DoH)
that will be used as well. that will be used as well.
7. Privacy Considerations 7. Privacy Considerations
The use of non-local DNS servers exposes the list of names resolved The use of non-local DNS servers exposes the list of names resolved
to a third parties, including passive eavesdroppers. to a third parties, including passive eavesdroppers.
skipping to change at page 15, line 8 skipping to change at page 15, line 8
Boucadair, M., Reddy, T., Wing, D., Cook, N., and T. Boucadair, M., Reddy, T., Wing, D., Cook, N., and T.
Jensen, "DHCP and Router Advertisement Options for Jensen, "DHCP and Router Advertisement Options for
Encrypted DNS Discovery", Work in Progress, Internet- Encrypted DNS Discovery", Work in Progress, Internet-
Draft, draft-btw-add-home-12, 22 January 2021, Draft, draft-btw-add-home-12, 22 January 2021,
<https://www.ietf.org/archive/id/draft-btw-add-home- <https://www.ietf.org/archive/id/draft-btw-add-home-
12.txt>. 12.txt>.
[I-D.pauly-dprive-oblivious-doh] [I-D.pauly-dprive-oblivious-doh]
Kinnear, E., McManus, P., Pauly, T., Verma, T., and C. A. Kinnear, E., McManus, P., Pauly, T., Verma, T., and C. A.
Wood, "Oblivious DNS Over HTTPS", Work in Progress, Wood, "Oblivious DNS Over HTTPS", Work in Progress,
Internet-Draft, draft-pauly-dprive-oblivious-doh-09, 5 Internet-Draft, draft-pauly-dprive-oblivious-doh-11, 17
January 2022, <https://www.ietf.org/archive/id/draft- February 2022, <https://www.ietf.org/archive/id/draft-
pauly-dprive-oblivious-doh-09.txt>. pauly-dprive-oblivious-doh-11.txt>.
[I-D.reddy-add-enterprise] [I-D.reddy-add-enterprise]
Reddy, T. and D. Wing, "DNS-over-HTTPS and DNS-over-TLS Reddy, T. and D. Wing, "DNS-over-HTTPS and DNS-over-TLS
Server Deployment Considerations for Enterprise Networks", Server Deployment Considerations for Enterprise Networks",
Work in Progress, Internet-Draft, draft-reddy-add- Work in Progress, Internet-Draft, draft-reddy-add-
enterprise-00, 23 June 2020, enterprise-00, 23 June 2020,
<https://www.ietf.org/archive/id/draft-reddy-add- <https://www.ietf.org/archive/id/draft-reddy-add-
enterprise-00.txt>. enterprise-00.txt>.
[I-D.richardson-mud-qrcode] [I-D.richardson-mud-qrcode]
Richardson, M., Latour, J., and H. H. Gharakheili, "On Richardson, M., Latour, J., and H. H. Gharakheili, "On
loading MUD URLs from QR codes", Work in Progress, loading MUD URLs from QR codes", Work in Progress,
Internet-Draft, draft-richardson-mud-qrcode-03, 11 January Internet-Draft, draft-richardson-mud-qrcode-07, 21 March
2022, <https://www.ietf.org/archive/id/draft-richardson- 2022, <https://www.ietf.org/archive/id/draft-richardson-
mud-qrcode-03.txt>. mud-qrcode-07.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 Appendix A. Appendices
 End of changes. 24 change blocks. 
51 lines changed or deleted 68 lines changed or added

This html diff was produced by rfcdiff 1.48. The latest version is available from http://tools.ietf.org/tools/rfcdiff/