Re: [OPSAWG] Éric Vyncke's No Objection on draft-ietf-opsawg-mud-iot-dns-considerations-12: (with COMMENT)
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 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
Re: [OPSAWG] Éric Vyncke's No Objection on draft-ietf-opsawg-mud-iot-dns-considerations-12: (with COMMENT)
Dear IESG and MUD Enthusiasts, I'm working through your comments, turning them all into issues, but I want to alert you that the -12/-13 diff includes a significant restructuring of the document in order to bring the *BCP* nature of the document more clearly to the front. I've tried to socialize this change via hallway conversations. This also means that some of your detailed comments have completely missed the mark, and I won't be turning those into issues as I go through them. There is no attempt in this document to standardize any *MUD controller* aspects or protocols, but IoT vendors need a model against which to determine what kind of DNS behaviour will work, and what will not. That was stated in the abstract: This document details concerns about how Internet of Things (IoT) devices use IP addresses and DNS names. These concerns become acute as network operators begin deploying RFC 8520 Manufacturer Usage Description (MUD) definitions to control device access. Also, this document makes recommendations on when and how to use DNS names in MUD files. I won't repeat this in each of the comments that I got, assuming everyone might read this once. https://author-tools.ietf.org/iddiff?url1=draft-ietf-opsawg-mud-iot-dns-considerations-12=draft-ietf-opsawg-mud-iot-dns-considerations-13=--html Looks like this might also contain some xml2rfc version based changes, e.g.: as s3.amazonaws.com). vs as "s3.example.com" -- Michael Richardson , Sandelman Software Works -= IPv6 IoT consulting =- *I*LIKE*TRAINS* signature.asc Description: PGP signature ___ OPSAWG mailing list OPSAWG@ietf.org https://www.ietf.org/mailman/listinfo/opsawg
[OPSAWG] Éric Vyncke's No Objection on draft-ietf-opsawg-mud-iot-dns-considerations-12: (with COMMENT)
Éric Vyncke has entered the following ballot position for draft-ietf-opsawg-mud-iot-dns-considerations-12: No Objection When responding, please keep the subject line intact and reply to all email addresses included in the To and CC lines. (Feel free to cut this introductory paragraph, however.) Please refer to https://www.ietf.org/about/groups/iesg/statements/handling-ballot-positions/ for more information about how to handle DISCUSS and COMMENT positions. The document, along with other ballot positions, can be found here: https://datatracker.ietf.org/doc/draft-ietf-opsawg-mud-iot-dns-considerations/ -- COMMENT: -- # Éric Vyncke, INT AD, comments for draft-ietf-opsawg-mud-iot-dns-considerations-12 Thank you for the work put into this document. It is a nice piece of work, clear and easy to read. Please find below some non-blocking COMMENT points (but replies would be appreciated even if only for my own education). 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. 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 available (no need to wait for it though): https://datatracker.ietf.org/doc/draft-ietf-opsawg-mud-iot-dns-considerations/reviewrequest/19052/ You may also expect an Int-dir review as: https://datatracker.ietf.org/doc/draft-ietf-opsawg-mud-iot-dns-considerations/reviewrequest/19051/ (not yet assigned though) I hope that this review helps to improve the document, Regards, -éric # COMMENTS (non-blocking) ## Absence of mDNS Is mDNS used in the context of MUD ? If so, then it should be mentioned here. ## Abstract Let's be positive s/This document details concerns /This document details considerations / ## 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. ## Section 3 Suggest to always use "DNS names" rather than plain "names". Applicable in several places in the document. Isn't the mapping from address to DNS names usually called "reverse mapping" ? E.g., section 3.1.3 uses `reverse names`. ## 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`. ## 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. ## Section 3.1.3 `Service providers` is rather vague in this context, is it the access/internet SP or a hosted-IoT-service ? ## 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. ## Section 4 Thanks for pointing me to "antipatterns", I learned something :-) OTOH, I had to follow the link to understand the paragraph :-( ## Section 4.3 Unsure whether using a real case with Amazon is useful here... ## Section 5 Whether the MUD devices and the MUD controllers use the same recursive resolver is probably orthogonal to the use of DoT/DoH. ## Section 6 AFAIK, LLDP can also be used per RFC 8520 in addition to DHCP to retrieve the MUD string. ## 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. Which are the reasons in `There are a number of reasons to avoid this` ? ## 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. ## References Please note that DNR & DDR are published as RFC 9462 / 9463 (dated November 2023). ___ OPSAWG mailing list OPSAWG@ietf.org https://www.ietf.org/mailman/listinfo/opsawg
