Re: [OPSAWG] Adam Roach's Yes on draft-ietf-opsawg-mud-20: (with COMMENT)

Eliot Lear <lear@cisco.com> Thu, 19 April 2018 09:39 UTC

Return-Path: <lear@cisco.com>
X-Original-To: opsawg@ietfa.amsl.com
Delivered-To: opsawg@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2F21D12D7EA; Thu, 19 Apr 2018 02:39:55 -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, RCVD_IN_DNSWL_HI=-5, SPF_PASS=-0.001, T_DKIMWL_WL_MED=-0.01, 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 B-CRfNrZTCna; Thu, 19 Apr 2018 02:39:52 -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 039E4124C27; Thu, 19 Apr 2018 02:39:51 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=7407; q=dns/txt; s=iport; t=1524130792; x=1525340392; h=subject:to:cc:references:from:message-id:date: mime-version:in-reply-to; bh=S39XzRbN2CXIORsqaAR1rT7Ta8HQKfIqc2AwdsH9Vk4=; b=gcOiVRglaXu+ze2o4Y7fn7C3noRM1SXwcSbRdH8ENjUr21E2uXAQZQVe ujvS4doflpu2BhsaOVp6ltRfZlpjqKI2Wn2iPckAH3XPZ6+3oC/k4kVxW I0wmDefoBIpTKqYmHucXy7FhXwgNczF4x9wkFsQKy21GLg7al+xa2VOtV c=;
X-Files: signature.asc : 488
X-IronPort-AV: E=Sophos; i="5.48,468,1517875200"; d="asc'?scan'208"; a="3230082"
Received: from aer-iport-nat.cisco.com (HELO aer-core-1.cisco.com) ([173.38.203.22]) by aer-iport-3.cisco.com with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384; 19 Apr 2018 09:39:49 +0000
Received: from [10.61.210.190] ([10.61.210.190]) by aer-core-1.cisco.com (8.14.5/8.14.5) with ESMTP id w3J9dmgJ004514; Thu, 19 Apr 2018 09:39:49 GMT
To: Adam Roach <adam@nostrum.com>, The IESG <iesg@ietf.org>
Cc: draft-ietf-opsawg-mud@ietf.org, Joe Clarke <jclarke@cisco.com>, opsawg-chairs@ietf.org, opsawg@ietf.org
References: <152411619849.28688.7728428588690184834.idtracker@ietfa.amsl.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: <3b3a9137-ad74-6516-ec26-760b41078d50@cisco.com>
Date: Thu, 19 Apr 2018 11:39:48 +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: <152411619849.28688.7728428588690184834.idtracker@ietfa.amsl.com>
Content-Type: multipart/signed; micalg=pgp-sha256; protocol="application/pgp-signature"; boundary="LBcLU0wyLqkun2lEfAG8x1OQmQ1AQBsYf"
Archived-At: <https://mailarchive.ietf.org/arch/msg/opsawg/t5pLdcAu8-8uBBxKEF7x5RJiXdI>
Subject: Re: [OPSAWG] Adam Roach's Yes on draft-ietf-opsawg-mud-20: (with COMMENT)
X-BeenThere: opsawg@ietf.org
X-Mailman-Version: 2.1.22
Precedence: list
List-Id: OPSA Working Group Mail List <opsawg.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/opsawg>, <mailto:opsawg-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/opsawg/>
List-Post: <mailto:opsawg@ietf.org>
List-Help: <mailto:opsawg-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/opsawg>, <mailto:opsawg-request@ietf.org?subject=subscribe>
X-List-Received-Date: Thu, 19 Apr 2018 09:39:55 -0000

Hi Adam,


On 19.04.18 07:36, Adam Roach wrote:
> Adam Roach has entered the following ballot position for
> draft-ietf-opsawg-mud-20: Yes
>
> When responding, please keep the subject line intact and reply to all
> email addresses included in the To and CC lines. (Feel free to cut this
> introductory paragraph, however.)
>
>
> Please refer to https://www.ietf.org/iesg/statement/discuss-criteria.html
> for more information about IESG DISCUSS and COMMENT positions.
>
>
> The document, along with other ballot positions, can be found here:
> https://datatracker.ietf.org/doc/draft-ietf-opsawg-mud/
>
>
>
> ----------------------------------------------------------------------
> COMMENT:
> ----------------------------------------------------------------------
>
> I would like to thank everyone who worked on this document, and the authors in
> particular for clear, easy-to-read prose. The described mechanism seems quite useful.
>
> ---------------------------------------------------------------------------
>
> §1.3:
>
>>  The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
>>  "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
>>  document are to be interpreted as described in [RFC2119].
> This document also uses lowercase forms of these words. Consider using the
> boilerplate from RFC 8174.

I propose to include this change.
>
> ---------------------------------------------------------------------------
>
> §1.6:
>
>>  Section 5.3.2) containing "application/mud+json", an "Accept-
>>  Language" header ([RFC7231], Section 5.3.5), and a "User-Agent"
>>  header ([RFC7231], Section 5.5.3).
> s/header/header field/ (three times)

ACK
>
> ---------------------------------------------------------------------------
>
> §1.7:
>
>>  JSON is used as a serialization for compactness and readability,
> Perhaps cite RFC 7159 here?

Now 8259.

>
> ---------------------------------------------------------------------------
>
> §3.5:
>
>>  A MUD controller MAY still periodically check for updates.
> I'm surprised to see this as a "MAY" rather than a "SHOULD." For example, even
> an unsupported device may be the subject of a CERT security advisory, and the
> manufacturer would presumably (if possible) take whatever mitigating steps would
> make sense.

I think this is definitional.  The idea in the preceding text really is
that once the vendor sets this, they really have no intention of
updating even CERT-based issues.  This is another instance where
operational experience could provide us guidance between MAY and SHOULD.
>
> ---------------------------------------------------------------------------
>
> §8:
>
>>                    "ietf-acldns:src-dnsname": "test.com",
> The domain "test.com" is registered by an entity known as TESTCOM Inc. It's
> probably best to avoid its use in an example. I would propose "test.example.org"
> or something else reserved by RFC 6761.

Good catch!
>
> (This applies to three other locations in the document as well)
>
> ---------------------------------------------------------------------------
>
> §9:
>
>>   reserved = 1*( CHAR ) ; from [RFC5234]
> Is there a reason to restrict this to be only 7 bits?

It's mostly fear of the unknown.  We don't know how this stuff will be
carried.  But since the URL can be 8 bits wide, I suppose this issue
will have to be solved anyway, so.... OCTET then?

>
> ---------------------------------------------------------------------------
>
> §11:
>
>>  The LLDP vendor specific frame has the following format:
>>
>>  +--------+--------+----------+---------+--------------
>>  |TLV Type|  len   |   OUI    |subtype  | MUD URL
>>  |  =127  |        |= 00 00 5E|  = 1    |
>>  |(7 bits)|(9 bits)|(3 octets)|(1 octet)|(1-255 octets)
>>  +--------+--------+----------+---------+--------------
> Should this final field be a MUD URL? Or should it be the (extensible)
> MUDstring defined in §9?

Leftover.  Good catch.  Changed to MUDString.
>
> ---------------------------------------------------------------------------
>
> §12.2:
>
>>  Prior to retrieving a MUD file the MUD controller SHOULD retrieve the
>>  MUD signature file by retrieving the value of "mud-signature" and
>>  validating the signature across the MUD file.
> I'm really confused about how this works. 

Propose changed to... "Prior to processing the rest of the MUD file..." 
Earlier versions of the draft had an implicit file for the signature. 
We changed that based on feedback from mnot, but this text didn't get
caught.


> ---------------------------------------------------------------------------
>
> §12.2:
>
> I'm surprised to see no discussion in here of duration of signature validity. I
> presume these will typically be cached by the MUD controller.

I think the choices here are limited, and in particular, if a device is
set to unsupported and the signature becomes invalid, you don't want to
just delete the policy.  The same thing occurs if you don't have
Internet connectivity and can't refresh easily.  Deleting the policy
would violate principle of least astonishment.  Should we say that?

>
> ---------------------------------------------------------------------------
>
> §16.4:
>
>>   o Security considerations: See Security Considerations
>>     of this document.
> Ideally, this would also cite [[RFC 8259]], section 12.
>
>
>

So edited in my copy.

Thanks!

Eliot