Good evening, fellow members,I appreciate your time and feedback during this afternoon's presentation. I will work with my co-authors to prepare another draft for the mailing lists, and look forward to more great discussion.Best,John -------- Original message --------From: "Woodworth, John R" <[email protected]>
Good evening, Apologies for the delay in bringing this to the groups' attention, but I am looking forward to discussing this in the int-area session on Tuesday. I've included some feedback we received from Bernie Volz at the end of this announcement and welcome any additional feedback the group has to offer. Best, John From: [email protected] <[email protected]> A new version of Internet-Draft draft-woodworth-dhcp-dwirm-00.txt has been successfully submitted by John Woodworth and posted to the IETF repository. Name: draft-woodworth-dhcp-dwirm Revision: 00 Title: Defend the World from IoT Remote-threats & Malware Date: 2025-10-20 Group: Individual Submission Pages: URL: https://www.ietf.org/archive/id/draft-woodworth-dhcp-dwirm-00.txt Status: https://datatracker.ietf.org/doc/draft-woodworth-dhcp-dwirm/ HTML: https://www.ietf.org/archive/id/draft-woodworth-dhcp-dwirm-00.html HTMLized: https://datatracker.ietf.org/doc/html/draft-woodworth-dhcp-dwirm Abstract: Internet of Things (IoT) devices are commonly added to home networks without fully understanding which services (hosts, ports, protocols) are being provided or consumed for those devices to operate. As a result, they are essentially unmanaged threats with full access to that network and the internet. The Defend the World from IoT Remote- threats & Malware (DWIRM) extension to DHCP provides a framework for IoT devices to negotiate services that the local router in turn enforces as policy. The IETF Secretariat -- From: Bernie Volz <[email protected]> Subject: Re: IETF124 presentation If you proceed with your approach, you likely should consider adding a dhcp (bootp) option that a client can send in the parameter request list to learn whether a server supports your new feature (message). That avoids these messages ever being sent on networks that don’t support the capability. Client does normal dhcp includes the option in the PRL. If server supports, it responds with option. If client receives option, it then sends new message to request the data. New option here is just a signal-no data. Refer to https://datatracker.ietf.org/doc/rfc9686/ (dhcpv6 work) as this technique is used there. You will also need to fill in more about exactly what these new messages contain and how all your data is formatted. One nice thing about the MUD option is that only URL is communicated and that can usually just be a new option that likely fits in existing packets. Also, the larger data is exchanged with http(s) and thus not limited by single packet size. But, yes it does require more infrastructure on the IoT device (though that isn’t as big an issue these days as compared to more limited devices in the past). Anyway, likely would be better to move this whole discussion to dhc wg mailing list so others can benefit. Andm they may have useful input/comments. Feel free to use my messages if you do move discussion. - Bernie This communication is the property of Lumen Technologies and may contain confidential or privileged information. Unauthorized use of this communication is strictly prohibited and may be unlawful. If you have received this communication in error, please immediately notify the sender by reply e-mail and destroy all copies of the communication and any attachments.
_______________________________________________ Int-area mailing list -- [email protected] To unsubscribe send an email to [email protected]
