[OPSAWG] MUD in DNSOP (fwd) Ben Schwartz: MUD in DNSOP

[Michael Richardson <[e-mail]>]

Forwarding comments.

<#secure method=pgpmime mode=sign>

--- Begin Message ---

I noticed that draft-ietf-opsawg-mud-iot-dns-considerations is on the DNSOP
agenda for this week.  It considers the problem of using MUD, which applies
IP-based filtering to locked-down IoT devices, with DNS-named servers.

Some of the recommendations are clearly correct given the limitations of
MUD, but I also have significant concerns with parts of the text.

Section 4.1 says not to use IP addresses at all.  Section 5 and Section 6.4
make recommendations about which resolvers to use for IoT generally.  I
think this is not necessary or productive.  The recommendations should be
limited to MUD-DNS devices.

The draft recommends that devices use the network-provided DNS server,
which is typically a general-purpose resolver that is capable of processing
any name.  Allowing the device to access this server defeats much of the
security benefit of MUD, because malware can communicate bidirectionally
through the DNS server, bypassing the MUD profile entirely.  It would be
more secure to disable the urn:ietf:params:mud:dns permission.

Section 6.3 says

   When aliases point to a Content-Distribution Network (CDN), prefer to
>    use stable names that point to appropriately load balanced targets.
>    CDNs that employ very low time-to-live (TTL) values for DNS make it
>    harder for the MUD controller to get the same answer as the IoT
>    Device.  A CDN that always returns the same set of A and AAAA
>    records, but permutes them to provide the best one first provides a
>    more reliable answer.


I don't think this guidance is sufficient.  MUD's DNS filters assume that
the device and gateway have the same answer in their local caches.  Even if
the device got its answer _through_ the gateway, there's no guarantee that
this is true, unless the name always resolves to the same addresses.

Even if the name resolves to the same addresses for everyone (no
geotargeting or load-balancing), any change to the zone can result in a
device-gateway mismatch during the transition, resulting in an outage while
the gateway blocks the device's network access.  This mismatch can last for
the duration of the DNS TTL.  Ironically, the guidance here to use long
TTLs could result in longer outages, plausibly hours to days.

Even if the device always delegates DNS resolution to the MUD gateway, and
the gateway attempts to provide deterministic caching (unlike a typical
resolver or forwarder), consider the case where the gateway experiences a
power glitch and resets.  Normally, with MUD, this would likely result in
an outage of less than a minute, but if the gateway re-queries the DNS name
and gets a new answer, all corresponding devices on the network will be
offline for the DNS TTL.

I want MUD-DNS to work, but I think that's going to require some deeper
changes.  The cleanest solution, in my view, would be to avoid the device
ever learning about the results of DNS resolution, by forwarding traffic to
named destinations through a SOCKS5 proxy operated by the gateway.  (SOCKS5
is trivial to implement, far simpler than DNS.)  A similar effect could be
achieved by IP encapsulation, IPv6 extension headers, and many other
mechanisms.

A hackier solution would be to add a DHCP option for the MUD gateway to
specify its associated resolver, and require devices not to implement any
DNS caching.

These approaches are compatible with disabling the urn:ietf:params:mud:dns
permission, which is typically necessary for real control over the device.

--Ben

[1]
https://www.ietf.org/archive/id/draft-ietf-opsawg-mud-iot-dns-considerations-01.txt

--- End Message ---

--
Michael Richardson <[e-mail]>   . o O ( IPv6 IøT consulting )
           Sandelman Software Works Inc, Ottawa and Worldwide