Re: [Mud] [Last-Call] Opsdir last call review of draft-ietf-suit-mud-06 (fwd) Hannes Tschofenig: Re: [Last-Call] Opsdir last call review of draft-ietf-suit-mud-06

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
last-call@ietf.org
https://www.ietf.org/mailman/listinfo/last-call