Paul Wouters has entered the following ballot position for draft-ietf-opsawg-mud-iot-dns-considerations-12: Discuss
When responding, please keep the subject line intact and reply to all email addresses included in the To and CC lines. (Feel free to cut this introductory paragraph, however.) Please refer to https://www.ietf.org/about/groups/iesg/statements/handling-ballot-positions/ for more information about how to handle DISCUSS and COMMENT positions. The document, along with other ballot positions, can be found here: https://datatracker.ietf.org/doc/draft-ietf-opsawg-mud-iot-dns-considerations/ ---------------------------------------------------------------------- DISCUSS: ---------------------------------------------------------------------- I unfortunately find this document very hard to understand. Overall, I think it would do better to split out the use cases. It seems to conflate or mix three distinct use cases: 1) A CPE with firewall+MUD-controller and an IoT MUD client, 2) A CPE with firewall with separate MUD controller and IoT MUD client, 3) An IoT device and a centralized enterprise MUD controller and centralized enterprise firewalling. This then gets more complicated due to different assumptions of where the DNS resolver lives: On the CPE, on the LAN, in the Enterprise, on the public Internet, and what DNS protocols to use: port 53 or DoH/DoT/DoQ. After reading the document I do not find clear guidance on the MUD+DNS issue. On the contrary, I feel like this is impossible to deploy. If the MUD controller and DNS resolver are not within the same CPE, it is unclear how communication should work to synchronize the required DNS lookups, results and firewall synchronisation between MUD controller, IoT device and firewall/router device. It seems a protocol needs to be specified but hasn't. Lots of talk about synchronizing the DNS servers to use and do independent DNS lookups seems very problematic. I feel that MUD still needs to evolve first to be further specified as a technology, before a document about (remainig) DNS considerations can be published. I've put my specific item feedback in the comments section below. ---------------------------------------------------------------------- COMMENT: ---------------------------------------------------------------------- In the Introduction the numbered sections are wrong (eg "second section", "third section") An issue is raised about delays as a result of a cold cache. I'm not sure why that matters. It is a few seconds delay that should only happen once every couple of weeks ? Section 3.1.1 does not take prefetching into account ? By doing the DNS lookups when the traffic occurs, then a passive attacker can see when the device is active Isn't this always the case? No application splits the DNS lookup from using the obtained IP by a large amount of time to counter traffic analyses ? Although the app might cache the result and re-use long past the TTL time, which is a problem if the MUD controller and firewall base any ACL addition and removal on DNS TTLs. This does not require access to all on-path data, just to the DNS requests to the bottom level of the DNS tree. I don't fully understand this? If query-minimalization is used, does this still apply? I don't think so and if you care about DNS privacy, then surely you use query-minimalization and perhaps a DoT/DoH to an external party on top? 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 did the lookup Isn't the IoT device forced to use the firewall/MUD DNS Server? If not, there is already a DNS extraction channel and MUD has lost already. In order to compensate for this, the MUD controller SHOULD regularly perform DNS lookups in order to never have stale data. This will cause a lot of unused lookups to be forever refreshed. This seems bad and with ephemeral redirections (eg 32217321835.pool.hue.philips.com) seem to use up a lot of memory on the router for DNS and firewall rules. it may be necessary to avoid local recursive resolvers. Why? Shouldn't the IoT device be FORCED to use the local firewall/MUD associated DNS server? (see earlier point) The MUD controller SHOULD incorporate its own recursive caching DNS server. What if the network firewalls all DNS except the allowed one? After all, we want to protect the network by doing DNS filtering? If you think you need the MUD controller to limit DNS queries it sends to the DNS recursive, then perhaps the MUD application should honour TTL and not do repeated lookups? If they would be outside of the TTL, then you have to do a real lookup against the real DNS server anyway? But even so, a DNS caching server should be able to easilly serve many queries that are coming from DNS cache. These lookups must be rate limited to avoid excessive load on the DNS servers, and it may be necessary to avoid local recursive resolvers. The MUD controller SHOULD incorporate its own recursive caching DNS server. Wouldn't the local network now have those DNS entries constantly refreshed in both the MUD controller and the local DNS cache (because every home router has a DNS resolver with cache). It is often not possible to bypass the DHCP obtained DNS servers because the router will block those to be able to do content filtering and mailware protection based on DNS. if the IoT device does a DNS lookup, it goes via the router's advertised DNS. If this is not relayed to the MUD controller, it will never know and it wont work so now there is another protocol needed to relay that DNS from router to mud controller? A MUD controller that is aware of which recursive DNS server the IoT device will use can instead query that server on a periodic basis. That's a race condition waiting to happen though. It _could_ do a cache snoop query (eg without RD=1) and it wouldn't trigger an upstream query. Any geographic load balancing will base the decision on the geolocation of the recursive DNS server, and the recursive name server will provide the same answer to the MUD controller as to the IoT device. There is no guarantee this is true. As the document says earlier, many services return load balanced answers or round robin answers. The resulting name to IP address mapping in the recursive name server will be cached, and will remain the same for the entire advertised Time-To-Live reported in the DNS query return. This also allows the MUD controller to avoid doing unnecessary queries. An IoT device that does a DNS lookup and gets an answer with TTL=3600 isn't stopped from using its answer for weeks. It is not even against any RFC if it can keep its TCP connection up for those weeks. The MUD controller doing repeated DNS lookups isn't going to know which of these answers is still in use or not. Some text at the end of Section 3 finally describes two very different use cases that the document should have started out with. The home network and the Enterprise. It realizes these things only really work well when inside a single CPE. But wont work for Enterprise deployments. But I find the Enterprise case weak. Why would an Enterprise ever allow its IoT devices to send packets to outside the Enterprise? The first is that the update service server must decide whether to provide an IPv4 or an IPv6 literal. Why can's such a REST API not return a json struct with both? A third problem involves the use of HTTPS But it was talking about downloading a signed firmware blob. You don't need HTTPS for that. The signature can detect unauthorized modifications. If you want privacy, you can still do HTTPS to an IP and just not validate the X.509 certificate. With TLS ephemeral keys that gets you privacy for passive monitors. A non-deterministic name or address that is returned within the update protocol, the MUD controller is unable to know what the name is. It is therefore unable to make sure that the communication to retrieve the new firmware is permitted by the MUD enforcement point. Sure, but if the IoT device can tell the MUD controller which name it needs for the firmware update, a compromised IoT device can tell it the firmware is at evil.com and get to unauthorized places. The only way to avoid this is for the IoT device to limit the domains allowed statically from the signed mud profile, and not allow HTTP redirects or random CDN redirects. If you allow that, you have again lost already. Define what "geofenced names" are? Only existing locally? Within a LAN or home or isp network? Use of public resolvers instead of the provided DNS resolver, whether Do53, DoQ, DoT or DoH is discouraged. Should the network provide such a resolver for use, then there is no reason not to use it, as the network operator has clearly thought about this. This seems to contradict the earlier text. If the DHCP handed out 8.8.8.8, then the IoT device and the MUD controller both using 8.8.8.8 could end up on a different node of the ANYCAST cluster and thus get different replies when there is round robin etc happening. It is recommended that use of non-local resolvers is only done when the locally provided resolvers provide no answers to any queries at all, and do so repeatedly. The use of the operator provided resolvers SHOULD be retried on a periodic basis, and once they answer, there SHOULD be no further attempts to contact public resolvers. Assuming the recommendation is valid for MUD controller and IoT device, there is again a race condition where they can end up using different DNS servers and thus getting different answers and getting the wrong ACLs installed. It really seems to me that more coordination is needed between the MUD controller, the IoT device and the DNS server, and that this is really only possible if the MUD controller is the firewall/router and DNS server within a single CPE. Finally, the list of public resolvers that might be contacted MUST be listed in the MUD file as destinations that are to be permitted! This should include the port numbers (i.e., 53, 853 for DoT, 443 for DoH) that will be used as well. Doesn't this again open up a free channel for a compromised IoT device? If it can reach 8.8.8.8 it can exfiltrate by sending arbitrary queries to it. I would assume a MUD file would limit DNS queries to certain domains but if the IoT device directly connects to 8.8.8.8 (and even worse, over DoT or DoH), then all MUD protection has been bypassed. Use of Encrypted DNS connection to a local DNS recursive resolver is the preferred choice. I would argue this is not always the preferred choice. Especially with the ADD drafts allowing Delegated Credentials et all. IoT devices that reach out to the manufacturer at regular intervals to check for firmware updates are informing passive eavesdroppers of the existence of a specific manufacturer's device being present at the origin location. While true, it is unavoidable and perhaps the responsibility of the CPE to have a DoT/DoH upstream trusted server or to use a public trusted one where being part of a client pool gives some limtied privacy back. But regardless, I don't think it relates to MUD and is not a consideration for MUD IoT. _______________________________________________ OPSAWG mailing list OPSAWG@ietf.org https://www.ietf.org/mailman/listinfo/opsawg
