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

# 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"

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.

Thanks for the update/rewrite of the document. It reads much better now. I've updated my ballot to No Objection.

Thank you to Chris Wood for the SECDIR review.

Thank you for addressing my DISCUSS feedback and select COMMENT.

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

# É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).

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.

(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!

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

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?