|
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.
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.
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".
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:
- 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.
- 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.
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"?
Micro-nits:
"Our work begins with" in section 1.5 is awkward and I suspect will cause
problems if this document is translated into other languages.
If you *know* this to be a problem, I will make a change.
I can't demonstrate a problem.
At "======= The MUD URL identifies" in section 5, I suggest deleting the =
signs.
I believe this is corrected.
Please provide a reference or better description for "so-called east-west
infection""
I'll change this to "lateral infection (infection of devices that
reside near one another)".
ok
The string "enorcement" appears a couple of times in the models. It is intended
to be "enforcement".
Thanks for catching these.
And thank you again for the quick response.
|
