Since the document has been returned to the WG by the AD, I've left the IESG out of this email.
Roman Danyliw via Datatracker <nore...@ietf.org> wrote:
} ** 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?
Yes, changed to add word "vendor"
} The current firmware model of the device is sometimes provided and then the
} vendor's authoritative server provides a determination if a new version is
} required and, if so, what version.
> ** Section 5. What is the actionable BCP or design guidance from this
section?
I have added:
} If the IoT device does not use the DNS servers provided to it via DHCP or
} Router Advertisements, then the MUD controller will need to be told which
} servers will in fact be used.
} As yet, there is no protocol to do this, but future work could provide this
} as an extension to MUD.
} Until such time as such a protocol exists, the best practice is for the IoT
} device to always use the DNS servers provided by DHCP or Router
} Advertisements.
> ** 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?
Each connection listed in the MUD file which uses a DNS name needs to be
reviewed to determine if the name is stable or not. That's the topic of the
entire document.
> ** 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”.
You seem to have reviewed a previous version, since the version posted in
April has section 8 as privacy considerations.
> 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”.
Yes. I'm not really sure what I can/should revise.
> ** 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?
Yes. And brick themselves if/when they fail.
This is now common news.
> 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?
Yes, in well managed enterprises end-points are actively managed.
We just had a discussion about firmware update systems/trackers, and *those*
systems, which are non-standard, are the ways they are managed. But, it's
highly verticalized today, with lots of vendor-lock-in, and yes, lots of
cases where only the manufacturer can manage the device.
> -- 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?
Yes, that could be done by overriding/extending the MUD file by the
enterprise operator. Many people have suggested this, but in general, it's a
value-add, and does seem to need standardization. Those filters would need
to be of the drop-without-flagging kind, because enterprises have too many
false positives already. Of course, the moment there is a device
mis-function, the manufacturer will ask if there are any extra filters, and
then the filters will get removed, and disaster restarts.
> ** 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?
1. I don't think one could characterize the DNS footprint this way.
2. Those other things might or might not be privacy violations, but the one
thing that I know all devices *ought* to be doing is updates.
> -- 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.
Yes. Lots of manufacturers suck.
My estimation is that 95% of residential IoT devices will be landfill within
a year of their release. That's really aweful. None of those manufacturers
have read this document, will ever read it, or will know what MUD is.
A major concern is false positives: devices that appear to be doing bad
things, but actually, it's just a (MUD) ruleset problem. This ties up
operator time, and I think is one reason why many are reluctant to deploy a
MUD controller: if it creates more work, nobody wants it. So getting rid of
false positives due to DNS mis-use seems like a big deal.
--
Michael Richardson <mcr+i...@sandelman.ca> . o O ( IPv6 IøT consulting )
Sandelman Software Works Inc, Ottawa and Worldwide
signature.asc
Description: PGP signature
_______________________________________________ OPSAWG mailing list -- opsawg@ietf.org To unsubscribe send an email to opsawg-le...@ietf.org
