Re: [Gen-art] Genart telechat review of draft-ietf-opsawg-mud-20

Joe Clarke <jclarke@cisco.com> Tue, 10 April 2018 20:31 UTC

Return-Path: <jclarke@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 8E72412895E; Tue, 10 Apr 2018 13:31:45 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -14.511
X-Spam-Level:
X-Spam-Status: No, score=-14.511 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_HI=-5, SPF_PASS=-0.001, T_DKIMWL_WL_MED=-0.01, 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 5oa33bEB0FoP; Tue, 10 Apr 2018 13:31:44 -0700 (PDT)
Received: from alln-iport-6.cisco.com (alln-iport-6.cisco.com [173.37.142.93]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id BB9B51272E1; Tue, 10 Apr 2018 13:31:43 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=2159; q=dns/txt; s=iport; t=1523392303; x=1524601903; h=subject:to:cc:references:from:message-id:date: mime-version:in-reply-to:content-transfer-encoding; bh=WfSDmKJYaiilp5+daJAWJJfn0Ia6b/yjbUjw6X8P2yU=; b=LjeWFWcdH05Xzdo8nW+bnkCXM3sbzVTZ1RJG6/m6wv1SfuEYF4jyCj0f pQULCW2nySFtIf5N6rvzIetgjbCayC4GWZMshN9N+3rs2kcYIMfzVyrd6 iu7tCSL28hYSbFSSFcRp1pkcE4gB7wBVTDlNge+5m+lCEpGaFV67bjzji 0=;
X-IronPort-AV: E=Sophos;i="5.48,433,1517875200"; d="scan'208";a="96449581"
Received: from alln-core-7.cisco.com ([173.36.13.140]) by alln-iport-6.cisco.com with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384; 10 Apr 2018 20:31:43 +0000
Received: from [10.118.87.88] (rtp-jclarke-nitro7.cisco.com [10.118.87.88]) by alln-core-7.cisco.com (8.14.5/8.14.5) with ESMTP id w3AKVgxc007968; Tue, 10 Apr 2018 20:31:43 GMT
To: Eliot Lear <lear@cisco.com>, Robert Sparks <rjsparks@nostrum.com>, gen-art@ietf.org
Cc: draft-ietf-opsawg-mud.all@ietf.org, opsawg@ietf.org, ietf@ietf.org
References: <152329667548.30723.13155842895888603902@ietfa.amsl.com> <10591659-b464-ad66-a499-6567202cc782@cisco.com>
From: Joe Clarke <jclarke@cisco.com>
Openpgp: preference=signencrypt
Autocrypt: addr=jclarke@cisco.com; prefer-encrypt=mutual; keydata= xsDiBDyDmj4RBADa/Icz5Xl+cJUGNxC/tWgXWqcA9VA8GN+PeqKhXS0BnVHntdsQxbpFUUKK 4ld0Zex/Rec1jgC/ikExJHHIee8ZVcHqP+tsWexi83/ZvEdzI95diBp2Is5fYp8P8hdIBNQS Ooc1jVYrTJUaZgJK2uBzbkh/WbipwsQbueRzXqPORwCgsPNrStLzqOpjrA7FdUz/JVQf5+8D /1SiKAOFiW4TxY+fS09lqiLs3mbXjvw23iQwLxje4vBd4+b9iAUWOsSretSKv6OE9ZlD4FYe a8HmMgEkuKfXGc8GvTq4J1uHZ0gcVbrBGmxAUBPPaAENYEJfJf7dcysKVAl14ZQVIvzAGJAZ HGuegD7uekGKnOEA61R3ze4aM2zNA/96I77l0qiMc6J7gXmiD5uxC7FsSCFj5sqTYMgBqzIY EZjU/tTUbth84xcRi4X0WNkaILqq1mOcBfmzQMvzG1n1CydmJU6iF1ewle6cIui9TQYg5CES rJF7xid4vVXRz+xi6hc1+0bSaoJa3sfpNrSSr0lKGdWHZozWdQjOvTMCXc1CSm9lIE1hcmN1 cyBDbGFya2UgKEZyZWVCU0QgY29tbWl0dGVyIGFkZHJlc3MpIDxtYXJjdXNARnJlZUJTRC5v cmc+wl8EExECABcFAjyuLU0FCwcKAwQDFQMCAxYCAQIXgAASCRBvaI+K/hTPhwdlR1BHAAEB 7U0AoICIVoBe9B8bo1lrvHh+UF7GY/WaAJ9C2mCThFrmqxCr2bCtR12UoPCPqs7ATQQ8g5pA EAQAqk1J4LBDLeWs6ZOkPDYYcKCSAu0qlzEf5YP/TcSeZcjJyXILgesFXcayoy1v7ILPQSXj 4p5uzRyn0fuGqiTvajjxMZz1aSkvgGyS+gc+PDmi4SJ2N/tX2isrul8MK+NGeUsLuZaM1JKh gKpq9yuu3D3ELG7ESga7xsOs1V/sSd8AAwUD/20XByIlsUUC/65KG/DQ1WfX2gNuy5If9tSP Q6h1Lno5Hv3ow3ktybIoQSxbcBo28nA/Gzg5NFGVkkqfOkH2xtS6V0K/WjzsrloBHCPFiKp2 yHpXfKubxl8yefQPTMj8hLwlBKrNiN1fz5/629TIkEwDwrUwHxQreE7FAzPMqHORwkYEGBEC AAYFAjyDmkAACgkQb2iPiv4Uz4cnuQCfX1zNrahRTWz/HRpF7ms8qZqzdOIAn1uuu6Jst43p DzanBHUOBzUP6ymA
Organization: Cisco
Message-ID: <d8ef4cf4-c58e-403d-83b1-bcfea8553fb8@cisco.com>
Date: Tue, 10 Apr 2018 16:31:42 -0400
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.13; rv:52.0) Gecko/20100101 Thunderbird/52.7.0
MIME-Version: 1.0
In-Reply-To: <10591659-b464-ad66-a499-6567202cc782@cisco.com>
Content-Type: text/plain; charset=utf-8
Content-Language: en-US
Content-Transfer-Encoding: 8bit
Archived-At: <https://mailarchive.ietf.org/arch/msg/gen-art/VkBgfgcOmuIB2cJPB599xLmM1cs>
Subject: Re: [Gen-art] Genart telechat review of draft-ietf-opsawg-mud-20
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: Tue, 10 Apr 2018 20:31:46 -0000

On 4/10/18 06:43, Eliot Lear wrote:
> With that in mind, I propose the following edit:
> 
> DHCP servers may implement MUD functionality themselves or they may
> pass along appropriate information to a network management system or
> MUD controller.  A DHCP server that does process the MUD URL MUST adhere
> to the process specified in {{RFC2818}} and {{RFC5280}} to validate
> the TLS certificate of the web server hosting the MUD file.  Those
> servers will retrieve the file, process it, create and install the
> necessary configuration on the relevant network element.  Servers
> SHOULD monitor the gateway for state changes on a given interface.  A
> DHCP server that does not provide MUD functionality and has forwarded
> a MUD URL to a MUD controller MUST notify the MUD controller
> of any corresponding change to the DHCP state of the client
> (such as expiration or explicit release of a network address lease).
> 
> Should the DHCP server fail, in the case when it implements the MUD
> controller functionality, any backup mechanisms SHOULD include the MUD
> state, and the server SHOULD resolve the status of clients upon its
> restart, similar to what it would do, absent MUD controller
> functionality.  In the case where the DHCP server forwards information
> to the MUD controller, the MUD controller will either make use of
> redundant DHCP servers for information, or otherwise clear state based
> on other network information, such as monitoring port status on a
> switch via SNMP, Radius accounting, or similar mechanisms.

Robert says this text works for him, and it does address the comments,
but I wonder if it's getting too far afield where at this point you're
re-describing a MUD controller as a software feature of DHCP?  That is,
do we really need to call out that a DHCP server can _also_ be a MUD
controller?  They may be co-resident on the same server, they may be in
the same process space.  Does it matter?

It seems to me, the most valuable part of this text is the in the second
paragraph where the DHCP state's impact on the MUD controller (where
ever that is) is described.

Joe