Re: [OPSAWG] Éric Vyncke's No Objection on draft-ietf-opsawg-mud-iot-dns-considerations-12: (with COMMENT)

[Michael Richardson <[e-mail]>]

Eric, I've processed your comments first among the COMMENTS after
reorganizing the document. That re-org is in -13, and I sent a message about
that change before.  I'll post -14 once I've been through them all.

I suspect that many of your comments are repeated by other ADs, but I can't
keep track of them all at once, so I'll try to note to them if I've
dealt with their comments already with yours.

I've moved comments where I have something to day other than "okay"/done to
the beginning of this email so that you don't have to fish for them.

Your comments are collected into commit at:
https://github.com/IETF-OPSAWG-WG/draft-ietf-opsawg-mud-iot-dns-considerations/commit/d29461cc4a3d255cbdfe923d0668f50aab26b1ac

Éric Vyncke via Datatracker <[e-mail]> wrote:
    > Special thanks to Henk Birkholz for the shepherd's detailed write-up including
    > the WG consensus and the *very light* justification of the intended status.

I hope that the argument for BCP is clearer after the document
reorganization.

    > ## Section 3.1.2

    > `They could determine when a home was occupied or not`: actually when I leave
    > home to travel (e.g., to IETF-119) most of my IoT devices are still active as I
    > want to 'control' my home from remote.

Assumg a cloud-centric IoT solution. (You wouldn't buy one, and I wouldn't, but...)
if you aren't home then the motion sensor isn't busy talking to the cloud in
order to tell the lights (which also talk to the cloud) to go on.
There would probably be a noticeable change in traffic, and since reverse DNS
mappings do not last forever, an observer could notice the traffic.

    > Please note that Dave Thaler is the IoT directorate reviewer (at my request)
    > and you may want to consider this iot-dir review as well when it will
    > be

It's in my todo, and I enjoyed his review, I'm pleased he did it.

    > # COMMENTS (non-blocking)

    > ## Absence of mDNS

    > Is mDNS used in the context of MUD ? If so, then it should be mentioned here.

Collected as:
          https://github.com/IETF-OPSAWG-WG/draft-ietf-opsawg-mud-iot-dns-considerations/issues/16
and perhaps solved as:
https://github.com/IETF-OPSAWG-WG/draft-ietf-opsawg-mud-iot-dns-considerations/pull/17

    > ## Section 5

    > Whether the MUD devices and the MUD controllers use the same recursive resolver
    > is probably orthogonal to the use of DoT/DoH.

It's not due to tailored replies.
A device is more likely to use DoT or DoH, to a "public DNS server", because
they believe it's more secure than Do53 to 192.168.1.1, while the MUD
controller is likely co-located with the recursive server at 192.168.1.1

    > ## Section 6

    > AFAIK, LLDP can also be used per RFC 8520 in addition to DHCP to retrieve the
    > MUD string.

yes. That's true.
It's probably not going to ever happen in the home.
But, in the enterprise, it requires SNMP (or RESTCONF) or some other mechanism to
collect that info from the L2 switches, while DHCP requests tend to already
flow to a centralized point.
So I can add two words somewhere, but I'm not sure it helps.

    > ## Section 7

    > `The use of non-local DNS servers exposes the list of names resolved to a third
    > party` even if the recursive resolution is done 'locally' (i.e., on a CPE) it
    > will leak the MUD requests, we could argue that using a non-local recursive
    > resolver will only expose the requests to this non-local server but not to the
    > actual authoritative server.

The MUD requests could be done via oblivious HTTP.  This is not a new
problem, I think.

Do53 certainly reveals lots of passive eavesdroppers.
But, you are right, ideally, only the recursive resolver sees the list.


non-controversal edits:

    > ## Abstract

    > Let's be positive s/This document details concerns /This document details
    > considerations /

done above.

    > ## Section 1

    > s/Some Enterprises do this already. /Some organisations do this already. / ?
    > (e.g., governmental agencies, ...)

    > Suggest to put the sentence `The first section of this document...` on its own
    > 1-sentence paragraph.

okay.

    > ## Section 3

    > Suggest to always use "DNS names" rather than plain "names". Applicable in
    > several places in the document.

Searched and replaced.

    > Isn't the mapping from address to DNS names usually called "reverse mapping" ?
    > E.g., section 3.1.3 uses `reverse names`.

uhm. Sure. Does that become reverse DNS mapping, give above? I've done that
in: https://github.com/IETF-OPSAWG-WG/draft-ietf-opsawg-mud-iot-dns-considerations/commit/3529a008cc089c4ad5fb9a4641d565e8532bc1ae

    > ## Section 3.1

    > Suggest to add "often" in the too assertive sentence `Attempts to map IP
    > address to names in real time fails for a number of reasons`.

okay.

    > ## Section 3.1.3

    > `Service providers` is rather vague in this context, is it the access/internet
    > SP or a hosted-IoT-service ?

In this context, I mean CDN service, and I've clarified that.

    > ## Section 3.2

    > It seems indeed to be the most obvious technique. So obvious that it should be
    > given a hint in the introduction.

    > Is there a common use case where the MUD controller is changing location ?
    > I.e., then having different forward DNS resolution answers ? I would also
    > expect the authoritative geo-sensitve servers will use a short DNS TTL in their
    > answers.

This text has been emphasized and the other text moved to an appendix.

    > ## Section 4.3

    > Unsure whether using a real case with Amazon is useful here...

I"m open to adjustments here, but it's something they had problems with, and
addressed somewhat recently.

    > ## Section 6.5

    > The section title is about `Prefer DNS servers learnt from DHCP/Route
    > Advertisements` but the text is only about DHCP.

    > Btw, the exact wording is "Route*r* Advertisement" and a reference to RFC 8106
    > could be useful.

fixed.

    > Which are the reasons in `There are a number of reasons to avoid this`
    > ?

added text.



    > ## References

    > Please note that DNR & DDR are published as RFC 9462 / 9463 (dated November
    > 2023).

already fixed.


--
Michael Richardson <[e-mail]>, Sandelman Software Works
 -= IPv6 IoT consulting =-                      *I*LIKE*TRAINS*