Operational Considerations for Use of DNS in IoT Devices
draft-ietf-opsawg-mud-iot-dns-considerations-13

[Ballot comment]
Thank you Dave for the IOTDIR, Nicolai for the DNSDIR, and Christopher for the SECDIR review.

I support Paul and Roman's DISCUSS, and all the comments posted by the reviewers.I will note that IOTDIR, DNSDIR, and SECDIR independently have raised issues that I hope the authors will work through when they publish the next version of the draft.

[Ballot comment]
Thank you Dave for the IOTDIR, Nicolai for the DNSDIR, and Christopher for the SECDIR review.

I support Paul and Roman's DISCUSS, and all the comments posted by all the reviewers.I will note that IOTDIR, DNSDIR, and SECDIR independently have raised issues that I hope the authors will work through when they publish the next version of the draft.

[Ballot comment]
I support Paul's DISCUSS position and many of his comments.

I also agree with Murray's comments, especially regarding Informational status possibly being a better choice.

[Ballot comment]
No objection from transport layer specific issues, however, this was not a easy read for me. It often convolutes process steps with practice, issues and recommendations, hence hard to follow.

I strongly support Paul's discuss points.

I have following comments/questions and I believe the document will be enriched if those are addressed:

- Abstract : it says -

      This document details concerns about how Internet of Things devices use IP addresses and DNS names.

  I am with the impression that these concerns are not for the entire community of IoT devices, rather for those uses MUD and wanted to use DNS. Also detailing only concerns does not seem the entire goal of this document. Why does the document start with such statement? 

- Please define "antipattern" in this document. I understand it comes from an external source, any day that definition can change and the usage of "antipattern" in this document may become out of context. It is better to agree on what the "antipattern" means in the context of this document.

- Section 1 : This references to sections to describe particular things and that reference does not map to the section numbers of this document. I think there is not need to such calling out of sections in the introduction, it is confusing.

- Section 1 :

          The third section of this document details how current trends in DNS resolution such as public DNS servers, DNS over TLS (DoT), DNS over QUIC (DoQ), and DNS over HTTPS (DoH) cause problems for the strategies employed.

  Where can I find the promised details? DoQ is only mentioned once in later sections.

- Section 6:
  - Please explain the geofenced name before providing recommendations for it. 
  - How should the manufacturers interpret "strong recommendation" ? Is there any particular reason not to use normative text here?

[Ballot comment]
I support Paul's DISCUSS position and many of his comments.

I understand why this is seeking BCP status, but I think it's unusual for something claiming to be "Considerations" to seek that status.  I think this is more suited to Informational.

Please expand "ECH" on first use.

If Section 3.1 describes a "failing strategy", why is it only NOT RECOMMENDED?

In Section 3.2, what is a "physical ACL"?

Also, Section 3.2 seems to use a lot of space describing the benefits of DNS caching, TTLs, etc.  Someone with a moderate understanding of DNS would already get all of this.  I think it could use some editing down.

Section 4.1: I think "inprotocol" should be "in-protocol", although I don't know if that's a word either.  I would use neither; it's fine without.

Also in Section 4.1, the final paragraph (or at least its first sentence) seems a bit mangled.

The title of Section 6.1 doesn't appear (to me) to match what it says.

For Section 6.4, can we define "geofenced" or provide a reference?  This is the first time that term is used in this document.

For a BCP, Section 6.5 feels mushy.  It says the best practice is (thing), but then buffers it with SHOULDs.  I think you should say what the best practice is and stop.  If someone elects to deviate, then they're not doing what the best practice is.

===

From Orie Steele, incoming ART Area Director:

In 4.2. Use of non-deterministic DNS names in-protocol

> Within that control protocol references are made to additional content at other URLs. The values of those URLs do not fit any easily described pattern and may point at arbitrary names.

Seems to rely on RFC9238 to define what constitutes a well formed URL, which in turn references RFC3986

https://www.rfc-editor.org/rfc/rfc3986#section-7.1

I believe this imposes some interoperability considerations regarding IDNA.

Some comments or guidance on what international domain names and URLs are acceptable might be useful, please consider a reference to https://datatracker.ietf.org/doc/html/rfc5895

[Ballot comment]
Thanks for this document. Paul Wouters DISCUSS rings true for me. I do have one small comment. Probably this is just an editing mistake left over from some earlier revision. The last para of the Intro is:

```
  The Security Considerations section covers some of the negative
  outcomes should MUD/firewall managers and IoT manufacturers choose
  not to cooperate.
```

It doesn't, though. I guess either fix the SecCons to do what the Intro says, or change the Intro to accurately describe the SecCons.

[Ballot discuss]
** Section 7.
  The use of a publicly specified firmware update protocol would also
  enhance privacy of IoT devices.  In such a system, the IoT device
  would never contact the manufacturer for version information or for
  firmware itself.

Why does the use of a “publicly specified firmware update protocol” necessarily enhance privacy?  Do all such protocols have the properties described in the second sentence?

[Ballot comment]
Thank you to Chris Wood for the SECDIR review.

I support the DISCUSS position of Paul Wouters.  Judging by the title, abstract, framing in Section 1 and the tradeoff presenting in Section 8, it isn’t clear if this guidance is for “all IoT devices” or “only IoT devices that support MUD”; and if this is intended for enterprise and home deployments.  In the spirit of simplifying the adjudication of feedback, I tried my best not duplicate points from Paul's COMMENT ballot.  Some of the points below are further examples of this scope confusion.

** Section 1.
  In TLS 1.3, with or without the use of ECH, middleboxes cannot rely
  on SNI inspection because malware could lie about the SNI.

Can’t malware also lie about the SNI in TLS 1.2?

** Section 2.
  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.

Isn’t common for BCPs to use RFC2119 language.

** Section 3.1.3.  Who are these service providers whose role it is to maintain reverse mappings relative to the actors I thought were in question – device manufacturer and owner/operator? 

** Section 4.1  Editorial. Is it “4.1.  Use of IP address literals inprotocol” or “in-protocol”?

** Section 4.1.  Editorial.
  (often over
  HTTPS, sometimes with a POST, but the method is immaterial)

If is immaterial, why mention it?

** Section 4.1
  The current firmware model of the device is sometimes provided and
  then the authoritative server provides a determination if a new
  version is required and, if so, what version.

What’s the authoritative server in this model?  Is it the “vendor system” mentioned in the previous sentence?

** Section 4.1
  The first is that it eliminates problems with firmware updates that
  might be caused by lack of DNS, or incompatibilities with DNS.

I’m confused on what is the anti-pattern.  It’s acceptable for the device to initial query the authoritative server via IP (I say acceptable because there isn’t guidance cautioning against it), but if the authoritative server responds back with an URI with an IP, this is a problem? 

** Section 4.1
  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
  kinds of addresses, and can also contain many different IP addresses
  of each kind.

Couldn’t the update service know which IP address family it was contacted over and serve a response back in that family (in addition to including both addresses in the HTTP API)?

** Section 4.1
  Finally, it is common in some content-distribution networks (CDN) to
  use multiple layers of DNS CNAMEs in order to isolate the content-
  owner's naming system from changes in how the distribution network is
  organized.

Understood.  Who is this a problem for?  What if the vendor doesn’t use a CDN?

** Section 4.3.  Who is this section directed at?  Based on Section 4’s title of “DNS and IP Anti-Patterns for IoT device Manufacturers”, it seems like it is manufacturers.  However, the text in this section seems to be discussing CDN behavior.  Are manufacturers supposed to avoid CDNs that follow this behavior? 

** Section 5.  What is the actionable BCP or design guidance from this section?

** Section 6. 
  The difficult part is determining what to put into the MUD file
  itself.  There are currently tools that help with the definition and
  analysis of MUD files, see [mudmaker].  The remaining difficulty is
  now the actual list of expected connections to put in the MUD file.
  An IoT manufacturer must now spend some time reviewing the network
  communications by their device.

How is this germane to MUD and DNS?

** Section 6.5

  Should the network provide
  such a resolver for use, then there is no reason not to use it, as
  the network operator has clearly thought about this.

Can more be said about the basis of this confidence.  I can see the rationale in some enterprise scenario.  Section 7 makes a case for the opposite advice -- “The use of unencrypted (Do53) requests to a local DNS server exposes the list to any internal passive eavesdroppers, and for some situations that may be significant, particularly if unencrypted Wi-Fi
is used.”

** Section 7.  I found this Privacy Considerations lacking a basic explanation of the DNS-focused threat model.  I think the start of that threat assessment is that “many IoT devices are automatically configured to connect to the public internet to enable automatic updates, send telemetry to the manufacturers, or enable integration with manufacturer or third-party services”.

Using the tradeoff template of the security considerations in Section 8, a privacy consideration trade-off might be that “device owners/operators want to leak as little onto the internet and to the device manufacturer while still getting the functionality of the IoT device”.

** Section 7.

  IoT devices that reach out to the manufacturer at regular intervals
  to check for firmware updates are informing passive eavesdroppers of
  the existence of a specific manufacturer's device being present at
  the origin location.

-- Is it common in an enterprise setting for IoT devices to be able to auto-updated themselves from firmware download off the internet?  In my limited enterprise experience, other end-points and network device are typically managed.  Is there some nuance that these devices can only be managed the manufacturer?

-- In an enterprise setting wouldn’t it be best practice to prevent devices from beaconing out to the internet with DNS blackholing or IP address filters?

** Section 7.
  IoT device manufacturers are encouraged to find ways to anonymize
  their update queries.  For instance, contracting out the update
  notification service to a third party that deals with a large variety
  of devices would provide a level of defense against passive
  eavesdropping.

This is good advice. 

-- Is the DNS footprint of most IoT devices predominately queries for updates?  To revisit the previous comment about the threat model, don’t some IoT devices use DNS to initiate traffic for more things than just update queries negating the benefit of a third-party update infrastructure?

-- Not knowing much about this is done in production, is this realistic guidance based on current IoT manufacturer practices?  Collecting less data from device owner/operators seems to be opposite of the trends I have seen.

[Ballot comment]
(4.1) There's an editorial error here.

"An authoritative server might be tempted to provide an IP address literal inside the protocol: there are two arguments (anti-patterns) for doing this."

I'm expecting two reasons someone might use an IP literal.

"The first is that it eliminates problems with firmware updates that might be caused by lack of DNS..."

Yep, that tracks.

"The second reason to avoid a IP address literal in the URL is when an inhouse content-distribution system is involved..."

But this is making the opposite point! It appears that this section is actually presenting ONE (not two) reason to use IP literals, and then several reasons that's a bad idea. So say that!

[Ballot discuss]
I unfortunately find this document very hard to understand. Overall, I think it would do better to split out the use cases. It seems to conflate or mix three distinct use cases: 1) A CPE with firewall+MUD-controller and an IoT MUD client, 2) A CPE with firewall with separate MUD controller and IoT MUD client, 3) An IoT device and a centralized enterprise MUD controller and centralized enterprise firewalling.
This then gets more complicated due to different assumptions of where the DNS resolver lives: On the CPE, on the LAN, in the Enterprise, on the public Internet, and what DNS protocols to use: port 53 or DoH/DoT/DoQ. After reading the document I do not find clear guidance on the MUD+DNS issue. On the contrary, I feel like this is impossible to deploy.

If the MUD controller and DNS resolver are not within the same CPE, it is unclear how communication should work to synchronize the required DNS lookups, results and firewall synchronisation between MUD controller, IoT device and firewall/router device. It seems a protocol needs to be specified but hasn't. Lots of talk about synchronizing the DNS servers to use and do independent DNS lookups seems very problematic.

I feel that MUD still needs to evolve first to be further specified as a technology, before a document about (remainig) DNS considerations can be published.

I've put my specific item feedback in the comments section below.

[Ballot comment]
In the Introduction the numbered sections are wrong (eg "second section", "third section")

An issue is raised about delays as a result of a cold cache. I'm not sure why
that matters. It is a few seconds delay that should only happen once every
couple of weeks ?

Section 3.1.1 does not take prefetching into account ?

        By doing the DNS lookups when the traffic occurs, then a passive
        attacker can see when the device is active
       
Isn't this always the case? No application splits the DNS lookup from using
the obtained IP by a large amount of time to counter traffic analyses ?
Although the app might cache the result and re-use long past the TTL time,
which is a problem if the MUD controller and firewall base any ACL addition
and removal on DNS TTLs.

      This does not require access to all on-path data, just to the
        DNS requests to the bottom level of the DNS tree.

I don't fully understand this? If query-minimalization is used, does this
still apply? I don't think so and if you care about DNS privacy, then surely
you use query-minimalization and perhaps a DoT/DoH to an external party on top?

      Aside from the list of records being incomplete, the list may
        have changed between the time that the MUD controller did the
        lookup and the time that the IoT device did the lookup

Isn't the IoT device forced to use the firewall/MUD DNS Server? If not, there
is already a DNS extraction channel and MUD has lost already.

      In order to compensate for this, the MUD controller SHOULD
        regularly perform DNS lookups in order to never have stale data.

This will cause a lot of unused lookups to be forever refreshed. This seems bad
and with ephemeral redirections (eg 32217321835.pool.hue.philips.com) seem to
use up a lot of memory on the router for DNS and firewall rules.

        it may be necessary to avoid local recursive resolvers.

Why? Shouldn't the IoT device be FORCED to use the local firewall/MUD
associated DNS server? (see earlier point)

        The MUD controller SHOULD incorporate its own recursive caching DNS server.

What if the network firewalls all DNS except the allowed one? After all,
we want to protect the network by doing DNS filtering? If you think you
need the MUD controller to limit DNS queries it sends to the DNS recursive,
then perhaps the MUD application should honour TTL and not do repeated lookups?
If they would be outside of the TTL, then you have to do a real lookup against
the real DNS server anyway? But even so, a DNS caching server should be able to
easilly serve many queries that are coming from DNS cache.


        These lookups must be rate limited to avoid excessive load on
        the DNS servers, and it may be necessary to avoid local recursive
        resolvers. The MUD controller SHOULD incorporate its own recursive
        caching DNS server.

Wouldn't the local network now have those DNS entries constantly refreshed
in both the MUD controller and the local DNS cache (because every home
router has a DNS resolver with cache). It is often not possible to bypass
the DHCP obtained DNS servers because the router will block those to be
able to do content filtering and mailware protection based on DNS.

if the IoT device does a DNS lookup, it goes via the router's advertised
DNS. If this is not relayed to the MUD controller, it will never know
and it wont work so now there is another protocol needed to relay that
DNS from router to mud controller?

        A MUD controller that is aware of which recursive DNS server
        the IoT device will use can instead query that server on a
        periodic basis.

That's a race condition waiting to happen though. It _could_ do a cache
snoop query (eg without RD=1) and it wouldn't trigger an upstream query.

        Any geographic load balancing will base the decision on the
        geolocation of the recursive DNS server, and the recursive name
        server will provide the same answer to the MUD controller as to
        the IoT device.

There is no guarantee this is true. As the document says earlier, many
services return load balanced answers or round robin answers.

        The resulting name to IP address mapping in the recursive name
        server will be cached, and will remain the same for the entire
        advertised Time-To-Live reported in the DNS query return. This
        also allows the MUD controller to avoid doing unnecessary queries.

An IoT device that does a DNS lookup and gets an answer with TTL=3600
isn't stopped from using its answer for weeks. It is not even against
any RFC if it can keep its TCP connection up for those weeks. The MUD
controller doing repeated DNS lookups isn't going to know which of
these answers is still in use or not.

Some text at the end of Section 3 finally describes two very different
use cases that the document should have started out with. The home network
and the Enterprise. It realizes these things only really work well when
inside a single CPE. But wont work for Enterprise deployments. But I find
the Enterprise case weak. Why would an Enterprise ever allow its IoT devices
to send packets to outside the Enterprise?

        The first is that the update service server must decide whether
        to provide an IPv4 or an IPv6 literal.

Why can's such a REST API not return a json struct with both?

        A third problem involves the use of HTTPS

But it was talking about downloading a signed firmware blob. You don't
need HTTPS for that. The signature can detect unauthorized modifications.
If you want privacy, you can still do HTTPS to an IP and just not validate
the X.509 certificate. With TLS ephemeral keys that gets you privacy for
passive monitors.

        A non-deterministic name or address that is returned within
        the update protocol, the MUD controller is unable to know
        what the name is. It is therefore unable to make sure that the
        communication to retrieve the new firmware is permitted by the
        MUD enforcement point.

Sure, but if the IoT device can tell the MUD controller which name it
needs for the firmware update, a compromised IoT device can tell it
the firmware is at evil.com and get to unauthorized places. The only
way to avoid this is for the IoT device to limit the domains allowed
statically from the signed mud profile, and not allow HTTP redirects or
random CDN redirects. If you allow that, you have again lost already.

Define what "geofenced names" are? Only existing locally? Within a LAN
or home or isp network?

        Use of public resolvers instead of the provided DNS resolver,
        whether Do53, DoQ, DoT or DoH is discouraged. Should the network
        provide such a resolver for use, then there is no reason not to
        use it, as the network operator has clearly thought about this.

This seems to contradict the earlier text. If the DHCP handed out 8.8.8.8,
then the IoT device and the MUD controller both using 8.8.8.8 could end up
on a different node of the ANYCAST cluster and thus get different replies
when there is round robin etc happening.

        It is recommended that use of non-local resolvers is only done
        when the locally provided resolvers provide no answers to any
        queries at all, and do so 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.

Assuming the recommendation is valid for MUD controller and IoT device,
there is again a race condition where they can end up using different
DNS servers and thus getting different answers and getting the wrong ACLs
installed. It really seems to me that more coordination is needed between
the MUD controller, the IoT device and the DNS server, and that this is
really only possible if the MUD controller is the firewall/router and
DNS server within a single CPE.

        Finally, the list of public resolvers that might be contacted
        MUST be listed in the MUD file as destinations that are to
        be permitted! This should include the port numbers (i.e., 53,
        853 for DoT, 443 for DoH) that will be used as well.

Doesn't this again open up a free channel for a compromised IoT device?
If it can reach 8.8.8.8 it can exfiltrate by sending arbitrary queries
to it. I would assume a MUD file would limit DNS queries to certain
domains but if the IoT device directly connects to 8.8.8.8 (and even worse,
over DoT or DoH), then all MUD protection has been bypassed.

        Use of Encrypted DNS connection to a local DNS recursive resolver
        is the preferred choice.

I would argue this is not always the preferred choice. Especially with
the ADD drafts allowing Delegated Credentials et all.

        IoT devices that reach out to the manufacturer at regular
        intervals to check for firmware updates are informing passive
        eavesdroppers of the existence of a specific manufacturer's
        device being present at the origin location.

While true, it is unavoidable and perhaps the responsibility of the
CPE to have a DoT/DoH upstream trusted server or to use a public
trusted one where being part of a client pool gives some limtied privacy
back. But regardless, I don't think it relates to MUD and is not a
consideration for MUD IoT.

[Ballot comment]

# Éric Vyncke, INT AD, comments for draft-ietf-opsawg-mud-iot-dns-considerations-12

Thank you for the work put into this document. It is a nice piece of work, clear and easy to read.

Please find below some non-blocking COMMENT points (but replies would be appreciated even if only for my own education).

Special thanks to Henk Birkholz for the shepherd's detailed write-up including the WG consensus and the *very light* justification of the intended status.

Please note that Dave Thaler is the IoT directorate reviewer (at my request) and you may want to consider this iot-dir review as well when it will be available (no need to wait for it though):
https://datatracker.ietf.org/doc/draft-ietf-opsawg-mud-iot-dns-considerations/reviewrequest/19052/

You may also expect an Int-dir review as:
https://datatracker.ietf.org/doc/draft-ietf-opsawg-mud-iot-dns-considerations/reviewrequest/19051/ (not yet assigned though)

I hope that this review helps to improve the document,

Regards,

-éric

# COMMENTS (non-blocking)

## Absence of mDNS

Is mDNS used in the context of MUD ? If so, then it should be mentioned here.

## Abstract

Let's be positive s/This document details concerns /This document details considerations /

## Section 1

s/Some Enterprises do this already. /Some organisations do this already. / ? (e.g., governmental agencies, ...)

Suggest to put the sentence `The first section of this document...` on its own 1-sentence paragraph.

## Section 3

Suggest to always use "DNS names" rather than plain "names". Applicable in several places in the document.

Isn't the mapping from address to DNS names usually called "reverse mapping" ? E.g., section 3.1.3 uses `reverse names`.

## Section 3.1

Suggest to add "often" in the too assertive sentence `Attempts to map IP address to names in real time fails for a number of reasons`.

## Section 3.1.2

`They could determine when a home was occupied or not`: actually when I leave home to travel (e.g., to IETF-119) most of my IoT devices are still active as I want to 'control' my home from remote.

## Section 3.1.3

`Service providers` is rather vague in this context, is it the access/internet SP or a hosted-IoT-service ?

## Section 3.2

It seems indeed to be the most obvious technique. So obvious that it should be given a hint in the introduction.

Is there a common use case where the MUD controller is changing location ? I.e., then having different forward DNS resolution answers ? I would also expect the authoritative geo-sensitve servers will use a short DNS TTL in their answers.

## Section 4

Thanks for pointing me to "antipatterns", I learned something :-) OTOH, I had to follow the link to understand the paragraph :-(

## Section 4.3

Unsure whether using a real case with Amazon is useful here...

## Section 5

Whether the MUD devices and the MUD controllers use the same recursive resolver is probably orthogonal to the use of DoT/DoH.

## Section 6

AFAIK, LLDP can also be used per RFC 8520 in addition to DHCP to retrieve the MUD string.

## Section 6.5

The section title is about `Prefer DNS servers learnt from DHCP/Route Advertisements` but the text is only about DHCP.

Btw, the exact wording is "Route*r* Advertisement" and a reference to RFC 8106 could be useful.

Which are the reasons in `There are a number of reasons to avoid this` ?

## Section 7

`The use of non-local DNS servers exposes the list of names resolved to a third party` even if the recursive resolution is done 'locally' (i.e., on a CPE) it will leak the MUD requests, we could argue that using a non-local recursive resolver will only expose the requests to this non-local server but not to the actual authoritative server.

## References

Please note that DNR & DDR are published as RFC 9462 / 9463 (dated November 2023).

[Ballot comment]
# Internet AD comments for draft-ietf-opsawg-mud-iot-dns-considerations-12
CC @ekline

* comment syntax:
  - https://github.com/mnot/ietf-comments/blob/main/format.md

* "Handling Ballot Positions":
  - https://ietf.org/about/groups/iesg/statements/handling-ballot-positions/

## Comments

### S3

* "ip6.arpa", not "ipv6.arpa"

  This is correct elsewhere in the doc, but this seems to have been missed.

### S3.2

* "recursive servers should cache data for at least..."

  ... while still respecting TTLs in the replies, yes?

### S6.4

* I suggest finding some text to point to that defines what a "geofenced"
  name is.  Right now this feels like the kind of thing that everyone
  "just knows what it means", but could use some formal description.

## Nits

### S3.1

* s/mapping/mappings/?

### S4.1

* s/inprotocol/in-protocol/

### S4.2

* "all those addresses DNS for the the name" ->
  "all those addresses in the DNS for the name"

(Via drafts-lastcall@iana.org): IESG/Authors/WG Chairs:

IANA has completed its review of draft-ietf-opsawg-mud-iot-dns-considerations-12, which is currently in Last Call, and has the following comments:

We understand that this document doesn't require any registry actions.

While it's often helpful for a document's IANA Considerations section to remain in place upon publication even if there are no actions, if the authors strongly prefer to remove it, we do not object.

If this assessment is not accurate, please respond as soon as possible.

For definitions of IANA review states, please see:

https://datatracker.ietf.org/help/state/draft/iana-review

Thank you,

David Dong
IANA Services Sr. Specialist

The following Last Call announcement was sent out (ends 2024-02-26):

From: The IESG
To: IETF-Announce
CC: draft-ietf-opsawg-mud-iot-dns-considerations@ietf.org, henk.birkholz@sit.fraunhofer.de, opsawg-chairs@ietf.org, opsawg@ietf.org, rwilton@cisco.com
Reply-To: last-call@ietf.org
Sender:
Subject: Last Call:  (Operational Considerations for use of DNS in IoT devices) to Best Current Practice


The IESG has received a request from the Operations and Management Area
Working Group WG (opsawg) to consider the following document: - 'Operational
Considerations for use of DNS in IoT devices'
  as Best Current
  Practice

The IESG plans to make a decision in the next few weeks, and solicits final
comments on this action. Please send substantive comments to the
last-call@ietf.org mailing lists by 2024-02-26. Exceptionally, comments may
be sent to iesg@ietf.org instead. In either case, please retain the beginning
of the Subject line to allow automated sorting.

Abstract


  This document details concerns about how Internet of Things devices
  use IP addresses and DNS names.  The issue becomes acute as network
  operators begin deploying RFC8520 Manufacturer Usage Description
  (MUD) definitions to control device access.

  This document makes recommendations on when and how to use DNS names
  in MUD files.




The file can be obtained via
https://datatracker.ietf.org/doc/draft-ietf-opsawg-mud-iot-dns-considerations/



No IPR declarations have been submitted directly on this I-D.


The document contains these normative downward references.
See RFC 3967 for additional information:
    rfc1794: DNS Support for Load Balancing (Informational - Internet Engineering Task Force (IETF))
    rfc9019: A Firmware Update Architecture for Internet of Things (Informational - Internet Engineering Task Force (IETF))
    rfc8094: DNS over Datagram Transport Layer Security (DTLS) (Experimental - Internet Engineering Task Force (IETF))

** Last updated: 2022-05-11 **

## Document History

1. Does the working group (WG) consensus represent the strong concurrence of a
  few individuals, with others being silent, or did it reach broad agreement?

The WG consensus represents the strong concurrence of the interested
individuals, with others being silent.

2. Was there controversy about particular points, or were there decisions where
  the consensus was particularly rough?

Directorate reviews were quickly addressed.  The most contentious discussions
were on the topics of geofencing/CDN.  Also, the strategy of coupling MUD
controller duties and name resolution duties in the context DNS caching and
lookup duties to detect record expiration underwent a somewhat rough decision
making process.  In general, using names in ACLs is a somewhat contentious topic
that exceeds the scope of MUD.
As a compromise to provide useful guidance, "failing" and "successful" strategies
(that still can fail) are illustrated in detail.  A few controversial discussions
that did not show a clear consensus during document evolution did not come up
again in the WGLC.

3. Has anyone threatened an appeal or otherwise indicated extreme discontent? If
  so, please summarize the areas of conflict in separate email messages to the
  responsible Area Director. (It should be in a separate email because this
  questionnaire is publicly available.)

No.

4. For protocol documents, are there existing implementations of the contents of
  the document? Have a significant number of potential implementers indicated
  plans to implement? Are any existing implementations reported somewhere,
  either in the document itself (as [RFC 7942][3] recommends) or elsewhere
  (where)?

While this document's intended status is BCP, it is guidance for RFC 8520,
which has several implementations and starter tools, such as
https://mudmaker.org/.

## Additional Reviews

5. Do the contents of this document closely interact with technologies in other
  IETF working groups or external organizations, and would it therefore benefit
  from their review? Have those reviews occurred? If yes, describe which
  reviews took place.

Yes, DNSOPS was involved and quite a lot of their input manifested in document changes.

6. Describe how the document meets any required formal expert review criteria,
  such as the MIB Doctor, YANG Doctor, media type, and URI type reviews.

The document does not include such content.

7. If the document contains a YANG module, has the final version of the module
  been checked with any of the [recommended validation tools][4] for syntax and
  formatting validation? If there are any resulting errors or warnings, what is
  the justification for not fixing them at this time? Does the YANG module
  comply with the Network Management Datastore Architecture (NMDA) as specified
  in [RFC 8342][5]?

The document does not include such content.

8. Describe reviews and automated checks performed to validate sections of the
  final version of the document written in a formal language, such as XML code,
  BNF rules, MIB definitions, CBOR's CDDL, etc.

The document does not include such content.

## Document Shepherd Checks

9. Based on the shepherd's review of the document, is it their opinion that this
  document is needed, clearly written, complete, correctly designed, and ready
  to be handed off to the responsible Area Director?

Yes.

10. Several IETF Areas have assembled [lists of common issues that their
    reviewers encounter][6]. For which areas have such issues been identified
    and addressed? For which does this still need to happen in subsequent
    reviews?

The assembled OPS area topics do not apply.

11. What type of RFC publication is being requested on the IETF stream ([Best
    Current Practice][12], [Proposed Standard, Internet Standard][13],
    [Informational, Experimental or Historic][14])? Why is this the proper type
    of RFC? Do all Datatracker state attributes correctly reflect this intent?

Best Current Practice, which is the right track for this document.
The DT attributes and tags seem appropriate.

12. Have reasonable efforts been made to remind all authors of the intellectual
    property rights (IPR) disclosure obligations described in [BCP 79][7]? To
    the best of your knowledge, have all required disclosures been filed? If
    not, explain why. If yes, summarize any relevant discussion, including links
    to publicly-available messages when applicable.

The two authors have stated that they are not aware of any IPR.
No IPR disclosures have been submitted directly on either the individual or the
document.

13. Has each author, editor, and contributor shown their willingness to be
    listed as such? If the total number of authors and editors on the front page
    is greater than five, please provide a justification.

The documents has two authors that have shown their willingness to be listed and
no additional contributors are listed.

14. Document any remaining I-D nits in this document. Simply running the [idnits
    tool][8] is not enough; please review the ["Content Guidelines" on
    authors.ietf.org][15]. (Also note that the current idnits tool generates
    some incorrect warnings; a rewrite is underway.)

One checklist nit refers to a non-RFC2606-compliant FQDN (which could be false
positive).  There is some lint, such as unused references, and there are
potential downrefs indicated for RFC 1794, RFC 8094, and RFC 9019 that need
investigation, see 15.  There are two outdated references that should be easy
to fix.  In total there are 4 errors, 4 warnings, and 4 comments.

15. Should any informative references be normative or vice-versa? See the [IESG
    Statement on Normative and Informative References][16].

I am rather certain that:
* [Akamai] "Akamai", , ,
* [AmazonS3] "Amazon S3", , ,
* as well as RFC 1794, RFC 8094, and RFC 9019

should not be normative references.
(Note that RFC 1794 is cited as a description of a common operational approach,
not as part of the Best Current Practice recommended by this document.)
draft-ietf-dnsop-rfc8499bis-07 probably can stay in the normative section, if
clustered; it is cited as additional information though, so can be dropped to
informative if the document gets stuck.

16. List any normative references that are not freely available to anyone. Did
    the community have sufficient access to review any such normative
    references?

The document does not include such references.

17. Are there any normative downward references (see [RFC 3967][9] and [BCP
    97][10]) that are not already listed in the [DOWNREF registry][17]? If so,
    list them.

(With the changes outlined above, no.)

18. Are there normative references to documents that are not ready to be
    submitted to the IESG for publication or are otherwise in an unclear state?
    If so, what is the plan for their completion?

Somewhat yes: dnsop-terminology-ter -> draft-ietf-dnsop-rfc8499bis-07 probably
can stay in the normative section (see above).

19. Will publication of this document change the status of any existing RFCs? If
    so, does the Datatracker metadata correctly reflect this and are those RFCs
    listed on the title page, in the abstract, and discussed in the
    introduction? If not, explain why and point to the part of the document
    where the relationship of this document to these other RFCs is discussed.

No status change is intended.

20. Describe the document shepherd's review of the IANA considerations section,
    especially with regard to its consistency with the body of the document.
    Confirm that all aspects of the document requiring IANA assignments are
    associated with the appropriate reservations in IANA registries. Confirm
    that any referenced IANA registries have been clearly identified. Confirm
    that each newly created IANA registry specifies its initial contents,
    allocations procedures, and a reasonable name (see [RFC 8126][11]).

The authors need to add an empty IANA cons section.

21. List any new IANA registries that require Designated Expert Review for
    future allocations. Are the instructions to the Designated Expert clear?
    Please include suggestions of designated experts, if appropriate.

None.

[1]: https://www.ietf.org/about/groups/iesg/
[2]: https://www.rfc-editor.org/rfc/rfc4858.html
[3]: https://www.rfc-editor.org/rfc/rfc7942.html
[4]: https://trac.ietf.org/trac/ops/wiki/yang-review-tools
[5]: https://www.rfc-editor.org/rfc/rfc8342.html
[6]: https://trac.ietf.org/trac/iesg/wiki/ExpertTopics
[7]: https://www.rfc-editor.org/info/bcp79
[8]: https://www.ietf.org/tools/idnits/
[9]: https://www.rfc-editor.org/rfc/rfc3967.html
[10]: https://www.rfc-editor.org/info/bcp97
[11]: https://www.rfc-editor.org/rfc/rfc8126.html
[12]: https://www.rfc-editor.org/rfc/rfc2026.html#section-5
[13]: https://www.rfc-editor.org/rfc/rfc2026.html#section-4.1
[14]: https://www.rfc-editor.org/rfc/rfc2026.html#section-4.2
[15]: https://authors.ietf.org/en/content-guidelines-overview
[16]: https://www.ietf.org/about/groups/iesg/statements/normative-informative-references/
[17]: https://datatracker.ietf.org/doc/downref/

** Last updated: 2022-05-11 **

## Document History

1. Does the working group (WG) consensus represent the strong concurrence of a
  few individuals, with others being silent, or did it reach broad agreement?

The WG consensus represents the strong concurrence of the interested
individuals, with others being silent.

2. Was there controversy about particular points, or were there decisions where
  the consensus was particularly rough?

Directorate reviews were quickly addressed.  The most contentious discussions
were on the topics of geofencing/CDN.  Also, the strategy of coupling MUD
controller duties and name resolution duties in the context DNS caching and
lookup duties to detect record expiration underwent a somewhat rough decision
making process.  In general, using names in ACLs is a somewhat contentious topic
that exceeds the scope of MUD.
As a compromise to provide useful guidance, "failing" and "successful" strategies
(that still can fail) are illustrated in detail.  A few controversial discussions
that did not show a clear consensus during document evolution did not come up
again in the WGLC.

3. Has anyone threatened an appeal or otherwise indicated extreme discontent? If
  so, please summarize the areas of conflict in separate email messages to the
  responsible Area Director. (It should be in a separate email because this
  questionnaire is publicly available.)

No.

4. For protocol documents, are there existing implementations of the contents of
  the document? Have a significant number of potential implementers indicated
  plans to implement? Are any existing implementations reported somewhere,
  either in the document itself (as [RFC 7942][3] recommends) or elsewhere
  (where)?

While this document's intended status is BCP, it is guidance for RFC 8520,
which has several implementations and starter tools, such as
https://mudmaker.org/.

## Additional Reviews

5. Do the contents of this document closely interact with technologies in other
  IETF working groups or external organizations, and would it therefore benefit
  from their review? Have those reviews occurred? If yes, describe which
  reviews took place.

Yes, DNSOPS was involved and quite a lot of their input manifested in document changes.

6. Describe how the document meets any required formal expert review criteria,
  such as the MIB Doctor, YANG Doctor, media type, and URI type reviews.

The document does not include such content.

7. If the document contains a YANG module, has the final version of the module
  been checked with any of the [recommended validation tools][4] for syntax and
  formatting validation? If there are any resulting errors or warnings, what is
  the justification for not fixing them at this time? Does the YANG module
  comply with the Network Management Datastore Architecture (NMDA) as specified
  in [RFC 8342][5]?

The document does not include such content.

8. Describe reviews and automated checks performed to validate sections of the
  final version of the document written in a formal language, such as XML code,
  BNF rules, MIB definitions, CBOR's CDDL, etc.

The document does not include such content.

## Document Shepherd Checks

9. Based on the shepherd's review of the document, is it their opinion that this
  document is needed, clearly written, complete, correctly designed, and ready
  to be handed off to the responsible Area Director?

Yes.

10. Several IETF Areas have assembled [lists of common issues that their
    reviewers encounter][6]. For which areas have such issues been identified
    and addressed? For which does this still need to happen in subsequent
    reviews?

The assembled OPS area topics do not apply.

11. What type of RFC publication is being requested on the IETF stream ([Best
    Current Practice][12], [Proposed Standard, Internet Standard][13],
    [Informational, Experimental or Historic][14])? Why is this the proper type
    of RFC? Do all Datatracker state attributes correctly reflect this intent?

Best Current Practice, which is the right track for this document.
The DT attributes and tags seem appropriate.

12. Have reasonable efforts been made to remind all authors of the intellectual
    property rights (IPR) disclosure obligations described in [BCP 79][7]? To
    the best of your knowledge, have all required disclosures been filed? If
    not, explain why. If yes, summarize any relevant discussion, including links
    to publicly-available messages when applicable.

The two authors have stated that they are not aware of any IPR.
No IPR disclosures have been submitted directly on either the individual or the
document.

13. Has each author, editor, and contributor shown their willingness to be
    listed as such? If the total number of authors and editors on the front page
    is greater than five, please provide a justification.

The documents has two authors that have shown their willingness to be listed and
no additional contributors are listed.

14. Document any remaining I-D nits in this document. Simply running the [idnits
    tool][8] is not enough; please review the ["Content Guidelines" on
    authors.ietf.org][15]. (Also note that the current idnits tool generates
    some incorrect warnings; a rewrite is underway.)

One checklist nit refers to a non-RFC2606-compliant FQDN (which could be false
positive).  There is some lint, such as unused references, and there are
potential downrefs indicated for RFC 1794, RFC 8094, and RFC 9019 that need
investigation, see 15.  There are two outdated references that should be easy
to fix.  In total there are 4 errors, 4 warnings, and 4 comments.

15. Should any informative references be normative or vice-versa? See the [IESG
    Statement on Normative and Informative References][16].

I am rather certain that:
* [Akamai] "Akamai", , ,
* [AmazonS3] "Amazon S3", , ,
* as well as RFC 1794, RFC 8094, and RFC 9019

should not be normative references.
(Note that RFC 1794 is cited as a description of a common operational approach,
not as part of the Best Current Practice recommended by this document.)
draft-ietf-dnsop-rfc8499bis-07 probably can stay in the normative section, if
clustered; it is cited as additional information though, so can be dropped to
informative if the document gets stuck.

16. List any normative references that are not freely available to anyone. Did
    the community have sufficient access to review any such normative
    references?

The document does not include such references.

17. Are there any normative downward references (see [RFC 3967][9] and [BCP
    97][10]) that are not already listed in the [DOWNREF registry][17]? If so,
    list them.

(With the changes outlined above, no.)

18. Are there normative references to documents that are not ready to be
    submitted to the IESG for publication or are otherwise in an unclear state?
    If so, what is the plan for their completion?

Somewhat yes: dnsop-terminology-ter -> draft-ietf-dnsop-rfc8499bis-07 probably
can stay in the normative section (see above).

19. Will publication of this document change the status of any existing RFCs? If
    so, does the Datatracker metadata correctly reflect this and are those RFCs
    listed on the title page, in the abstract, and discussed in the
    introduction? If not, explain why and point to the part of the document
    where the relationship of this document to these other RFCs is discussed.

No status change is intended.

20. Describe the document shepherd's review of the IANA considerations section,
    especially with regard to its consistency with the body of the document.
    Confirm that all aspects of the document requiring IANA assignments are
    associated with the appropriate reservations in IANA registries. Confirm
    that any referenced IANA registries have been clearly identified. Confirm
    that each newly created IANA registry specifies its initial contents,
    allocations procedures, and a reasonable name (see [RFC 8126][11]).

The authors need to add an empty IANA cons section.

21. List any new IANA registries that require Designated Expert Review for
    future allocations. Are the instructions to the Designated Expert clear?
    Please include suggestions of designated experts, if appropriate.

None.

[1]: https://www.ietf.org/about/groups/iesg/
[2]: https://www.rfc-editor.org/rfc/rfc4858.html
[3]: https://www.rfc-editor.org/rfc/rfc7942.html
[4]: https://trac.ietf.org/trac/ops/wiki/yang-review-tools
[5]: https://www.rfc-editor.org/rfc/rfc8342.html
[6]: https://trac.ietf.org/trac/iesg/wiki/ExpertTopics
[7]: https://www.rfc-editor.org/info/bcp79
[8]: https://www.ietf.org/tools/idnits/
[9]: https://www.rfc-editor.org/rfc/rfc3967.html
[10]: https://www.rfc-editor.org/info/bcp97
[11]: https://www.rfc-editor.org/rfc/rfc8126.html
[12]: https://www.rfc-editor.org/rfc/rfc2026.html#section-5
[13]: https://www.rfc-editor.org/rfc/rfc2026.html#section-4.1
[14]: https://www.rfc-editor.org/rfc/rfc2026.html#section-4.2
[15]: https://authors.ietf.org/en/content-guidelines-overview
[16]: https://www.ietf.org/about/groups/iesg/statements/normative-informative-references/
[17]: https://datatracker.ietf.org/doc/downref/

## Document History

1. Does the working group (WG) consensus represent the strong concurrence of a
  few individuals, with others being silent, or did it reach broad agreement?

The WG consensus represents the strong concurrence of the interested
individuals, with others being silent.

2. Was there controversy about particular points, or were there decisions where
  the consensus was particularly rough?

Directorate reviews were quickly addressed.  The most contentious discussions
were on the topics of geofencing/CDN.  Also, the strategy of coupling MUD
controller duties and name resolution duties in the context DNS caching and
lookup duties to detect record expiration underwent a somewhat rough decision
making process.  In general, using names in ACLs is a somewhat contentious topic
that exceeds the scope of MUD.
As a compromise to provide useful guidance, "failing" and "successful" strategies
(that still can fail) are illustrated in detail.  A few controversial discussions
that did not show a clear consensus during document evolution did not come up
again in the WGLC.

3. Has anyone threatened an appeal or otherwise indicated extreme discontent? If
  so, please summarize the areas of conflict in separate email messages to the
  responsible Area Director. (It should be in a separate email because this
  questionnaire is publicly available.)

No.

4. For protocol documents, are there existing implementations of the contents of
  the document? Have a significant number of potential implementers indicated
  plans to implement? Are any existing implementations reported somewhere,
  either in the document itself (as [RFC 7942][3] recommends) or elsewhere
  (where)?

While this document's intended status is BCP, it is guidance for RFC 8520,
which has several implementations and starter tools, such as
https://mudmaker.org/.

## Additional Reviews

5. Do the contents of this document closely interact with technologies in other
  IETF working groups or external organizations, and would it therefore benefit
  from their review? Have those reviews occurred? If yes, describe which
  reviews took place.

Yes, DNSOPS was involved and quite a lot of their input manifested in document changes.

6. Describe how the document meets any required formal expert review criteria,
  such as the MIB Doctor, YANG Doctor, media type, and URI type reviews.

The document does not include such content.

7. If the document contains a YANG module, has the final version of the module
  been checked with any of the [recommended validation tools][4] for syntax and
  formatting validation? If there are any resulting errors or warnings, what is
  the justification for not fixing them at this time? Does the YANG module
  comply with the Network Management Datastore Architecture (NMDA) as specified
  in [RFC 8342][5]?

The document does not include such content.

8. Describe reviews and automated checks performed to validate sections of the
  final version of the document written in a formal language, such as XML code,
  BNF rules, MIB definitions, CBOR's CDDL, etc.

The document does not include such content.

## Document Shepherd Checks

9. Based on the shepherd's review of the document, is it their opinion that this
  document is needed, clearly written, complete, correctly designed, and ready
  to be handed off to the responsible Area Director?

Yes.

10. Several IETF Areas have assembled [lists of common issues that their
    reviewers encounter][6]. For which areas have such issues been identified
    and addressed? For which does this still need to happen in subsequent
    reviews?

The assembled OPS area topics do not apply.

11. What type of RFC publication is being requested on the IETF stream ([Best
    Current Practice][12], [Proposed Standard, Internet Standard][13],
    [Informational, Experimental or Historic][14])? Why is this the proper type
    of RFC? Do all Datatracker state attributes correctly reflect this intent?

Best Current Practice, which is the right track for this document.
The DT attributes and tags seem appropriate.

12. Have reasonable efforts been made to remind all authors of the intellectual
    property rights (IPR) disclosure obligations described in [BCP 79][7]? To
    the best of your knowledge, have all required disclosures been filed? If
    not, explain why. If yes, summarize any relevant discussion, including links
    to publicly-available messages when applicable.

The two authors have stated that they are not aware of any IPR.
No IPR disclosures have been submitted directly on either the individual or the
document.

13. Has each author, editor, and contributor shown their willingness to be
    listed as such? If the total number of authors and editors on the front page
    is greater than five, please provide a justification.

The documents has two authors that have shown their willingness to be listed and
no additional contributors are listed.

14. Document any remaining I-D nits in this document. Simply running the [idnits
    tool][8] is not enough; please review the ["Content Guidelines" on
    authors.ietf.org][15]. (Also note that the current idnits tool generates
    some incorrect warnings; a rewrite is underway.)

One checklist nit refers to a non-RFC2606-compliant FQDN (which could be false
positive).  There is some lint, such as unused references, and there are
potential downrefs indicated for RFC 1794, RFC 8094, and RFC 9019 that need
investigation, see 15.  There are two outdated references that should be easy
to fix.  In total there are 4 errors, 4 warnings, and 4 comments.

15. Should any informative references be normative or vice-versa? See the [IESG
    Statement on Normative and Informative References][16].

I am rather certain that:
* [Akamai] "Akamai", , ,
* [AmazonS3] "Amazon S3", , ,
* as well as RFC 1794, RFC 8094, and RFC 9019

should not be normative references.
(Note that RFC 1794 is cited as a description of a common operational approach,
not as part of the Best Current Practice recommended by this document.)
draft-ietf-dnsop-rfc8499bis-07 probably can stay in the normative section, if
clustered; it is cited as additional information though, so can be dropped to
informative if the document gets stuck.

16. List any normative references that are not freely available to anyone. Did
    the community have sufficient access to review any such normative
    references?

The document does not include such references.

17. Are there any normative downward references (see [RFC 3967][9] and [BCP
    97][10]) that are not already listed in the [DOWNREF registry][17]? If so,
    list them.

(With the changes outlined above, no.)

18. Are there normative references to documents that are not ready to be
    submitted to the IESG for publication or are otherwise in an unclear state?
    If so, what is the plan for their completion?

Somewhat yes: dnsop-terminology-ter -> draft-ietf-dnsop-rfc8499bis-07 probably
can stay in the normative section (see above).

19. Will publication of this document change the status of any existing RFCs? If
    so, does the Datatracker metadata correctly reflect this and are those RFCs
    listed on the title page, in the abstract, and discussed in the
    introduction? If not, explain why and point to the part of the document
    where the relationship of this document to these other RFCs is discussed.

No status change is intended.

20. Describe the document shepherd's review of the IANA considerations section,
    especially with regard to its consistency with the body of the document.
    Confirm that all aspects of the document requiring IANA assignments are
    associated with the appropriate reservations in IANA registries. Confirm
    that any referenced IANA registries have been clearly identified. Confirm
    that each newly created IANA registry specifies its initial contents,
    allocations procedures, and a reasonable name (see [RFC 8126][11]).

The authors need to add an empty IANA cons section.

21. List any new IANA registries that require Designated Expert Review for
    future allocations. Are the instructions to the Designated Expert clear?
    Please include suggestions of designated experts, if appropriate.

None.

[1]: https://www.ietf.org/about/groups/iesg/
[2]: https://www.rfc-editor.org/rfc/rfc4858.html
[3]: https://www.rfc-editor.org/rfc/rfc7942.html
[4]: https://trac.ietf.org/trac/ops/wiki/yang-review-tools
[5]: https://www.rfc-editor.org/rfc/rfc8342.html
[6]: https://trac.ietf.org/trac/iesg/wiki/ExpertTopics
[7]: https://www.rfc-editor.org/info/bcp79
[8]: https://www.ietf.org/tools/idnits/
[9]: https://www.rfc-editor.org/rfc/rfc3967.html
[10]: https://www.rfc-editor.org/info/bcp97
[11]: https://www.rfc-editor.org/rfc/rfc8126.html
[12]: https://www.rfc-editor.org/rfc/rfc2026.html#section-5
[13]: https://www.rfc-editor.org/rfc/rfc2026.html#section-4.1
[14]: https://www.rfc-editor.org/rfc/rfc2026.html#section-4.2
[15]: https://authors.ietf.org/en/content-guidelines-overview
[16]: https://www.ietf.org/about/groups/iesg/statements/normative-informative-references/
[17]: https://datatracker.ietf.org/doc/downref/