Reviewer: Dave Thaler Review result: On the Right Track Section 3.2 (A successful strategy): > This situation does not result in failures as long as all possible A/ > AAAA records are returned. The MUD controller and the device get a > matching set, and the ACLs that are set up cover all possibilities. This paragraph, and various others in the draft, make a potentially false assumption that the IoT device does a DNS query. RFC 8520 section 8.1 states: > 8.1 src-dnsname The argument corresponds to a domain name of a source as specified by inet:host. > A number of means may be used to resolve hosts. What is important is that such resolutions be consistent > with ACLs that are required by Things to properly operate.“ As far as I can tell, MUD has no such requirement that the device use DNS to resolve domain names. Specifically, above says "A number of means may be used to resolve hosts." DNS is only one such means. Later in section 3.2... > 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. This is not as good as the MUD controller _being_ the recursive DNS server the IoT device uses, where the ACL in the enforcement point can be updated at the same time as the DNS cache is updated, when the IoT device does a DNS query. If there is a time delay between the DNS cache being updated and the ACL being updated, one can get lack of connectivity since the DNS cache can contain a new IP address that the enforcement point won't learn about until the next time it gets around to querying DNS. I would expect that connectivity failures would be NOT RECOMMENDED. Section 3.2 alludes to this issue when it says: > Where the solution is more complex is when the MUD controller is > located elsewhere in an Enterprise, or remotely in a cloud such as > when a Software Defined Network (SDN) is used to manage the ACLs. > The DNS servers for a particular device may not be known to the MUD > controller, nor the MUD controller be even permitted to make > recursive queries to that server if it is known. In this case, > additional installation specific mechanisms are probably needed to > get the right view of the DNS. Given the resulting connecting failures I point out, it would probably be good to say such use is NOT RECOMMENDED. But right now I think the draft is remiss in not evening point out that connectivity failures can easily result. Section 4.1 (Use of IP address literals inprotocol) This is the section I had the most problems with. It purports to give reasons _not_ to do this, and which is then used to justify a recommendation against it in section 6.1. Let's walk through them... It starts with "there are two arguments (anti-patterns) _for_ doing this." Great. The first reason _for_ doing it is given, which makes a lot of sense to me. It then goes on to say: > The second reason to avoid an IP address literal in the URL is when an > in-house content-distribution system is involved that involves on- > demand instances being added (or removed) from a cloud computing > architecture. First, it's listed as a reason "to avoid" in the list of arguments "for" doing this, which doesn't make sense. Second, I don't buy this as a reason to avoid literals. If the update server provides URLs on demand, the server can ensure provide the latest URLs when needed. If the address is removed right after being returned, without any transition time, then I’d argue that something else is operationally problematic in that network. But even then, if it doesn’t work, the device can just re-query the update server for a new URL. So I think this paragraph is a red herring, at least as currently phrased. The draft then gives a list of "more problems"... > The first is that the update service server must decide whether to > provide an IPv4 or an IPv6 literal. A DNS name can contain both > kinds of addresses, and can also contain many different IP addresses > of each kind. I don’t buy the claim that it "must" decide whether to provide IPv4 or IPv6. The update server can provide a list of addresses (or a list of URLs). The draft hasn’t mentioned any reason that it "must" pick only one. I might buy that an anti-pattern is that some implementations DO only provide one, and then the recommendation should be to fix the “only one” design. Bottom line: it’s not the use of literals that are the problem. > The second problem is that it forces the MUD file definition to > contain the exact same IP address literals. It must also contain an > ACL for each address literal. DNS provides a useful indirection > method that naturally aggregates the addresses. I don't agree that it "forces” it per se, although I do agree that’s the _best_ way to ensure that it matches. A minor rewording would suffice for this paragraph. > A third problem involves the use of HTTPS. IP address literals do > not provide enough context for TLS ServerNameIndicator to be useful > [RFC6066]. This limits the firmware repository to be a single tenant > on that IP address, and for IPv4 (at least), this is no longer a > sustainable use of IP addresses. So... make the use of *IPv4* literals be NOT RECOMMENDED then. (Even then, if the firmware image is signed and non-secret, then TLS is of course good but not strictly required for many classes of attack.) I don't believe this section has presented sufficient motivation to make IPv6 literals be NOT RECOMMENDED (as 6.1 tries to do), especially given the valid reasons _for_ doing it that are pointed out in the draft. Finally the section concludes: > 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. The above paragraph is really hard to follow. What is meant by “non-deterministic name or address”? And what does “unable to make sure” mean in practice? Section 4.2 (Use of non-deterministic DNS names in-protocol): This section seems to confuse various roles (or at least terminology). The first two paragraphs introduce the issue (correctly, I think) as not being specific to firmware updates, but really about any type of content the device might access. But then things get confusing... > Such names may be unpredictably chosen by the content provider, and > not the content owner, and so impossible to insert into a MUD file. Who is the "content owner"? Firmware image owner? Device manufacturer? If you have a device that (say) accesses weather information at a third-party site, then the MUD file is still provided by the device manufacturer NOT the “content owner” if the “content” is the weather data. Another paragraph says: > A solution is to use a deterministic DNS name, within the control of > the firmware vendor. Firmware updates are not the only type of content the device may access that section 4.2 applies to. If this paragraph is not specific to firmware updates, then is “firmware vendor” still the right term? Or should it be “device manufacturer”? (since a MUD file is a *M*anufacturer usage description, not a *F*irmware usage description (FUD)) Section 6.5 (Prefer DNS servers learnt from DHCP/Route Advertisements): > IoT Devices SHOULD prefer doing DNS with the DHCP provided DNS servers. Why are DHCP-provided DNS servers preferred over RA-provided DNS servers? Elaborate. > 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, See comment below about this "there is no reason" statement… > as the network operator has clearly thought about this. > > Some manufacturers would like to have a fallback to using a public > resolver to mitigate against local misconfiguration. Claiming “there is no reason” assumes omniscience, that no device manufacturer has come with any reason. Maybe some device manufacturer doesn’t trust local network operators and wants to hide DNS query details from such observers. Even the next paragraph (the last sentence quoted above) seems to contradict this statement by providing a potential reason (“to mitigate against local misconfiguration”). Section 7 (Privacy Considerations): > The use of non-local DNS servers exposes the list of names resolved > to a third party, including passive eavesdroppers. Not necessarily. If the non-local DNS server is provided by the device manufacturer, it’s not a third party. > Use of Encrypted DNS connection to a local DNS recursive > resolver is the preferred choice. This still exposes DNS names to the local network. Communication inherently exposes destination IP addresses (in the IP header) to the local network operator, but not DNS names. There’s a significant disclosure difference when you have many names hosted at the same IP. Hence this should be called out as a privacy issue that some device manufacturers might be concerned about. -- last-call mailing list last-call@xxxxxxxx https://www.ietf.org/mailman/listinfo/last-call
