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

[Eliot Lear <[e-mail]>]

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.
>>>>
>>>>
>>>>
>>>