My apologies. This should have gone out under my name, not under that
of the ISE. The ISE has no interest in this.
Eliot
On 28.03.22 21:25, Independent Submissions Editor (Eliot Lear) wrote:
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
<[email protected] <mailto:mcr%[email protected]>> 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
[email protected]
https://www.ietf.org/mailman/listinfo/opsawg
_______________________________________________
OPSAWG mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/opsawg
_______________________________________________
OPSAWG mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/opsawg
