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

[Michael Richardson <[e-mail]>]

{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]> 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.


    > (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.

    > (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.

    > (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.

    > (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.


    > (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?

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


    > (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.

    > (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.

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 :-)


    > (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.


    > (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.


    > (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.


    > (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)

    > (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?

    > 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]>   . o O ( IPv6 IøT consulting )
           Sandelman Software Works Inc, Ottawa and Worldwide