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
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 iswhat 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 <lear@xxxxxxx> 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
last-call@xxxxxxxx
https://www.ietf.org/mailman/listinfo/last-call
_______________________________________________ Suit mailing list Suit@xxxxxxxx https://www.ietf.org/mailman/listinfo/suit
-- last-call mailing list last-call@xxxxxxxx https://www.ietf.org/mailman/listinfo/last-call
