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

Eliot Lear <lear@cisco.com> Thu, 31 August 2017 08:41 UTC

Return-Path: <lear@cisco.com>
X-Original-To: gen-art@ietfa.amsl.com
Delivered-To: gen-art@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C0B67132620; Thu, 31 Aug 2017 01:41:32 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -14.499
X-Spam-Level:
X-Spam-Status: No, score=-14.499 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-5, SPF_PASS=-0.001, URIBL_BLOCKED=0.001, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=cisco.com
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id hgd3xnssRLaG; Thu, 31 Aug 2017 01:41:31 -0700 (PDT)
Received: from aer-iport-1.cisco.com (aer-iport-1.cisco.com [173.38.203.51]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id D88C8132358; Thu, 31 Aug 2017 01:41:29 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=8823; q=dns/txt; s=iport; t=1504168890; x=1505378490; h=subject:to:cc:references:from:message-id:date: mime-version:in-reply-to; bh=WK2LzKZOb0zgqg2jYdZ9Hpa6qyPK0Lrh6HBZOFfnWG0=; b=RbFj9UOYfKBdZ207GDMvut6TZXne4ZJ0E7RNsxZXM/vquPMK52j6aNjM gxtHWG2GbBcXiSTYUXjfUuWsPPgOIn05AelCyzrfggBlvknvCr2rZyQAd ZUYWFdO8Ihn/EnlWSzEao+kUBBhj8hWHO7X/paWmB1CqlTrYElqBUdEEL A=;
X-Files: signature.asc : 481
X-IronPort-Anti-Spam-Filtered: true
X-IronPort-Anti-Spam-Result: A0BEAwAJy6dZ/xbLJq1eGQEBAQEBAQEBAQEBBwEBAQEBgy2CJoN3ixSQeSKQaYU+ghIHhUAChGwWAQIBAQEBAQEBayiFGQEFI1YQCxgnAwICRhEGAQwGAgEBii2wHYInJ4sdAQEBAQEBAQEBAQEBAQEBAQEBAQEBDg+DKoVeC4FlgQ2EX4MpgmEBBKBvhDmCIY13ghOFZ4NZhxuWRSYFLIENMiEIHBVJhRgcgWk+Noo9AQEB
X-IronPort-AV: E=Sophos;i="5.41,451,1498521600"; d="asc'?scan'208,217";a="696869282"
Received: from aer-iport-nat.cisco.com (HELO aer-core-3.cisco.com) ([173.38.203.22]) by aer-iport-1.cisco.com with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384; 31 Aug 2017 08:41:25 +0000
Received: from [10.61.80.230] (ams3-vpn-dhcp4327.cisco.com [10.61.80.230]) by aer-core-3.cisco.com (8.14.5/8.14.5) with ESMTP id v7V8fOHi030151; Thu, 31 Aug 2017 08:41:25 GMT
To: "M. Ranganathan" <mranga@gmail.com>, Robert Sparks <rjsparks@nostrum.com>
Cc: gen-art@ietf.org, draft-ietf-opsawg-mud.all@ietf.org, opsawg@ietf.org, ietf@ietf.org
References: <150411366399.21627.17047458871931107094@ietfa.amsl.com> <CAHiu4JMCtxFY9qu6q4h30Y=GExx69yLg7xRbSirgURy=7+4_Lw@mail.gmail.com>
From: Eliot Lear <lear@cisco.com>
Message-ID: <8a26b512-495b-4315-a885-32acd41c5460@cisco.com>
Date: Thu, 31 Aug 2017 10:41:28 +0200
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.12; rv:52.0) Gecko/20100101 Thunderbird/52.3.0
MIME-Version: 1.0
In-Reply-To: <CAHiu4JMCtxFY9qu6q4h30Y=GExx69yLg7xRbSirgURy=7+4_Lw@mail.gmail.com>
Content-Type: multipart/signed; micalg="pgp-sha256"; protocol="application/pgp-signature"; boundary="0qe0LOGonjdSE19rTg8FL8PgpeM1CSBp1"
Archived-At: <https://mailarchive.ietf.org/arch/msg/gen-art/7cUEfhBf9e_aT5-qLM5_BHHUXC8>
Subject: Re: [Gen-art] [OPSAWG] Genart early review of draft-ietf-opsawg-mud-08
X-BeenThere: gen-art@ietf.org
X-Mailman-Version: 2.1.22
Precedence: list
List-Id: "GEN-ART: General Area Review Team" <gen-art.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/gen-art>, <mailto:gen-art-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/gen-art/>
List-Post: <mailto:gen-art@ietf.org>
List-Help: <mailto:gen-art-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/gen-art>, <mailto:gen-art-request@ietf.org?subject=subscribe>
X-List-Received-Date: Thu, 31 Aug 2017 08:41:33 -0000

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@nostrum.com
> <mailto:rjsparks@nostrum.com>> 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