Re: [secdir] Secdir early review of draft-ietf-opsawg-mud-08

Adam Montville <adam.w.montville@gmail.com> Tue, 29 August 2017 18:50 UTC

Return-Path: <adam.w.montville@gmail.com>
X-Original-To: secdir@ietfa.amsl.com
Delivered-To: secdir@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CEFCF1326EC; Tue, 29 Aug 2017 11:50:30 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.698
X-Spam-Level:
X-Spam-Status: No, score=-2.698 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.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 Q0eZNgiQBKDd; Tue, 29 Aug 2017 11:50:28 -0700 (PDT)
Received: from mail-it0-x22e.google.com (mail-it0-x22e.google.com [IPv6:2607:f8b0:4001:c0b::22e]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 15AC013248B; Tue, 29 Aug 2017 11:50:28 -0700 (PDT)
Received: by mail-it0-x22e.google.com with SMTP id o132so4502536itc.1; Tue, 29 Aug 2017 11:50:28 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=1L15XunAXfD0LcRaF4p9Zt64Uw3nYwWAboSpb1hQCJo=; b=uh9eidmszsQMfP4IQQex37GLSKejdH547DSjbsRWfnwcMvaKh8dvZIwD9WyrNvy9vP YrszY1c1tA+dUIFTibEh77xhciBeGS3tfT5rGK4o3DTKC7+/oDR3p18VmAaYhlU7VE0p Di5boZ422Nd3K5Ox6BkXXi+7aY520O4020AOKzGLUvODLlsEoffit7R2NHFbuNpHiaH7 H1i5uwDtt6o3qLWsivL4/j880D3fB3yR7TkuQyneNQFGuT9g4Ess1mHqno+SiUpyJ3lj P+kKJ0hCUnsML1lFdZ2xs0IBS1sTpm2RJvlnFIdqcs2TovemyC6eCiksTS8UOH5aZgzF s3hw==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=1L15XunAXfD0LcRaF4p9Zt64Uw3nYwWAboSpb1hQCJo=; b=FmgJrh6aqe3V4CGOMPZg63lpSzyCCTOtAD4tlSgA0VKTT99NMAXNaKlF013mkBR4HB ZxT9tehB+SrMrNomMyK9jGi1TuEp125f34yxbm+6YWjna+Smsa6fZwhsjnzn4N/CPbHN 1Sdj3Xp42TAMM+SCO3V5HeEQ/3hQcWnn0DCL9AS5uSlX0kMo5+yG/yeHy/Y8iKv+DzaE J+flKyCEVwBVn7FnpZywKdV5pd4uEM0eJ6eF35LcjFzN7b67FaG53e+vtcLhh5LDjv4R VgMuIePFX6oHB7s51PdrjwBEZ5pHSbPLJ2ErRyxoxqYGWfizFV5pynvTlsJFwgc3LvZ+ q1/w==
X-Gm-Message-State: AHYfb5gHXL032zM6vT+TfG3VT9PeR2t4hIZ3EE0va1DBvnIFiYHgu33z yENV5CRBRdrgCi+Q6AoJ5ONSBZLwMw==
X-Received: by 10.36.249.67 with SMTP id l64mr3371819ith.66.1504032627122; Tue, 29 Aug 2017 11:50:27 -0700 (PDT)
MIME-Version: 1.0
References: <150384057895.866.9675653302394719026@ietfa.amsl.com> <bea3e871-bc5c-38f8-4027-44c3559afad1@cisco.com>
In-Reply-To: <bea3e871-bc5c-38f8-4027-44c3559afad1@cisco.com>
From: Adam Montville <adam.w.montville@gmail.com>
Date: Tue, 29 Aug 2017 18:50:15 +0000
Message-ID: <CACknUNVFJjs4y+tLr7Ks0LO9x-XTx9VLZZqVK8-jA9Cf-NFTOQ@mail.gmail.com>
To: Eliot Lear <lear@cisco.com>, secdir@ietf.org
Cc: draft-ietf-opsawg-mud.all@ietf.org, opsawg@ietf.org, ietf@ietf.org
Content-Type: multipart/alternative; boundary="94eb2c0475707864dc0557e8e2c4"
Archived-At: <https://mailarchive.ietf.org/arch/msg/secdir/rNAE0wO4HizM64c9_UptYK87GGY>
Subject: Re: [secdir] Secdir early review of draft-ietf-opsawg-mud-08
X-BeenThere: secdir@ietf.org
X-Mailman-Version: 2.1.22
Precedence: list
List-Id: Security Area Directorate <secdir.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/secdir>, <mailto:secdir-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/secdir/>
List-Post: <mailto:secdir@ietf.org>
List-Help: <mailto:secdir-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/secdir>, <mailto:secdir-request@ietf.org?subject=subscribe>
X-List-Received-Date: Tue, 29 Aug 2017 18:50:31 -0000

Hi Eliot,

You're welcome. Thanks for taking the time to consider, and even implement
some of, my feedback.

I agree on the hardware rooted trust for software intended use. Seems
plausible, given work coming out of TCG. I'm sure there are others who may
find this train of thought interesting.

Kind regards,

Adam

On Tue, Aug 29, 2017 at 1:31 PM Eliot Lear <lear@cisco.com> wrote:

> Hi Adam,
>
> Thanks very much for your review.  I'm pleased you like the general
> approach.  You hit the nail on the head: this is NOT intended to be a
> panacea, but a means by which the device (and its manufacturer) can
> enlist the network's protection. Indeed as I mentioned the first time I
> presented to SAAG, I will say now again (with feeling):
>
> NOTHING in that draft nor anywhere ELSE should excuse a
> manufacturer/developer from best coding practices and updating
> software.  The best form of protection will ALWAYS ALWAYS be a well
> secured device to begin with.
>
> MUD is simply there to add an additional layer for when the hacker gets
> there first...
>
> Please now see below.
>
>
> On 8/27/17 3:29 PM, Adam Montville wrote:
> >
> > Finally, I found myself wondering if this type of appraoch -
> communicating
> > intended use - could be extended to software installed on general purpose
> > devices. For example, it would be interesting to consider how a given
> installed
> > software package could communicate not only its intended use, but it's
> > preferred configuration.
>
> I'd very much like to pursue this concept, but it seems to me it has to
> be rooted in some sort of hardware trust.
>
> >
> > Some questions to consider (these are potential issues):
> >
> > At the top of page 9, the draft describes controller behavior for mobile
> > devices - configurations should be removed when the device is removed.
> Does
> > this apply also to intermittent devices?
> Well indeed so.  I think the discussion around mobility is confusing.
> I've cleaned that up.
>
> > When would a device be considered
> > "removed" instead of simply powered down?
>
> I think the best way to look at this is to view the configuration
> information as ephemeral, and since the device provides the information
> on connect, or otherwise periodically (eg LLDP), you can regenerate the
> state.
>
> >  Also, when reading that paragraph I
> > began wondering about the load on Web servers serving MUD files - not
> that this
> > draft should say anything about it, but that it's something
> manufacturers are
> > going to have to consider and account for.
> Right.
> >
> > Is a stronger statement needed on the first bullet of section 4? Should
> it
> > read: Anything not explicitly permitted MUST be denied? Similarly for
> other
> > requirements in MUD file processing. At about this point, I began
> wondering if
> > additional security considerations may be required for the controller.
>
> One of the principles we try to observe is that the administrator owns
> the network.  As such we should be somewhat cautious about how we phrase
> such things.  From a MUD perspective, what you end up with is an
> access-list that an administrator might choose to augment.  For
> instance, if he or she is running a special load on a Thing using
> 802.1AR certificates, he might want to augment the access to accommodate
> a new feature.
>
> In fact, it may be possible that a manufacturer writes such a complex
> MUD file that the network administrator desires an optimization.  We do
> not yet have enough experience to know what sort of normative statement
> would cover that ;-)
>
> >
> > Section 9.2 describes DHCP server behavior, and is written in a manner
> > presuming the DHCP server knows what's happening with these building
> blocks. I
> > am not a DHCP expert, so there may be something in DHCP instructing a
> server to
> > ignore everything it doesn't understand, but if that is not the case,
> then what
> > is expected to happen when DHCP is not expecting these options and is
> not going
> > to ignore them?
>
> This is not a worry.  DHCP servers are very capable of ignoring unknown
> options, and they have to be well bullet proofed today or we have FAR
> FAR bigger fish to fry ;-)
> >
> > Nits follow:
> >
> > First paragraph of section 1.5: s/another example might to follow/another
> > example might be to follow/
> Right!
> >
> > Recommend the following for definition of Thing: the device emitting a
> MUD URL.
>
> Ok.
> >
> > Suggest striking last two sentences of Manufacturer definition, as
> irrelevant.
>
> Ahhh but this actually is a big deal to system integrators ;-)  They
> want to know what their role in the ecosystem is.
>
> >
> > Is there a way to make the ASCII art in section 1.7 a little cleaner? One
> > possibility is to move the right side of the bounding box to the left by
> two or
> > three places.
>
> Sure.  Done.
> > Also, the arrows to the line text isn't necessary (e.g.
> > "----->get URL->" is cleaner as "---get URL--->").
>
> Done.
> >
> > Second bullet on page 11: s/other otherwise/otherwise/
>
> right.
> > Should there be a newline after "<CODE BEGINS>" at the start of section
> 6?
>
> I'm going to leave that one to the YANG doctors...
> >
> > On page 17: s/end(ed)/end(s\/ed)/  Basically, the sentence without
> "ended"
> > should read, "Information about when support ends, and when to refresh."
>
> This will change with the updating of the model, based on YANG doctor
> feedback.  That very container is likely to be consolidated away.
> >
> > Vertial spacing could be improved for the first bit in section 9, so
> that the
> > look/feel surrounding OPTION_MUD_URL_V4 matches that of OPTION_MUD_URL_v6
>
> Ok.  I think I addressed what you're talking about.
> >
> > Section 11, first sentence: s/link layer protocols/link layer protocol/
> >
> >
>
> Good catch.
>
> Best regards and thanks again for your review.
>
> Eliot
>
>