Re: [Last-Call] Opsdir last call review of draft-ietf-suit-mud-06

[Behcet Sarikaya <[e-mail]>]

Folks,
It seems like Ref -07 of suit-mud draft is out. I read it, it resolves my
issues. I think, maybe the takeaway from Sue's review is
what Eliot said:
We don't have a YANG model for the MUD manager itself with operational
state.  I think that might be a possible next step.

Regards,
Behcet
On Thu, Dec 21, 2023 at 5:50 AM Eliot Lear <[e-mail]> wrote:

> We don't have a YANG model for the MUD manager itself with operational
> state.  I think that might be a possible next step.
> On 21.12.2023 12:06, Hannes Tschofenig wrote:
>
> Hi Eliot,
>
>
> thanks for the quick response.
>
>
> That's good to hear but I haven't read how any error cases are reported to
> some central device management system to take some actions.
>
> Is that functionality documented somewhere as well? For example, some YANG
> modules for use with Netconf?
>
>
> Ciao
>
> Hannes
>
>
> Am 21.12.2023 um 11:35 schrieb Eliot Lear:
>
> Hi Hannes and thanks Sue
>
> The MUD Manager always has the responsibility to "consider the source" and
> then to consider the context.  The information provided in MUD files *can
> *be used to automate access control to their associated devices.  I think
> this is pretty well covered in RFC 8520, but I am starting to think about
> an update to that document.
>
> Eliot
> On 21.12.2023 11:08, Hannes Tschofenig wrote:
>
> Hi Susan,
>
> thanks for your detailed review.
>
> You are correct that this document does not address operational aspects of
> the MUD Manager and this is certainly something the OPSAWG working group
> should address since this document is a tiny extension to the already
> existing MUD RFC. Along these lines you are also correct that the document
> does not define any mechanism for the MUD Manager to notify the operator
> about any error situations with the processing of MUD files and/or SUIT
> manifests. I will reach out to Eliot and the OPSAWG working group to think
> about standardization work in this direction.
>
> I have updated the draft to better explain how the different URIs are
> passed around. I also added a figure to illustrate it graphically.
> Attestation Evidence, which is used to convey information about the MUD
> URL, also allows the network to double-check the firmware/software (and
> other properties of the device). We didn't go into any details about how
> Evidence is processed because this is part of different documents, like the
> RATS architecture RFC. I hope the updated text clarified these aspects.
>
> Regarding the CDDL I had a chat with Brendan and we will make an update.
>
> Ciao
> Hannes
>
>
> Am 04.12.2023 um 16:19 schrieb Susan Hares via Datatracker:
>
> Reviewer: Susan Hares
> Review result: Has Issues
>
> Overall comment:
> Qualifications: I am not an expert on SUIT implementations or an operator
> of
> networks using SUIT. Therefore, my issues may be covered by some general
> security considerations in a document I am not aware of.
>
> General comments to authors:  This feature is clearly described in this
> document. Brendan and Hannes did an excellent job of writing the document.
>
> Security/Operational Issues:
>
> The security of MUD URLs may move the attacks from individual devices to
> the
> MUD Manager. (Instead of a single lemming going over the cliff, a MUD
> manager
> may send many lemmings over the cliff). This document does not seem to
> consider
> the operational issues in the MUD Manager or provide mechanisms on how to
> check
> for these attacks (e.g. Yang modules with operational state).
>
> 1. An Attack on the MUD Manager can shut down or subvert the entire
> network.
>
> It is not clear how the operator knows an attack on the MUD Manager is
> happening
> or occurred. If the MUD Manager pulls in broken SUIT manifests and
> then pulls in broken software/firmware based on the SUIT manifests
> how does the operator know?  In other words what device watches
> that the MUD Manager is not subverted via a management protocol?
>
> I do not see any operational state in the MUD Yang module [RFC8620 section
> 2.1]
> It would seem natural to have some operational state in the MUD Manager
> reports
> manifest state. Yang's notif protocols could report any manifest state
> change
> (over secure TLS connections) to a centralized security server.
>
> 2. For secure URLs transmitted by 802.1X with certificates,
> Why are these not a "double-check" on the validity of the software?
>
> Again, it would seem natural to utilize these secure certificates as
> "double-checks" on the MUD Manager being "in-sync"  with the devices.
>
> 3. As a less secure double-check on being "in-sync", is the reporting of
>   MUD URL sent via MUD Devices via DHCP or LLDAP that is not what is in
> the
>   manifest.
>
> These reporting features are useful in transition scenarios as well as
> detecting attacks on the MUD manager.
>
> Editorial nits:
>
> 1. section 1, last paragraph, sentence 2
>
> Old text: /can get/
> New text: /has/
>
> English grammar
>
> 2. Just for my sanity, would you check the following text is correct
>
> $$SUIT_severable-members-extensions //= (
>    suit-manifest-mud => bstr .cbor SUIT_MUD_container
> )
> It appears you are looking to define a CBOR Type for the
> the SUIT_MOD_container is defined in the text.
>
> What I think I'm missing is the .cbor value for SUIT.
> It looks correct, but I could  not derive this from
> draft-ietf-suit-manifest-24:
>
> SUIT_Severable_Manifest_Members = (
>    ? suit-payload-fetch => bstr .cbor SUIT_Command_Sequence,
>    ? suit-install => bstr .cbor SUIT_Command_Sequence,
>    ? suit-text => bstr .cbor SUIT_Text_Map,
>    * $$SUIT_severable-members-extensions,
> )
>
> And your IANA definitions of:
>
> IANA is requested to add a new value to the SUIT envelope elements
> registry
> created with [I-D.ietf-suit-manifest]: Label: TBD2 [[Value allocated from
> the
> standards action address range]]
>
> Name: Manufacturer Usage Description (MUD)
> Reference: [[TBD: This document]]
>
> Again, this may be due to my incomplete understanding.
> This is why this is a NIT rather than an Issue.
>
>
>
>
> --
> last-call mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/last-call
>