Re: [OPSAWG] [Iot-directorate] Iotdir telechat review of draft-ietf-opsawg-mud-iot-dns-considerations-12
Thanks Michael for working on this. See answers below. > -Original Message- > From: Michael Richardson > Sent: Wednesday, March 27, 2024 7:35 AM > To: Dave Thaler > Cc: iot-director...@ietf.org; m...@ietf.org; Eric Vyncke ; > draft-ietf-opsawg-mud-iot-dns-considerations@ietf.org; last-c...@ietf.org; > opsawg@ietf.org > Subject: Re: [Iot-directorate] Iotdir telechat review of > draft-ietf-opsawg-mud- > iot-dns-considerations-12 > > > Dave Thaler via Datatracker wrote: > > Section 3.2 (A successful strategy): > >> This situation does not result in failures as long as all possible A/ > >> 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. > > okay, so that's a good point. > Recommendation 0: use DNS? > Or maybe just clarify that the scope is only for devices that use DNS? I'd probably suggest just clarifying that the scope is only for devices that use DNS. > > 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. > > yes. > If the device has hard-coded IP addresses in the firmware (it has happened > many times, I think. There was an NTP situation a decade ago...) then that's > okay, just hard-code the same IP address into the MUD file. > > If the device uses some other elaborate protocol, then I agree, it's a > problem.I'm not sure what I should say about that, other than scope it > out of scope? Yeah, I'd probably explicitly say it's out of scope. > >> 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. > > Yes. having the MUD controller be the recursive DNS server is how this whole > document got started. We implemented exactly that for the SHG project at > CIRA.ca. > Then we discussed failure situations, and enterprise situations, and 8.8.8.8 > usage. > > Paul Vixie has a few rants about trying to get various devices in his home to > use the (DHCP) provided DNS servers, and how often they'd wander off and > use > 8.8.8.8 even when the local one was working perfectly fine... and the number > of devices that fail when 8.8.8.8 is blocked. I think he also tried > impersonating 8.8.8.8, which works fine for Do53, but ought to fail for all > secured versions, and how many devices just continued working, because > they didn't actually check the certificate. I don't know how/if to include > any > of this. > > > 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. > > okay. I will think on how to address this. > I'll also stop here, and continue tomorrow. Here I'd probably say that having an enforcement point that has to make DNS queries periodically, instead of directly using the DNS cache in the recursive resolver used by the IoT devices, is NOT RECOMMENDED as it causes
Re: [OPSAWG] [Iot-directorate] Iotdir telechat review of draft-ietf-opsawg-mud-iot-dns-considerations-12
Dave Thaler via Datatracker wrote: > Section 3.2 (A successful strategy): >> This situation does not result in failures as long as all possible A/ >> 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. okay, so that's a good point. Recommendation 0: use DNS? Or maybe just clarify that the scope is only for devices that use DNS? > 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. yes. If the device has hard-coded IP addresses in the firmware (it has happened many times, I think. There was an NTP situation a decade ago...) then that's okay, just hard-code the same IP address into the MUD file. If the device uses some other elaborate protocol, then I agree, it's a problem.I'm not sure what I should say about that, other than scope it out of scope? >> 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. Yes. having the MUD controller be the recursive DNS server is how this whole document got started. We implemented exactly that for the SHG project at CIRA.ca. Then we discussed failure situations, and enterprise situations, and 8.8.8.8 usage. Paul Vixie has a few rants about trying to get various devices in his home to use the (DHCP) provided DNS servers, and how often they'd wander off and use 8.8.8.8 even when the local one was working perfectly fine... and the number of devices that fail when 8.8.8.8 is blocked. I think he also tried impersonating 8.8.8.8, which works fine for Do53, but ought to fail for all secured versions, and how many devices just continued working, because they didn't actually check the certificate. I don't know how/if to include any of this. > 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. okay. I will think on how to address this. I'll also stop here, and continue tomorrow. -- ] Never tell me the odds! | ipv6 mesh networks [ ] Michael Richardson, Sandelman Software Works| network architect [ ] m...@sandelman.ca http://www.sandelman.ca/| ruby on rails[ -- 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
Re: [OPSAWG] Martin Duke's No Objection on draft-ietf-opsawg-mud-iot-dns-considerations-12: (with COMMENT)
Martin Duke via Datatracker wrote: > (4.1) There's an editorial error here. > "An authoritative server might be tempted to provide an IP address literal > inside the protocol: there are two arguments (anti-patterns) for doing this." > I'm expecting two reasons someone might use an IP literal. > "The first is that it eliminates problems with firmware updates that might be > caused by lack of DNS..." > Yep, that tracks. > "The second reason to avoid a IP address literal in the URL is when an inhouse > content-distribution system is involved..." > But this is making the opposite point! It appears that this section is actually > presenting ONE (not two) reason to use IP literals, and then several reasons > that's a bad idea. So say that! In my mind, an in-house CDN is a bunch of HTTP/FTP servers which just don't have DNS names, because someone hacked the system together in an afternoon. Let me think about how to rephrase that. Or maybe it's really just two examples of the same thing, and as you say, it's not two reasons, but two kinds of one reason. Or maybe I missed another reason to use literals. -- 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
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] side meeting #119: Power Metrics: concrete usage example
Hi Jari, Thanks for your comments and offer to help, it will be greatly received! We are in the process of setting up the open mailing list. Once that has been created, and advertised, then I will move discussion on the BOF and WG charter discussion there. Ack, on whether a BOF is needed or not. In the past, when I was an AD, I generally favoured chartering WGs directly, e.g., for IOTOPS, IVY, NMOP, but I’ll defer to Mahesh & the IESG to consider which may be the best path here. Either, way I think that the key part of this work is really defining the charter for that WG. I’m also in complete agreement with you on a very tightly scoped, short lived, WG. In particular, I believe that it should be for work that is broadly understood and that can be achieved in a short time frame. Regards, Rob From: Jari Arkko Date: Wednesday, 27 March 2024 at 00:09 To: Rob Wilton (rwilton) Cc: Carlos Pignataro , Marisol Palmero Amador (mpalmero) , opsawg@ietf.org , e-imp...@ietf.org , inventory-y...@ietf.org , Alexander Clemm , Alberto Rodriguez-Natal (natal) , Ron Bonica , Mahesh Jethanandani , Ali Rezaki (Nokia) , Suresh Krishnan (sureshk) Subject: Re: [OPSAWG] side meeting #119: Power Metrics: concrete usage example Rob, One of the challenges we appear to be having is that the working groups that should potentially care about some of the metrics work for instance are busy. I find that somewhat unfortunate, but it may be what it is. The IAB program is not a place for us to standardize protocols or data models, though of course it can be a place to discuss what work is happening in the IETF or is not but should. So if the WGs like OPSAWG or IVY have little bandwidth for the the work that needs to happen, then new IETF activities should be created for it. I have two comments to consider though: 1. Sometimes if the work is clear enough but no room in an existing working group, WGs can also created directly. Not sure if this is feasible in this case. 2. I’d be happy to contribute to a BoF personally. But it is *very* important that it be scoped extremely tightly. This is a topic where we can easily attract any level of discussion, and BoF proposals with clear, concrete goals (”add this YANG thing”) succeed, whereas proposals with vague or unclear or debated scopes may not proceed as fast or at all. Jari Rob Wilton (rwilton) kirjoitti 26.3.2024 kello 0.48: Hi Carlos, During IETF 119, I had a couple of discussions with Suresh and Mahesh regarding how we actual get some of the short term “green” related work happening in IETF to get critical mass and cross review and get published in the short term. This seemed to somewhat culminate during the Power Metrics side meeting where it is clear that: · Various folks, representing different organizations, have various drafts related to Green networking. · Currently these drafts are spread out to different working groups, have various amounts of overlap, and it is unclear that they currently have a good homes and sufficient traction in IETF to progress effectively. · There was support in the meeting to target a WG forming BOF for IETF 120 to create a new WG with a limited targeted charter. Hence the proposal from Suresh and I was to try and help coordinate for a WG forming BOF for IETF 120 scoped specifically to work on items that are understood and achievable in the short term. E.g., roughly, I currently think of this work scope as being: e.g., energy related terminology and definitions (that should try and leverage and reference existing definitions from existing published sources), reporting energy and sustainability at the device and network layer via operational YANG models, and to facilitate configuration or YANG RPCs to influence and optimise power usage on network devices. Longer term energy efficiency and Green networking goals are intended to be out of scope for the proposed WG’s initial charter, and should continue to be discussed as part of the E-Impact IAB program. The exact scope of the charter would be worked out between the interested parties in the coming weeks. I’m happy to try and help this work gain traction within the IETF. I appreciate that several of the proponents for this work are also from Cisco, but I have no vested interest other than trying to help the industry take small steps that may help improve energy efficiency in networks (e.g., reporting power usage, and as Tony suggests by selectively powering off ports or linecards) to try and help mitigate some of the impacts of the Internet on climate change. To that end the proposed next steps from that side meeting were: 1. For me to request the creation of new open “green-bof” mailing list from Mahesh (hopefully should be done over the next few days). 2. I asked for, and received, permission to subscribe those who attended the side meeting, but once created, I also intended to circulate
