Hi Eliot, Reply in line below:
On Thu, Aug 31, 2017 at 4:41 AM, Eliot Lear <[email protected]> wrote: > Hi Ranga, > > Robert wrote a great review, and I'll respond to him in due course with > suggested changes. I wanted to take just a moment to comment to you on > your point: > > On 8/31/17 12:00 AM, M. Ranganathan wrote: > > > > On Wed, Aug 30, 2017 at 1:21 PM, Robert Sparks <[email protected]> > wrote: > >> >> >> Right now, you leave the DHCP server (when it's used) responsible for >> clearing state in the MUD controller. Please discuss what happens when >> those are distinct elements (as you have in the end of section 9.2) and >> the DHCP server reboots. Perhaps it would make sense for the DHCP server >> to hand the length of the lease it has granted to the MUD controller and >> let the MUD controller clean up on its own? >> > > I would like to add a few words to the comprehensive review presented by > Robert Sparks (I hope it is proper etiquette on this list to do so). > > With respect to the observation above: > > There is also a cache timeout in the MUD profile. Does it make sense that > the MUD controller should take the minimum of the DHCP lease time and the > cache timeout and use that to time out the installed ACLs (?) The DHCP > server should also pass to the MUD controller, some way of identifying the > device to which the lease has been granted (for example the MAC address of > the device). > > The draft also not specify how the DHCP server will communicate with the > MUD controller (presumably via a simple REST interface but what is the URL > to be used and how are the parameters passed?). I think this should be > specified for interoperability between DHCP clients and MUD servers. Maybe > words describing this interaction can be added here. > > > That's right. At the moment, this is an "internalized" function. That is > to say that the DHCP server is said to be tightly coupled to the MUD > controller without standardized interfaces. In my first implementation, I > literally just tailed dhcpd syslog entries and triggered MUD based on > DHCPREQUEST messages. Clean-up state had to do with RELEASE or periodic > SNMP queries. Our implementation at Cisco does something different. > > However... if the OPSAWG would like, and there is interest, we can > formalize that interface. I don't want to do it in THIS draft (it's > already fairly involved), but there's nothing to say we couldn't do some > follow-on work. > > Fair enough? > > Eliot > No problem with waiting to see if there's interest from OPSAWG and others before considering this. By way of explanation on why I think this makes sense to standardize in MUD: I had envisioned an architecture where the MUD controller runs in the Service Provider cloud. The DHCP server would run in the CPE router (e.g. as part of the firmware on a home router + NAT ). If the statement above makes sense, since the home router is typically not made by the same party as the service provider software, I was thinking there should be a standardized interface between the DHCP server and MUD controller. Thanks. Ranga -- M. Ranganathan
_______________________________________________ OPSAWG mailing list [email protected] https://www.ietf.org/mailman/listinfo/opsawg
