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

From: Adam Roach <[email-masked]>
Date: Wed, 18 Apr 2018 22:36:38 -0700

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.

---------------------------------------------------------------------------

§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)

---------------------------------------------------------------------------

§1.7:

>  JSON is used as a serialization for compactness and readability,

Perhaps cite RFC 7159 here?

---------------------------------------------------------------------------

§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.

---------------------------------------------------------------------------

§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.

(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?

---------------------------------------------------------------------------

§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?

---------------------------------------------------------------------------

§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. My understanding so far is that the
Thing will provide a URL that points to the MUD file. Inside this MUD file is a
"mud-signature" that points to the signature discussed in this section. So, to
get to the MUD signature, the MUD controller has to first retrieve the MUD file.
But the text above says that it SHOULD retrieve the signature before it
retrieves the MUD file.

How?

---------------------------------------------------------------------------

§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.

---------------------------------------------------------------------------

§16.4:

>   o Security considerations: See Security Considerations
>     of this document.

Ideally, this would also cite RFC 7159, section 12.

---

From: Adam Roach <[email-masked]>
Date: Thu, 19 Apr 2018 02:50:05 -0500

> Perhaps cite RFC 7159 here?

Ugh. Of course I meant  RFC 8259. Sorry for the extra noise.

/a

---

From: Eliot Lear <[email-masked]>
Date: Thu, 19 Apr 2018 11:39:48 +0200

Hi Adam,

> https://datatracker.ietf.org/doc/draft-ietf-opsawg-mud/

I propose to include this change.

ACK

Now 8259.

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.

Good catch!
> (This applies to three other locations in the document as well)

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?

> Should this final field be a MUD URL? Or should it be the (extensible)

Leftover.  Good catch.  Changed to MUDString.
> 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.

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?

> Ideally, this would also cite [[RFC 8259]], section 12.
>
>
>

So edited in my copy.

Thanks!

Eliot

---

From: Adam Roach <[email-masked]>
Date: Thu, 19 Apr 2018 10:51:19 -0500

> operational experience could provide us guidance between MAY and SHOULD.

My experience includes situations such as Microsoft officially 
discontinuing support of Windows XP in 2014, and yet releasing a 
security patch for it last year. While this is exceptional, it's not 
unheard of. If you want to define "support" to mean something in this 
document other than the way major vendors do, I suggest including a 
clear definition in this document, as readers are likely to make the 
same inferences as I did.

/a

---

From: Eliot Lear <[email-masked]>
Date: Thu, 19 Apr 2018 18:04:44 +0200

Ok, I'll work on it.