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

Eliot Lear <lear@cisco.com> Wed, 11 April 2018 06:35 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 7BDB9126C2F; Tue, 10 Apr 2018 23:35:27 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -14.51
X-Spam-Level:
X-Spam-Status: No, score=-14.51 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, 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 l8BhOjgaIKjR; Tue, 10 Apr 2018 23:35:22 -0700 (PDT)
Received: from aer-iport-3.cisco.com (aer-iport-3.cisco.com [173.38.203.53]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id CE1EF1241FC; Tue, 10 Apr 2018 23:35:21 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=34964; q=dns/txt; s=iport; t=1523428522; x=1524638122; h=subject:to:cc:references:from:message-id:date: mime-version:in-reply-to; bh=q8wrvAh7sMn7/DqlTo9VnL/zAdfl8rQ9qeeT+upaYOY=; b=a5Bn1eC6GMvq7wC9ZCXQ1WpfHH9nTh1GVWT4/WHiYvSaoH7n428VZulW +ibcSKViWZUHEaDufCvyZB0gz5wvF6YILf2gtxfH5tyMDfvZuWSv8vX3P gYCQ97/9ZW86OsgPQqa3u+0YE5dsC+bOCjNYaxngoavnUO+7UtFYAatQI c=;
X-IronPort-Anti-Spam-Filtered: true
X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0AYBAA8q81a/xbLJq0ZAUIZAQEBAQE?= =?us-ascii?q?BAQEBAQEBBwEBAQEBgxMEgQxvhAqIAV6NfimBD5JeFIFmCyOEYAKCazQYAQI?= =?us-ascii?q?BAQEBAQECbBwMhSIBAQEBAgEaCVYQCw4EAgQgCgICSQ4GAQwIAQGFAQgPiX2?= =?us-ascii?q?cKoIcH4gxghoFigGBDCKBZnyDEQKBGB0PAjaCYIJUAocNBygFCoQzhFeGewi?= =?us-ascii?q?FVoZKghAGgTODWoI3hH+JH4ZvgSUcOIFSMxoIGxU6gkSCGgUXegEIh1aFQD2?= =?us-ascii?q?MbAIkB4IYAQE?=
X-IronPort-AV: E=Sophos;i="5.48,434,1517875200"; d="scan'208,217";a="3076485"
Received: from aer-iport-nat.cisco.com (HELO aer-core-4.cisco.com) ([173.38.203.22]) by aer-iport-3.cisco.com with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384; 11 Apr 2018 06:35:19 +0000
Received: from [10.61.160.124] ([10.61.160.124]) by aer-core-4.cisco.com (8.14.5/8.14.5) with ESMTP id w3B6ZIq7010233; Wed, 11 Apr 2018 06:35:18 GMT
To: 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> <efb9927a-a0af-9578-096f-e5185316aa4f@nostrum.com>
From: Eliot Lear <lear@cisco.com>
Openpgp: preference=signencrypt
Autocrypt: addr=lear@cisco.com; prefer-encrypt=mutual; keydata= xsBNBFMe1UQBCADdYOS5APDpIpF2ohAxB+nxg1GpAYr8iKwGIb86Wp9NkK5+QwbW9H035clT lpVLciExtN8E3MCTPOIm7aITPlruixAVwlBY3g7U9eRppSw9O2H/7bie2GOnYxqmsw4v1yNZ 9NcMLlD8raY0UcQ5r698c8JD4xUTLqybZXaK2sPeJkxzT+IwupRSQ+vXEvFFGhERQ88zo5Ca Sa1Gw/Rv54oH0Dq2XYkO41rhxQ60BKZLZuQK1d9+1y3I+An3AJeD3AA31fJZD3H8YRKOBgqe ILPILbw1mM7gCtCjfvFCt6AFCwEsjITGx55ceoQ+t5B5XGYJEppMWsIFrwZsfbL+gP31ABEB AAHNJUVsaW90IExlYXIgPGxlYXJAb2Zjb3Vyc2VpbXJpZ2h0LmNvbT7CwHsEEwECACUCGwMG CwkIBwMCBhUIAgkKCwQWAgMBAh4BAheABQJTHtXCAhkBAAoJEIe2a0bZ0nozBNoH/j0Mdnyg CgNNmI4DyL9mGfTJ/+XiTxWXMK4TTszwwn/tsXjyPQWjoO6nYqz5i96ItmSpkelSGVpzU+LK LQxSjFeUvKw23bp1rVecfGR+OENSE1m6KfFj3vtzQOZ2/FgK210MWnlYNNyAHX6Pf6hKInTP v6LbZiAQMCmf0aPvRbk/aPSNJAuIKrLrrCgAlwelrTavFsSwnKI3dhSG8DJ9+z/uiXDiHYra Ub3BKp5K/x71Zd8hUsWm2simnE/6HvZaZz7CC29JSZ/5gGtNB3OMNKLzLWUbQacF3IKxpW66 ZFYFYnlBV4jRnKlmb40YcEXWVJkkVC8g+/J9Qo6R8BdmSTXOwE0EUx7VRAEIALRZXth1u/3n FgY+G2FN0KEEik+2Xsk8JX9zr/eISa+Ol8a4U1orgxpyP2V7bQQDkDUEfs+Asagc6I8zrk3K xGln3pFFVfdM18uaEYwWvmE84Y12r7FwYdW62bA9X1Ttsp5Q1GI8XHdh0SQTF12pXYTwWW1P THYVIp7bGzM88cHqBW0xyRflu4j2nUrd9tWFd28SRxhj+MHQkQkbKFLloRty3lwdS8MCRPzX 9gUrkl+DxFHC7WrW3Vi4glI5YBlD0n2hSyDoP1GkKVT60gUGh7eJOnUBR8lzKm5wYqAtgq2m 79rKBylA40diRhbnTTeY+ytqMWFF5UXm97Jwxsezi7kAEQEAAcLAXwQYAQIACQUCUx7VRAIb DAAKCRCHtmtG2dJ6M5K5CADbunatgHsqHbR3KbpXxzralakEcdODGv/fbN6/EdKJeXrG9QKD lPxZTB9STw6+ANwESsr9uUMAxdDNKDeynjnQmFHxGdcdcXlnPZPThfseeUhUkbB/YKOfDIQA kKozNoKYj6Dcia+D/wvifIEW+GUUcO/6Qi8yK6PLJyM8C7vHEqmUGzX8gTCYOgAyOd4WZrC9 95CfB0yFIorw+MpK7MZTm5SbGPcYF9Gq9MzSqmaEw8U6YOElKYfnkcsCTLYyWaolhck+3/0R 9ISEWK5rUzqAuK40S4+Sn7yNycdCoqvQh4e3xSpzAu3aYZ8jKXQVV0X2G9Y+M1HMZuCqhPUO LTdF
Message-ID: <b18d6e8f-7b31-158a-d4e8-e1e834211025@cisco.com>
Date: Wed, 11 Apr 2018 08:35:18 +0200
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: <efb9927a-a0af-9578-096f-e5185316aa4f@nostrum.com>
Content-Type: multipart/alternative; boundary="------------ACB27F9B4CD32B67120747BF"
Content-Language: en-US
Archived-At: <https://mailarchive.ietf.org/arch/msg/gen-art/vZZmxmzUEwwFEWsx-7ISuXjvsLc>
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: Wed, 11 Apr 2018 06:35:28 -0000

Hi Robert,

A few additional comments below:


On 10.04.18 16:22, Robert Sparks wrote:
>
>
>
> On 4/10/18 5:43 AM, Eliot Lear wrote:
>>
>> Hi Robert and thanks again for the review.  Please see below for
>> responses.  These are my personal views.  The WG chairs / shepherds
>> may have different opinions.
>>
> Thank you for the very quick response!
>>
>>
>> On 09.04.18 19:57, Robert Sparks wrote:
>>> Reviewer: Robert Sparks
>>> Review result: Ready with Issues
>>>
>>> I am the assigned Gen-ART reviewer for this draft. The General Area
>>> Review Team (Gen-ART) reviews all IETF documents being processed
>>> by the IESG for the IETF Chair. Please wait for direction from your
>>> document shepherd or AD before posting a new version of the draft.
>>>
>>> For more information, please see the FAQ at
>>>
>>> <https://trac.ietf.org/trac/gen/wiki/GenArtfaq>;.
>>>
>>> Document: draft-ietf-opsawg-mud-20
>>> Reviewer: Robert Sparks
>>> Review Date: 2018-04-09
>>> IETF LC End Date: 2017-11-07
>>> IESG Telechat date: 2018-04-19
>>>
>>> Summary: Almost ready but with minor issues to address before publication as a
>>> standards track RFC 
>>>
>>> Minor issues:
>>>
>>> Section 3.15 is confused, and I don't think you'll get the implementation you
>>> intend with the MUST in the current language. direction-indicated is not a
>>> flag. The text about dropping should talk about matching the direction that was
>>> indicated.
>>
>> Having reread this section (and perhaps I am a bit too close to the
>> text), perhaps it is a bit confused.  How about something along the
>> following lines:
>>
>> 3.15.  direction-initiated
>>
>>    When applied this matches the direction in which a TCP connection is
>>    initiated.  When direction initiated is "from-device", packets
>> that are
>>    transmitted in the direction of a thing MUST be dropped unless the
>> thing
>>    has first initiated a TCP connection.  This node may be implemented in
>>    its simplest form by looking at naked SYN bits, but may also be
>> implemented
>>    through more stateful mechanisms.
>>  
>>   [RFC6092] specifies IPv6 guidance best
>>    practices.  While that document is scoped specifically to IPv6, its
>>    contents are applicable for IPv4 as well. 
>>
>>
>> Better?
> wfm
>>
>>> The quoted issues below are from my early review of -08. I don't think they've
>>> been addressed or responded to. Apologies if I missed a response.
>>>
>>>> The document proposes "reputation services". It needs more words about
>>>> whether those exist, and what scopes the architecture imagines (an
>>>> enterprise might have a different idea of a reputation service than a
>>>> residence). There is a notion of "decent web reputations" in the security
>>>> considerations section. Who determines that? The security considerations
>>>> section should talk about attacks against the reputation services.
>>>> I think there needs to be more discussion of the PKI used for signing MUD
>>>> files.
>>>  
>>
>> While this section is admittedly a bit vague, we need some
>> operational experience to develop the appropriate use of PKI as an
>> anchor for reputations.  This having been said, if you have a
>> specific proposal for text, I'd be interested in what you have to say.
> Do you envision enterprises or manufacturers creating a new set of
> anchors of trust, or are you hoping to reuse the web PKI or something
> else? If you don't know and all of these are on the table, mentioning
> it would help implementers avoid assumptions that could hinder deployment.

Thanks for the guidance.   In fact I think we need to more clearly
specify the signature in terms of the purpose.  The tools (openssl)
support S/MIME signing easily enough for CMS.  I think this is what we
want, and it implies that we are *not* using the webpki, but instead
just getting an S/MIME certificate.  This implies that the signers will
have to be "admitted" on first sight.  Would that work for you?

Also see below.


>>
>>>> Consider discussing whether the stacks used by typical things will let
>>>> them add DHCP options (or include bits in the other protocols being 
>>>> enabled). If it's well known (I can't say) that these stacks typically
>>>> _won't_ provide that functionality, then you should punch up the
>>>> discussion of the controllers mapping other identifiers to MUD URLs on
>>>> behalf of the thing.
>>
>> We did indeed add some text about this, almost verbatim to what you
>> have above (I think at your suggestion).  This can be found in the
>> introduction toward the bottom of page 9.
> I'm not seeing it in -20. Maybe its in your working copy but not
> issued yet, or 9 above isn't where you meant to point? I did a quick
> search for DHCP through the document and didn't spot the discussion.
> Apologies if I'm just missing it.

Actually it's in two places.  See where we say in Section 1.5:

   It is possible that there may be other means for a MUD URL to be
   learned by a network.  For instance, some devices may already be
   fielded or have very limited ability to communicate a MUD URL, and
   yet can be identified through some means, such as a serial number or
   a public key.  In these cases, manufacturers may be able to map those
   identifiers to particular MUD URLs (or even the files themselves).
   Similarly, there may be alternative resolution mechanisms available
   for situations where Internet connectivity is limited or does not
   exist.  Such mechanisms are not described in this memo, but are
   possible.  Implementors should allow for this sort of flexibility of
   how MUD URLs may be learned.

Elsewhere we say:

   If a MUD controller is not able to fetch a MUD URL, other means MAY
   be used to import MUD files and associated signature files.  So long
   as the signature of the file can be validated, the file can be used.
   In such environments, controllers SHOULD warn administrators when
   cache-validity expiry is approaching so that they may check for new
   files.

So I'm hoping between the two we have you covered ;-).

More below.

>
>>>  
>>>> You suggest the DHCP Client (which is a thing) SHOULD log or report 
>>>> improper acknowledgments from servers. That's asking a bit much from
>>>> a thing. I suspect the requirement is unrealistic and should be removed
>>>> or rewritten to acknowledge that things typically won't do that.
>>
>> I propose to delete that paragraph to match that we do not wish DHCP
>> servers to modify their state.  This would address your concern (also
>> see below).
> ack
>>
>>>  
>>>> The security and deployment considerations sections talk about what the
>>>> need for coordination if control over the domain name used in the URL
>>>> changes. It should talk more about what happens if the new administration
>>>> of the domain is not interested in facilitating a transition (consider
>>>> the case of a young company with a few thousand start-up-ish things out
>>>> there that loses a suit over its name). Please discuss whether or not
>>>> suddenly losing the MUD assisted network configuration is expected to
>>>> leave the devices effectively cut-off. 
>>
>> The example you are talking about is a subset of what happens if the
>> file simply doesn't exist.  At worst, one is left in a situation no
>> worse than we are today: that is, someone will have to manually
>> decide policy, or apply a default policy.  This particular text is
>> the subject of separate piece of work that Thorsten Dahm and Steve
>> Rich are considering, and it is also the subject of some ongoing
>> research.  That is to say: we might be able to do better in the
>> future when we have some operational experience.
> OK. I suppose the detail I was hoping to see was some insight into
> recovery (how my hypothetical company above could start providing new
> MUD files that the existing devices would be convinced to use). I'll
> accept that is "future work".

Ok,
>>
>>
>>>  
>>>> 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?
>>
>> Ok, two issues:
>>
>>  1. There was some text that should have been removed, referring to
>>     the DHCP server returning the MUD-URL as part of state.  With
>>     everyone's permission, I propose to remove that text.  No
>>     additional DHCP server state should be required to implement this
>>     option.
>>  2. I agree that we could be a bit more descriptive about what would
>>     happen if a reboot of the DHCP server.  I also like your idea
>>     about mentioning the lease time to the MUD controller.  With that
>>     in mind, how about the following text:
>>
>>
>> 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.
>>
>>
> wfm - thanks
>>>  
>>> Nits:
>>>
>>> There is tension between the paragraph in the introduction that characterizes
>>> the manufacturer as the entity that provides the mud file and the third bullet
>>> in the intent list about speeding vulnerability resolution for devices that
>>> are no longer supported by the manufacturer (you intend here that someone other
>>> than the original manufacturer or integrator is providing a new mud file).
>>
>> Perhaps this is best fixed by dropping the phrase "by the manufacturer"?
> ok
>>
>>> Instead of "A light bulb is intended to light a room.", I suggest 
>>> "A light bulb is intended to light a given space." (There are lightbulbs
>>> meant for outdoor use, and others for only inside cabinets or appliances.)
>>
>> Ok.
>>
>>> Instead of "We make use of YANG because of the time and effort spent to develop
>>> accurate..." I suggest "We make use of YANG because it provides accurate..."
>>
>> Ok.
>>> At the end of section 1.7, instead of "For these reasons only a limited subset
>>> YANG-based configuration is permitted in a MUD file.", I suggest "For these
>>> reasons, the YANG-based configuration in a MUD file is limited to the YANG
>>> modules defined in this document." or something similar.
>> s/defined/specified/ but otherwise ok.

Just one clarification- this text needed to be wordsmithed a little bit
more.  Keep in mind that the ACL model is supported as discussed in the
draft.

>>
>>> In section 3.6, the parenthesized clause does not belong in the sentence in 
>>> which it currently appears. I suggest it belongs somewhere in the previous
>>> sentence.
>>
>> I've removed it and rewritten as follows:
>>
>> The intent is for administrators to be able to see a
>> brief displayable description of the Thing.
> ok
>>
>>> In section 3.13 you talk about classes that are standardized. Where does 
>>> someone find out about standardized classes?
>>
>> They're described in the document
> Ah. maybe in 3.13 you could say "classes standardized by this document
> or future RFCs"?

Ahh!  ok.  I see the confusion.  I think an example may be appropriate
here (we are literally getting a lot of operational experience with this
day by day now).

Suppose you have a manufacturer X who has products P, D, and Q.  They
each want to talk to the same controller or group of controllers.  Use
of "my-controller" may invoke a process on a MUD controller that
requires that the administrator populate the class for each device P, D,
and Q.  Whereas with use of a controller class, the administrator only
has to populate the class once.

Similarly, the use of the word standardized naked like that is probably
unhelpful.  One could imagine, for instance, Fairhair or some other
consortium deciding to create standard classes.

What I propose is two changes to facilitate better understanding:

 1. To include the simple example described above.
 2. To add an optional "documentation"  element in the "mud" container
    that consists of a URL that points to documents for each class, when
    so used.

Thoughts?

Eliot