[dhcwg] Re: Fw: New Version Notification for draft-woodworth-dhcp-dwirm-00.txt

["JW ,\\ John Woodworth" <[e-mail]>]

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" <[e-mail]>

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: [e-mail] <[e-mail]>




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 <[e-mail]>

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.