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

[Hannes Tschofenig <[e-mail]>]

Thanks for your review, Behcet. I have addressed also your comments with
version -07.

FWIW there is still another update coming based on the following PR:

https://github.com/bremoran/suit-mud/pull/8


Ciao

Hannes


Am 26.12.2023 um 18:00 schrieb Behcet Sarikaya:
> 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
>
>
> _______________________________________________
> Suit mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/suit