Thanks Dave! On Tue, Mar 5, 2024 at 11:57 AM Dave Thaler via Datatracker <noreply@xxxxxxxx> wrote: > > 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. > > > > -- > Iot-directorate mailing list > Iot-directorate@xxxxxxxx > https://www.ietf.org/mailman/listinfo/iot-directorate -- last-call mailing list last-call@xxxxxxxx https://www.ietf.org/mailman/listinfo/last-call
