Re: [Gen-art] [OPSAWG] Genart early review of draft-ietf-opsawg-mud-08

["M. Ranganathan" <[e-mail]>]

Hi Eliot,

Reply in line below:

On Thu, Aug 31, 2017 at 4:41 AM, Eliot Lear <[e-mail]> 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 <[e-mail]>
> 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