[Mud] review of mDNS vs IoT DNS

[Michael Richardson <[e-mail]>]

Éric Vyncke asked in his COMMENTS:

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

I've tried to answer this as:
https://github.com/IETF-OPSAWG-WG/draft-ietf-opsawg-mud-iot-dns-considerations/pull/17

which I paste below, but if you have edits, do a github suggestion please.

Ted: I'd particularly like your opinion here.
I think that I a device could ask for printer.local and then receive some
internet address as an AAAA record, 2001:db8::1234, which would send the
device out there.  I think that would only be the result of malware.
But... DNS-SD could well answer some
not-local-to-this-subnet-but-still-internal answer right?
Which might well pass through the MUD policy enforcement point ("firewall").
I think... tough... internal addresses need to be acceptlisted.

# Interactions with mDNS and DNSSD

Unicast DNS requests are not the only way to map names to IP addresses.
IoT devices might also use mDNS {{?RFC6762}}, both to be discovered by other
devices, and also to discover other devices.

mDNS replies include A and AAAA records, and it is conceivable that these
replies contain addresses which are not local to the link on which they are
made.
This could be the result of another device which contains malware.
An unsuspecting IoT device could be led to contact some external host as a result.
Protecting against such things is one of the benefits of MUD.

In the unlikely case that the external host has been listed as a legitimate
destination in a MUD file, then communication will continue as expected.
As an example of this, an IoT device might look for a name like
"update.local" in order to find a source of firmware updates.
It could be led to connect to some external host that was listed as
"update.example" in the MUD file.
This should work fine if the name "update.example" does not require any kind
of tailored reply.

In residential networks there has typically not been more than one network
(although this is changing through work like {{?I-D.ietf-snac-simple}}), but
on campus or enterprise networks, having more than one network is not
unusual.
In such networks, mDNS is being replaced with DNS-SD {{?RFC8882}}, and in
such a situation, connections could be initiated to other parts of the
network.
Such connections might traverse the MUD policy enforcement point (an
intra-department firewall), and could very well be rejected because the MUD
controller did not know about that interaction.

{{RFC8250}} includes a number of provisions for controlling internal
communications, including complex communications like same manufacturer ACLs.
To date, this aspect of MUD has been difficult to describe.
This document does not consider internal communications to be in scope.

--
Michael Richardson <[e-mail]>, Sandelman Software Works
 -= IPv6 IoT consulting =-                      *I*LIKE*TRAINS*