Hi Eliot,
Reply in line below:On Thu, Aug 31, 2017 at 4:41 AM, Eliot Lear <lear@xxxxxxxxx> 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 <rjsparks@xxxxxxxxxxx> 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 ).
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