Re: [Mud] review of mDNS vs IoT DNS

[Ted Lemon <[e-mail]>]

It's totally valid for an mDNS advertisement to contain a non-local
address. Uncommon, but valid. Which doesn't contradict your concern that
this could be used as an attack.

I think that you need to have a MUD policy for IP address separately from
the MUD policy for domain name. I noticed in a related message that you
were talking about having the MUD server be the DNS resolver for MUD
Devices, which makes sense; you can do the same thing for mDNS by having it
act as a discovery proxy. This is probably a win for MUD devices since they
can make the MUD server do the heavy lifting and don't have to implement
mDNS themselves.

So that would let you have controls on names-permitted-to-connect and
subnets-permitted-to-connect.

You could get more fancy than that, but that's how I'd implement it, all
things being equal.

On Wed, Mar 27, 2024 at 7:18 AM Michael Richardson <[e-mail]>
wrote:

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