Re: [OPSAWG] AD review of draft-ietf-opsawg-mud-iot-dns-considerations-08

["Rob Wilton (rwilton)" <[e-mail]>]

Hi Michael,

The TD;LR is I think that your latest changes are good and I’ll send -12 to IETF LC.

When checking the changes, diff, 3 minor nits:

  1.  “a IP address literal in the URL” to “an IP …


  1.  I still think “inprotocol” should be something else, perhaps “within the protocol”.


  1.  The final part of the sentence, from list all of … doesn’t scan very well to me.
} In some cases, a complete set of geographically distributed servers
} is known at ahead of time, and the firmware vendor can list all of
} those addresses DNS for the the name that it lists in the MUD file.

I think that you have already addressed some comments from Mahesh, but at this stage, please treat and of Mahesh’s remaining comments as you would for any others received during IETF LC.

I’ve also put a few comments inline (but highlighted the actions above), to close out the review.


On 08/02/2024, 19:56, "Michael Richardson" <[e-mail]> wrote:

{noting that you reviewed -08, and we are up to -10 since, so some of
your comments/text are no longer applicable}

Rob Wilton (rwilton) <[e-mail]<mailto:[e-mail]>> wrote:
    > I’ve just re-reviewed -10.I still think that the English to be cleaned
    > up further.  I know that the RFC editor would likely find and fix most

okay.

    > Minor level comments:



    > (1) p 2, sec 1.  Introduction
    >    [RFC8520] provides a standardized way to describe how a specific
    >    purpose device makes use of Internet resources.  Access Control
    > Lists
    >    (ACLs) can be defined in an RFC8520 Manufacturer Usage Description
    >    (MUD) file that permit a device to access Internet resources by DNS
    >    name.

    > "specific purpose device" sounds like slight strange phrasing to me.

As previously discussed for acceptable-urls, this comes from RFC8520,
although that document does not use those exact words.  I'd sure like a
comment from Eliot about whether this is the way to explain MUD.

It is fine to leave it as is.  This isn’t a hill that I’m willing to die on ;-)

    > (2) p 2, sec 1.  Introduction
    >    Use of a DNS name rather than IP address in the ACL has many
    >    advantages: not only does the layer of indirection permit the
    > mapping
    >    of name to IP address to be changed over time, it also generalizes
    >    automatically to IPv4 and IPv6 addresses, as well as permitting
    >    loading balancing of traffic by many different common ways,
    > including
    >    multi-CDN deployments wherein load balancing can account for
    >    geography and load.


    > "many different common ways" sounds like strange phrasing to me.  How
    > can something be both different and common, which do you mean?

rewritten to:

} generalizes automatically to IPv4 and IPv6 addresses, as well as
} permitting a variety of load balancing strategies, including multi-CDN
} deployments wherein load balancing can account for geography and
} load.

Thanks.

    > (3) p 2, sec 1.  Introduction
    >    At the MUD policy enforcement point -- the firewall -- there is a
    >    problem.  The firewall has only access to the layer-3 headers of the
    >    packet.  This includes the source and destination IP address, and if
    >    not encrypted by IPsec, the destination UDP or TCP port number
    >    present in the transport header.  The DNS name is not present!

    > "önly access" -> "äccess only"

fixed.


    > (4) p 2, sec 1.  Introduction
    >    It has been suggested that one answer to this problem is to provide
    > a
    >    forced intermediate for the TLS connections.  This could in theory
    > be
    >    done for TLS 1.2 connections.  The MUD policy enforcement point
    > could
    >    observe the Server Name Identifier (SNI) [RFC6066].  Some
    > Enterprises
    >    do this already.  But, as this involves active termination of the
    > TCP
    >    connection (a forced circuit proxy) in order to see enough of the
    >    traffic, it requires significant effort.


    > "This could in theory be done" => "In theory, this could be done", or
    > "This could, in theory, be done".

fixed.


    > (5) p 3, sec 1.  Introduction
    >    The second section of this document details how common manufacturer
    >    anti-patterns get in the way of this mapping.
    >    The third section of this document details how current trends in DNS
    >    resolution such as public DNS servers, DNS over TLS (DoT), DNS over
    >    QUIC (DoQ), and DNS over HTTPS (DoH) cause problems for the
    >    strategies employed.  Poor interactions with content-distribution
    >    networks is a frequent pathology that can result.

> Do you really mean pathology here?

"the scientific study of disease" or "a disease or medical condition:"

I certainly do not mean the first, but I do mean it results in a disease.
I'm going to just remove the sentence.

Okay.

    > (6) p 3, sec 1.  Introduction
    >    The fourth section of this document makes a series of
    > recommendations
    >    ("best current practices") for manufacturers on how to use DNS and
    > IP
    >    addresses with specific purpose IoT devices.

    > Perhaps just "with MUD supporting IoT devices".  Otherwise what is the
    > difference between a general purpose IoT device and a specific purpose
    > IoT device?

okay.


    > (7) p 3, sec 3.  Strategies to map names
    >    The most naive method is to try to map IP addresses to names using
    >    the in-addr.arpa (IPv4), and ipv6.arpa (IPv6) mappings.

    > For readability, it might be helpful to indicate when this mapping
    > would occur.

...ipv6.arpa (IPv6) mappings at the time the packet is seen.

Thanks.


    > (8) p 4, sec 3.1.1.  Too slow
    >    While subsequent connections to the same site (and subsequent
    > packets
    >    in the same flow) will not be affected if the results are cached,
    > the
    >    effects will be felt.  The ACL results can be cached for a period of
    >    time given by the TTL of the DNS results, but the lookup must be
    >    performed again in a number of hours to days.


    > Please consider whether it would read better as: "but the DNS lookup
    > must be repeated, e.g., in a few hours or days, when the cached IP
    > address to name binding expires."

okay.

now:
} The ACL results can be cached for a period of time given by the TTL
} of the DNS results, but the DNS lookup must be repeated, e.g, in a few
} hours or days,when the cached IP address to name binding expires.

Okay.

    > (9) p 4, sec 3.1.2.  Reveals patterns of usage
    >    By doing the DNS lookups when the traffic occurs, then a passive
    >    attacker can see when the device is active, and may be able to
    > derive
    >    usage patterns.  They could determine when a home was occupied or
    >    not.  This does not require access to all on-path data, just to the
    >    DNS requests to the bottom level of the DNS tree.

    > Is it worth mentioning that there are now mechanisms available (like
    > DoH, or Ohttp that can be used to mitigate this)?

I'm not convinced that ohttp will be ubiquitously available enough to
be useful to *MUD controllers*.  What is the business case for running
ohttp independently of a browser, or OS vertical?

I’ve assumed that ohttp may be used to increase privacy more generally, to stop attackers from inferring what devices an individual owns based on the DNS lookups that are being made.

Anyway, this section is about things that don't work.
Making them work slightly less bad seems not worth explaining.

Sure.



    > (10) p 6, sec 3.2.  A successful strategy
    >    In order to compensate for this, the MUD controller SHOULD regularly
    >    perform DNS lookups in order to never have stale data.  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.
    >    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!
    > I suggest changing "for many minutes to days" to "for at least some
    > number of minutes, up to some number of days".


okay.


    > (11) p 8, sec 4.1.  Use of IP address literals in-protocol
    >    The second reason to avoid a DNS in the URL is when an inhouse
    >    content-distribution system is involved that involves on-demand
    >    instances being added (or removed) from a cloud computing
    >    architecture.

    > Should it be "avoid in IP address literal in the URL"?  Also, inhouse
    > => in-house.

Hmm.  I guess so.
The point is that when instances/come go really fast, it can seem to be hard
to refer to them quickly using names rather than IP addresses.
Maybe this can be more clearly explained by a CDN person.

Okay.

    > (12) p 9, sec 4.1.  Use of IP address literals in-protocol
    >    Finally, third-party content-distribution networks (CDN) tend to use
    >    DNS names in order to isolate the content-owner from changes to the
    >    distribution network.
    >    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 first sentence above doesn't make sense to me, please can it be
    > rephrased.

I have rewritten this to:
} Finally, it is common in some content-distribution networks (CDN) to
} use multiple layers of DNS CNAMEs in order to isolate the
} content-owner's naming system from changes in how the distribution
} network is organized.

Okay.

As an example of what I'm talking about, I recently came across:

dyas-[~](2.6.6) mcr 10001 %host login.my.gov.nl.ca
login.my.gov.nl.ca is an alias for gnlprod.azurefd.net.
gnlprod.azurefd.net is an alias for azurefd-t-prod.trafficmanager.net.
azurefd-t-prod.trafficmanager.net is an alias for shed.dual-low.part-0008.t-0009.t-msedge.net.
shed.dual-low.part-0008.t-0009.t-msedge.net is an alias for part-0008.t-0009.t-msedge.net.

and you just can't do this kind of thing with an IP address :-)

That is probably a good thing, but there is always SRv6 ;-)



    > (13) p 10, sec 4.2.  Use of non-deterministic DNS names in-protocol
    >    The firmware vendor is therefore likely to be asked to point a CNAME
    >    to the CDN network, to a name that might look like "g7.a.example",
    >    with the expectation that the CDN vendors DNS will do all the
    >    appropriate work to geolocate the transfer.  This can be fine for a
    >    MUD file, as the MUD controller, if located in the same geography as
    >    the IoT device, can follow the CNAME, and can collect the set of
    >    resulting IP addresses, along with the TTL for each.  The MUD
    >    controller can then take charge of refreshing that mapping at
    >    intervals driven by the TTL.

    >    In some cases, a complete set of geographically distributed servers
    >    is known at ahead of time, and the firmware vendor can list all of
    >    those addresses in the name that it lists in the MUD file.  As long
    >    as the active set of addresses used by the CDN is a strict subset of
    >    that list, then the geolocated name can be used for the firmware
    >    download itself.  This use of two addresses is ripe for confusion
    >    however.


    > Where are the addresses being listed?  In the DNS or with the CDN?

the addresses are listed in the DNS reply.

While strongly geofenced zones will return a single reply:
  dyas-[lwork/opsawg/iot-mud-dns-considerations](2.6.6) mcr 10032 %host google.com
  google.com has address 172.217.13.110
  google.com has IPv6 address 2607:f8b0:4020:804::200e

others will return a long list of all possible addresses, and often
the order will be rotated in the hope the client will use the first
one, creating some amount of round-robin load balancing.
dyas-[lwork/opsawg/iot-mud-dns-considerations](2.6.6) mcr 10036 %host microsoft.com
microsoft.com has address 20.112.250.133
microsoft.com has address 20.231.239.246
microsoft.com has address 20.76.201.171
microsoft.com has address 20.70.246.20
microsoft.com has address 20.236.44.162
microsoft.com has IPv6 address 2603:1030:b:3::152
microsoft.com has IPv6 address 2603:1030:20e:3::23c
microsoft.com has IPv6 address 2603:1030:c02:8::14
microsoft.com has IPv6 address 2603:1020:201:10::10f
microsoft.com has IPv6 address 2603:1010:3:3::5b
microsoft.com mail is handled by 10 microsoft-com.mail.protection.outlook.com.

(there are longer answers I've seen which even push the answer to TCP,
but I suspect that this results in poorer results and operators back
off from that)

I've rewritten:

} In some cases, a complete set of geographically distributed servers
} is known at ahead of time, and the firmware vendor can list all of
} those addresses DNS for the the name that it lists in the MUD file.

The end of your sentence still looks a bit mangled to me.

    > (14) p 10, sec 4.3.  Use of a too generic DNS name
    >    Some CDNs make all customer content at a single URL (such as
    >    s3.amazonaws.com).  This seems to be ideal from a MUD point of view:
    >    a completely predictable URL.

    > "Make all customer content at" => "Make all customer content available
    > at"

fixed.

    > (15) p 11, sec 6.  Recommendations to IoT device manufacturer on MUD
    > and DNS usage

    >    The difficult part is determining what to put into the MUD file
    >    itself.  There are currently tools that help with the definition and
    >    analysis of MUD files, see [mudmaker].  The remaining difficulty is
    >    now the semantic contents of what is in the MUD file.  An IoT
    >    manufacturer must now spend some time reviewing the network
    >    communications by their device.

    > Could "The remaining difficulty is now the semantic contents of what is
    > in the MUD file." is a bit vague, could it be more precisely explained
    > please?


now:
} The remaining difficulty is now the actual list of expected connections to put in the MUD file.

Thanks.


    > (16) p 12, sec 6.5.  Prefer DNS servers learnt from DHCP/Route
    > Advertisements
    >    The ADD WG has written [I-D.ietf-add-dnr] and [I-D.ietf-add-ddr] to
    >    provided.

    > This sentence doesn't scan.

} The ADD WG has written {{?I-D.ietf-add-dnr}} and
} {{?I-D.ietf-add-ddr}} to provide information to end devices on how to
} find locally provisioned secure/private DNS servers.

Thanks.

    > (17) p 12, sec 7.  Privacy Considerations
    >    The use of DoT and DoH eliminates the threat from passive
    >    eavesdropping, but still exposes the list to the operator of the DoT
    >    or DoH server.  There are additional methods, such as described by
    >    [RFC9230].

    > Perhaps "There are additional methods to help preserve privacy, such as
    > ..."

fixed.



    > (18) p 13, sec 7.  Privacy Considerations
    >    The use of DoT and DoH eliminates the threat from passive
    >    eavesdropping, but still exposes the list to the operator of the DoT
    >    or DoH server.  There are additional methods, such as described by
    >    [RFC9230].
    >    The use of unencrypted (Do53) requests to a local DNS server exposes
    >    the list to any internal passive eavesdroppers, and for some
    >    situations that may be significant, particularly if unencrypted WiFi
    >    is used.  Use of Encrypted DNS connection to a local DNS recursive
    >    resolver is a preferred choice.

    > Use of an Encrypted ...  is the preferred choice.

fixed.


    > Nit level comments:


    > (19) p 4, sec 3.1.3.  Mappings are often incomplete
    >    In some cases there are multiple layers of CNAME between the
    > original
    >    name and the target service name.  This is often due to a layer of
    >    load balancing in DNS, followed by a layer of load balancer at the
    >    HTTP level.

    > "Load balancing layer in the DNS" and "Load balancing layer at the HTTP
    > level" would probably read better.

fixed.


    > (20) p 7, sec 3.2.  A successful strategy
    >    3.  if any addresses have been omitted in a round-robin DNS process,
    >        the cache will have the set of addresses that were returned.

    > Possibly, "the same set of addresses"?


fixed.


    > (21) p 10, sec 4.2.  Use of non-deterministic DNS names in-protocol
    >    The firmware vendor is therefore likely to be asked to point a CNAME
    >    to the CDN network, to a name that might look like "g7.a.example",
    >    with the expectation that the CDN vendors DNS will do all the
    >    appropriate work to geolocate the transfer.  This can be fine for a
    >    MUD file, as the MUD controller, if located in the same geography as
    >    the IoT device, can follow the CNAME, and can collect the set of
    >    resulting IP addresses, along with the TTL for each.  The MUD
    >    controller can then take charge of refreshing that mapping at
    >    intervals driven by the TTL.
    >    In some cases, a complete set of geographically distributed servers
    >    is known at ahead of time, and the firmware vendor can list all of
    >    those addresses in the name that it lists in the MUD file.  As long
    >    as the active set of addresses used by the CDN is a strict subset of
    >    that list, then the geolocated name can be used for the firmware
    >    download itself.  This use of two addresses is ripe for confusion
    >    however.

    > at ahead of time => ahead of time.  all of those => all those

fixed.


    > (22) p 13, sec 7.  Privacy Considerations
    >    The use of a publically specified firmware update protocol would
    > also
    >    enhance privacy of IoT devices.  In such a system the IoT device
    >    would never contact the manufacturer for version information or for
    >    firmware itself.  Instead, details of how to query and where to get
    >    the firmware would be provided as a MUD extension, and an
    > Enterprise-
    >    wide mechanism would retrieve firmware, and then distribute it
    >    internally.  Aside from the bandwidth savings of downloading the
    >    firmware only once, this also makes the number of devices active
    >    confidential, and provides some evidence about which devices have
    >    been upgraded and which ones might still be vulnerable.  (The
    >    unpatched devices might be lurking, powered off, lost in a closet)

    > publically => publicly

fixed.
(Is that a US/English thing?  Or just me being educated to spell in
french first)

No idea, but the Mac OS dictionary states: “Note that the spelling is publicly, not -ally”

    > (23) p 13, sec 7.  Privacy Considerations
    >    The use of a publically specified firmware update protocol would
    > also
    >    enhance privacy of IoT devices.  In such a system the IoT device
    >    would never contact the manufacturer for version information or for
    >    firmware itself.  Instead, details of how to query and where to get
    >    the firmware would be provided as a MUD extension, and an
    > Enterprise-
    >    wide mechanism would retrieve firmware, and then distribute it
    >    internally.  Aside from the bandwidth savings of downloading the
    >    firmware only once, this also makes the number of devices active
    >    confidential, and provides some evidence about which devices have
    >    been upgraded and which ones might still be vulnerable.  (The
    >    unpatched devices might be lurking, powered off, lost in a closet)

    > In such a system the => In such a system, the

fixed.

    > Spellings: inhouse, inprotocol, middleboxes

is "in-protocol" wrong?

I’m pretty sure that “inprotocol” is wrong, but I’m not sure that “in-protocol” is right either.  Maybe “… within the protocol”

Thanks,
Rob


    > Grammar Warnings:

    > Section: 3.1.3, draft text: To limit churn of DNS PTR records, and
    > reduce failures of the MUD ACLs, operators would want to add all
    > possible names for each reverse name, whether or not the DNS load
    > balancing in the forward DNS space lists that end-point at that moment.
    > Warning: Consider shortening this phrase to just 'whether', unless you
    > mean 'regardless of whether'.  Suggested change: "whether"

I think I stick with what I have.

    > Section: 3.1.4, draft text: For instance, github.io, which is used for
    > hosted content, including the Editors' copy of internet drafts stored
    > on github, does not actually publish any names.  Warning: The official
    > name of this software platform is spelled with a capital "H".
    > Suggested change: "GitHub"

DNS name.

    > Section: 3.1.4, draft text: Instead a wildcard exists to answer all
    > potential names: requests are routed appropriate once they are
    > received.  Warning: A comma may be missing after the
    > conjunctive/linking adverb 'Instead'.  Suggested change: "Instead,"

okay.

    > Section: 3.2, draft text: The MUD controller and the device get a
    > matching set, and the ACLs that are setup cover all possibilities.
    > Warning: The verb 'set up' is spelled as two words. The noun 'setup' is
    > spelled as one.  Suggested change: "set up"

okay.

    > Section: 3.2, draft text: The simplest is when the round robin does not
    > return all addresses.  Warning: This word is normally spelled with a
    > hyphen.  Suggested change: "round-robin"

okay.

    > Section: 4.1, draft text: A common pattern for a number of devices is
    > to look for firmware updates in a two step process.  Warning: This word
    > is normally spelled with a hyphen.  Suggested change: "two-step"

okay.

    > Section: 4.1, draft text: An initial query is made (often over HTTPS,
    > sometimes with a POST, but the method is immaterial) to a vendor system
    > that knows whether or not an update is required.  Warning: Consider
    > shortening this phrase to just 'whether', unless you mean 'regardless
    > of whether'.  Suggested change: "whether"

okay.

    > Section: 4.1, draft text: The current firmware model of the device is
    > sometimes provided and then the authoritative server provides a
    > determination if a new version is required, and if so, what version.
    > Warning: Use a comma before "and" if it connects two independent
    > clauses (unless they are closely connected and short).  Suggested
    > change: ", and"

okay.

    > Section: 4.2, draft text: Even if the content provider chosen names are
    > deterministic they may change at a rate much faster then MUD files can
    > be updated.  Warning: Did you mean faster than?  Suggested change:
    > "faster than"

fixed.

    > Section: 4.2, draft text: This use of two addresses is ripe for
    > confusion however.  Warning: Consider inserting a comma before
    > 'however'.  Suggested change: ", however"

fixed.

    > Section: 4.3, draft text: Exactly what the risk is depends upon what
    > the other customers are doing: it could be limited to simply causing a
    > distributed denial of service attack resulting in high costs to those
    > customers, or such an attack could potentially include writing content.
    > Warning: It appears that hyphens are missing.  Suggested change:
    > "denial-of-service"

okay.

    > Section: 6, draft text: It can even be done without code changes via
    > the use of a QR code affixed to the packaging (see [RFC9238].  Warning:
    > Unpaired symbol: ')' seems to be missing

closing added...

    > Section: 6.2, draft text: While it used to be costly to have a large
    > number of aliases in a web server certificate, this is no longer the
    > case.  Warning: Specify a number, remove phrase, or simply use many or
    > numerous Suggested change: "many"

I think i'm fine.


    > Section: 6.5, draft text: The ADD WG has written [I-D.ietf-add-dnr] and
    > [I-D.ietf-add-ddr] to provided.  Warning: The verb after "to" should be
    > in the base form.  Suggested change: "provide"

fixed.

    > Section: 7, draft text: The use of unencrypted (Do53) requests to a
    > local DNS server exposes the list to any internal passive
    > eavesdroppers, and for some situations that may be significant,
    > particularly if unencrypted WiFi is used.  Warning: Did you mean Wi-Fi?
    > (This is the officially approved term by the Wi-Fi Alliance.)
    > Suggested change: "Wi-Fi"

okay.

Posting new version in two minutes.


--
Michael Richardson <[e-mail]<mailto:[e-mail]>>   . o O ( IPv6 IøT consulting )
           Sandelman Software Works Inc, Ottawa and Worldwide