I think there are two things going on here.
First, there is a need for the controller to be tightly bound with the
resolver. Thus it is aware of what is returned to the device. How long
the device uses that information should be governed by the upper bound
of DNS caching semantics and stateful access mechanisms.
The second thing going on here is that the device needs to do a new
lookup if the TTL on a record has expired, and it has unexpectedly lost
connectivity, something that can happen on the Internet with or without
MUD. In fact, MUD is hardly the issue here. The issue is whether you
can have DNS-based ACLs that can function. Here the enforcement point
has something to say to make that happen, because resilience
requirements on the client will dictate it happening.
Eliot
On 28.03.22 21:00, Ben Schwartz wrote:
On Sat, Mar 26, 2022 at 8:32 PM Michael Richardson
<mcr+i...@sandelman.ca <mailto:mcr%2bi...@sandelman.ca>> wrote:
On 2022-03-07 11:47, Ben Schwartz wrote:
> I reviewed [1] this draft at version 01, but my concerns largely
stand with
> the current version.
>
> The fundamental issue here, in my view, is that the
urn:ietf:params:mud:dns
> permission is not compatible with the desired threat model. A
correct
> solution would be to recommend against this permission, and
introduce a new
> one that provides explicit coupling between DNS resolution,
transport
> setup, and the MUD gateway (e.g. using a SOCKS5 proxy).
I have been struggling to find a way to deal with your comments.
https://github.com/mcr/iot-mud-dns-considerations/pull/2 is the
beginnings of a recommendation to use SOCKS5 if it is present on
networks. I don't think that we have a way to do that.
Perhaps there is some discovery of SOCKS5 in some vendor DHCP option,
but I haven't found that yet.
Local SOCKS5 proxies are conventionally discovered via WPAD [1], which
returns a PAC file [2]. I'm no great fan of WPAD, but it is widely
implemented in browsers and OSes.
I don't mean to claim that SOCKS5 specifically, or domain-oriented
transport proxies generally, are the right solution here. My point is
that the MUD gateway architecture described here is fatally flawed.
Specifically, I'm focused on this text:
Aside from the list of records being incomplete, the list may have
changed between the time that the MUD controller did the lookup and
the time that the IoT device does the lookup, and this change can
result in a failure for the ACL to match.
In order to compensate for this, the MUD controller SHOULD regularly
do DNS lookups in order to get never have stale data. These lookups
need to be rate limited in order to avoid load. It may be necessary
to avoid local recursive DNS servers. The MUD controller SHOULD
incorporate its own recursive caching DNS server. Properly designed
recursive servers should cache data for many minutes to days, while
the underlying DNS data can change at a higher frequency, providing
different answers to different queries!
A MUD controller that is aware of which recursive DNS server that the
IoT device will use can instead query that server on a periodic
basis.
The problem description here is accurate, but the proposed MUD
controller behaviors are not reliably compatible with RFC
8520-compliant devices, so they cannot safely be deployed. The only
reliable solution is to update the allowed IPs based on the specific
DNS responses that are being used by the device's connections. This
could either be done implicitly (via a transport proxy) or explicitly
(by ensuring the MUD controller _is_ the client's DNS resolver, and
adding IP ACLs before returning any DNS response containing IP addresses).
This also touches on another issue with MUD DNS support: RFC 8520 does
not clearly define any rule regarding the allowed DNS QNAMEs. This
enables arbitrary data flows to be tunneled through the DNS to
arbitrary destinations. In my view, this is a very large hole in the
MUD protections. A transport proxy or tighter DNS binding would also
help to close this loophole.
[1] https://datatracker.ietf.org/doc/html/draft-ietf-wrec-wpad-01
[2]
https://developer.mozilla.org/en-US/docs/Web/HTTP/Proxy_servers_and_tunneling/Proxy_Auto-Configuration_PAC_file
_______________________________________________
OPSAWG mailing list
OPSAWG@ietf.org
https://www.ietf.org/mailman/listinfo/opsawg
_______________________________________________
OPSAWG mailing list
OPSAWG@ietf.org
https://www.ietf.org/mailman/listinfo/opsawg
