Strong Assertions of IoT Network Access Requirements
draft-ietf-suit-mud-08

[Ballot comment]
Thank you, Roman and WG, for adding an Update: meta-data to the document + the explanations on the timeline for this 'cluster' of MUD I-Ds.

Thanks also for your patience as the revised I-D was submitted when I was in pre-IETF holidays and I am only now back to work.

-éric

[Ballot comment]
Thanks for this document.

I to am supporting Erik and Rob in their discusses, though I have no fundamental issues with the protocol per say.

[Ballot comment]
Comments from incoming ART AD, Orie Steele:

> Only the developer can attest the communication requirements of the device.

^ is this sentence using the word attestation in accordance with 9334 ?

> or as part of other interactions that involve the conveyance of Evidence to the operational network.

it might be preferable to repeat the RATS terms you are using, in terminology.

> Devices can be quarantined if they do not attest a known software/firmware version.

^ perhaps include the word evidence here?

> To accomplish the transport of the manifest Evidence is used, which needs to be available at the protocol of choice.

reads awk.

There is no normative definition of URL, but there should be probably.

Noting several normative references to drafts.

[Ballot comment]
Thanks for this document. I have just a couple of nit-level comments:

- "communication pattern are described" should be "patterns are" or "pattern is" depending on your intent (which I can't divine).

- Is "Serverdig" a typo, or...?

[Ballot discuss]
Thank you for the work on this document.

This is a DISCUSS to flag an action item for the IESG (no action required from authors or wg): RFC 9334 is a downref in this document, but it was added after IETF Last Call, so it was not Last Called. IESG should approve it during the telechat.

[Ballot comment]
Thanks for working on this specification. No objection from transport protocol point of view.

I am supporting Eric's and Rob's discuss. I also found it a bit odd that we are already extending a yet to be specified specification, can't this wait?.

Besides, I have following comments which I believe would improve the readability of the document when addressed -

  # Elaborate SUIT at it's first occurrence in the document.
 
  # What is a MUD URL? yes, a reference to RFC 8520 would be necessary, otherwise, I would need to ask how do you encode the URL, and it's internationalization factors.

  # We would need to know about the "other MUD URL reporting mechanism" to actually understand the pros and cons. Where to we find them?

[Ballot comment]
Thanks for working on this specification.

I am supporting Eric's and Rob's discuss. I also found it a bit odd that we are already extending a yet to be specified specification, can't this wait?.

Besides, I have following comments which I believe would improve the readability of the document when addressed -

  # Elaborate SUIT at it's first occurrence in the document.
 
  # What is a MUD URL? yes, a reference to RFC 8520 would be necessary, otherwise, I would need to ask how do you encode the URL, and it's internationalization factors.

  # We would need to know about the "other MUD URL reporting mechanism" to actually understand the pros and cons. Where to we find them?

[Ballot comment]
Thank you for this document.

Also, thank you to Susan Hares for the OpsDir review, and for the followup discussions.

I'd like to support Robert and Eric's DISCUSS positions, especially the "This seems more like an ops thing than a security thing."

[Ballot discuss]
Hi,

Thanks for this document.

I've flagged the below issue as a discuss mostly because I think that it would be useful to have a brief discussion with the authors on whether this is an issue and whether the document should include more text.

(1) p 7, sec 6.  Security Considerations

  This specification links MUD files to SUIT manifests for improving
  security protection and ease of use.  By including MUD URLs in SUIT
  manifests an extra layer of protection has been created and
  synchronization risks can be minimized.  If the MUD file and the
  software/firmware loaded onto the device gets out-of-sync a device
  may be firewalled and, with firewalling by networks in place, the
  device may stop functioning.

The second sentence is included in the security considerations, but I wasn't really sure that this wasn't more of an operational consideration and hence might be better places in a separate "Operational Considerations" section of the document.

Is there any workaround or mitigation for this issue?  I.e., I still remember when Samsung managed to brick many of their Bluray players through a bad OTA update (which eventually required the devices to be returned to Samsung to be fixed).

I.e., it feels like having the MUD file being accessed by a URL is a good idea, since that means that it can be subsequently updated if it turns out to be wrong, but this only helps if there is a mechanism to ensure that the MUD file will be retrieved again.  Are such mechanisms in place and documented?

Regards,
Rob

[Ballot discuss]
# Éric Vyncke, INT AD, comments for draft-ietf-suit-mud-07

Thank you for the work put into this document.

Please find below one blocking DISCUSS points (easy to address and mostly to have a discussion at the IESG on one point), some non-blocking COMMENT points (but replies would be appreciated even if only for my own education), and one nit.

Special thanks to Russ Housley for the shepherd's detailed write-up including the WG consensus _but it lacks_ the justification of the intended status and as indicated by id-nits RFC 9334 is a downward reference even if the write-up includes `There are no downward normative references.`. Not a big deal though.

Please note that Michael Richardson is the IoT directorate reviewer (at my request) and you may want to consider this iot-dir review as well when it will be available (no need to wait for it though):
https://datatracker.ietf.org/doc/draft-ietf-suit-mud/reviewrequest/18682/

I hope that this review helps to improve the document,

Regards,

-éric


# DISCUSS (blocking)

As noted in https://www.ietf.org/blog/handling-iesg-ballot-positions/, a DISCUSS ballot is a request to have a discussion on the following topics:

## Section 5

It is merely a discuss-discuss in order to force some discussions during the telechat (or before) on the process here. I intend to ballot YES or ABSTAIN after the discussion.

The text `The SUIT_Envelope is also amended` seems to indicate that this I-D updates an *existing and published* RFC, while SUIT_Envelope appears to be specified in appendix A of draft-ietf-suit-manifest, i.e., a yet to be published document.

It is weird to ballot on an I-D modifying a yet-to-be-balloted document. And at the minimum, a meta-data of "update" seems to be required.

[Ballot comment]

# COMMENTS (non-blocking)

## Reference or inclusion

From my reading and understanding of this document, the MUD & SUIT files are generated by the same organisation. Is there any reason why the MUD file is not included into the SUIT manifest rather than via a reference ? Is it only to save smaller attestation ? If so, then the reader will probably welcome an explanation.

## Section 1

Should RFC 8520 already be referred to in the first paragraph ?

Should there be informative references to DHCP and LLDP ? As in section 1.5 of RFC 8520.

`an authentic copy of the MUD file` should there be "latest copy" ? Or is it enough to rely on MUD last-update & cache-validity ?

Should 'likely' be removed from `In case of DHCP and LLDP the URL is likely unprotected` ?

Even if draft-ietf-suit-manifest is a normative reference (i.e., this I-D will wait until draft-ietf-suit-manifest is approved) I would have preferred to have to review first draft-ietf-suit-manifest then this one. A matter of taste, no need to reply.

# NITS (non-blocking / cosmetic)

## Abstract

`The MUD description` the "D" in MUD also stands for "description".

(Via drafts-lastcall@iana.org): IESG/Authors/WG Chairs:

IANA has completed its review of draft-ietf-suit-mud-06. If any part of this review is inaccurate, please let us know.

IANA understands that, upon approval of this document, there are two actions which we must complete.

IANA understands that both of the actions requested in the IANA Considerations section of this document are dependent upon the approval of and completion of IANA Actions in another document, draft-ietf-suit-manifest, which has not yet entered Last Call.

First, in the SUIT Manifest Elements Registry, to be created on the approval of and completion of IANA Actions in another document, draft-ietf-suit-manifest, a single new registration will be made as follows:

Label: [ TBD-at-Registration ] [[Value allocated from the standards action address range]]
Name: Manufacturer Usage Description (MUD)
Reference: [ RFC-to-be ]

Second, in the SUIT Envelope Elements registry, another registry to be created on the approval of and completion of IANA Actions in another document, draft-ietf-suit-manifest, a single registration will be made as follows:

Label: [ TBD-at-Registration ] [[Value allocated from the standards action address range]]
Name: Manufacturer Usage Description (MUD)
Reference: [ RFC-to-be ]

We understand that these two actions are the only ones required to be completed upon approval of this document.

NOTE: The actions requested in this document will not be completed until the document has been approved for publication as an RFC. This message is meant only to confirm the list of actions that will be performed.

For definitions of IANA review states, please see:

https://datatracker.ietf.org/help/state/draft/iana-review

Thank you,

David Dong
IANA Services Sr. Specialist

The following Last Call announcement was sent out (ends 2023-11-14):

From: The IESG
To: IETF-Announce
CC: draft-ietf-suit-mud@ietf.org, housley@vigilsec.com, rdd@cert.org, suit-chairs@ietf.org, suit@ietf.org
Reply-To: last-call@ietf.org
Sender:
Subject: Last Call:  (Strong Assertions of IoT Network Access Requirements) to Proposed Standard


The IESG has received a request from the Software Updates for Internet of
Things WG (suit) to consider the following document: - 'Strong Assertions of
IoT Network Access Requirements'
  as Proposed Standard

The IESG plans to make a decision in the next few weeks, and solicits final
comments on this action. Please send substantive comments to the
last-call@ietf.org mailing lists by 2023-11-14. Exceptionally, comments may
be sent to iesg@ietf.org instead. In either case, please retain the beginning
of the Subject line to allow automated sorting.

Abstract


  The Manufacturer Usage Description (MUD) specification describes the
  access and network functionality required for a device to properly
  function.  The MUD description has to reflect the software running on
  the device and its configuration.  Because of this, the most
  appropriate entity for describing device network access requirements
  is the same as the entity developing the software and its
  configuration.

  A network presented with a MUD file by a device allows detection of
  misbehavior by the device software and configuration of access
  control.

  This document defines a way to link a SUIT manifest to a MUD file
  offering a stronger binding between the two.




The file can be obtained via
https://datatracker.ietf.org/doc/draft-ietf-suit-mud/



No IPR declarations have been submitted directly on this I-D.

Shepherd Write-up for draft-ietf-suit-mud-04


(1) What type of RFC is being requested (BCP, Proposed Standard, Internet
Standard, Informational, Experimental, or Historic)?  Why is this the
proper type of RFC?  Is this type of RFC indicated in the title page
header?

  Proposed Standard.  Yes, the header calls for a Standards Track RFC.


(2) The IESG approval announcement includes a Document Announcement
Write-Up.  Please provide such a Document Announcement Write-Up.  Recent
examples can be found in the "Action" announcements for approved
documents.  The approval announcement contains the following sections:

  Technical Summary:

  The Manufacturer Usage Description (MUD) specification describes the
  access and network functionality required a device to properly
  function.  The MUD description has to reflect the software running on
  the device and its configuration.  Thus, an appropriate entity for
  describing device network access requirements the the software developer.

  A network presented with a MUD file by a device allows detection of
  misbehavior by the device software and configuration of access
  control.

  This document defines a way to link a SUIT manifest to a MUD file
  offering a stronger binding between the two.

  Working Group Summary:

  There is consensus for this document in the SUIT WG.
   
  Personnel:

  Russ Housley is the document shepherd.
  Roman Danyliw is the responsible area director.


(3) Briefly describe the review of this document that was performed by
the Document Shepherd.  If this version of the document is not ready for
publication, please explain why the document is being forwarded to the
IESG.

  The document shepherd did a thorough review of the document during
  WG Last Call.  All issues that were raised during WG Last Call have
  been resolved.  However, there were few comments on the document even
  though there was strong consensus in the WG that inclusion of the MUD
  file in the SUIT Manifest was a good idea.


(4) Does the document Shepherd have any concerns about the depth or
breadth of the reviews that have been performed?

  No concerns.


(5) Do portions of the document need review from a particular or from
broader perspective, e.g., security, operational complexity, AAA, DNS,
DHCP, XML, or internationalization?  If so, describe the review that took
place.

  No concerns.


(6) Describe any specific concerns or issues that the Document Shepherd
has with this document that the Responsible Area Director and/or the IESG
should be aware of?  For example, perhaps he or she is uncomfortable with
certain parts of the document, or has concerns whether there really is a
need for it.  In any event, if the WG has discussed those issues and has
indicated that it still wishes to advance the document, detail those
concerns here.

  No concerns.


(7) Has each author confirmed that any and all appropriate IPR
disclosures required for full conformance with the provisions of BCP 78
and BCP 79 have already been filed.  If not, explain why?

The authors have explicitly stated that all known IPR has been
disclosed.


(8) Has an IPR disclosure been filed that references this document?  If
so, summarize any WG discussion and conclusion regarding the IPR
disclosures.

  There are no IPR disclosures against this document.


(9) How solid is the WG consensus behind this document?  Does it
represent the strong concurrence of a few individuals, with others being
silent, or does the WG as a whole understand and agree with it?

  There is strong consensus for the inclusion of a MUD file in the SUIT
  Manifest.  However, the number of people that spoke during the WG
  Last Call was pretty slim.


(10) Has anyone threatened an appeal or otherwise indicated extreme
discontent?  If so, please summarise the areas of conflict in separate
email messages to the Responsible Area Director.  (It should be in a
separate email because this questionnaire is publicly available.)

  No one has threatened an appeal.


(11) Identify any ID nits the Document Shepherd has found in this
document.  (See http://www.ietf.org/tools/idnits/ and the Internet-Drafts
Checklist).  Boilerplate checks are not enough; this check needs to be
thorough.

  There is a non-ASCII character in the text file, which is in the author's
  name of a referenced document.


(12) Describe how the document meets any required formal review criteria,
such as the MIB Doctor, media type, and URI type reviews.

  No special reviews are needed.  CBOR experts have looked at the very
  simple syntax in Section 5.


(13) Have all references within this document been identified as either
normative or informative?

  All of the references are normative.


(14) Are there normative references to documents that are not ready for
advancement or are otherwise in an unclear state?  If such normative
references exist, what is the plan for their completion?

  No.


(15) Are there downward normative references references (see RFC 3967)?
If so, list these downward references to support the Area Director in the
Last Call procedure.

  There are no downward normative references.


(16) Will publication of this document change the status of any existing
RFCs?  Are those RFCs listed on the title page header, listed in the
abstract, and discussed in the introduction?  If the RFCs are not listed
in the Abstract and Introduction, explain why, and point to the part of
the document where the relationship of this document to the other RFCs is
discussed.  If this information is not in the document, explain why the
WG considers it unnecessary.

  No.


(17) Describe the Document Shepherd's review of the IANA considerations
section, especially with regard to its consistency with the body of the
document.  Confirm that all protocol extensions that the document makes
are associated with the appropriate reservations in IANA registries.
Confirm that any referenced IANA registries have been clearly identified.
Confirm that newly created IANA registries include a detailed
specification of the initial contents for the registry, that allocations
procedures for future registrations are defined, and a reasonable name
for the new registry has been suggested (see RFC 5226).

  Section 7 describes assignments in one existing IANA registry.


(18) List any new IANA registries that require Expert Review for future
allocations.  Provide any public guidance that the IESG would find useful
in selecting the IANA Experts for these new registries.

  No new IANA regestries are requested.


(19) Describe reviews and automated checks performed by the Document
Shepherd to validate sections of the document written in a formal
language, such as XML code, BNF rules, MIB definitions, etc.

  None are needed.

Shepherd Write-up for draft-ietf-suit-mud-04


(1) What type of RFC is being requested (BCP, Proposed Standard, Internet
Standard, Informational, Experimental, or Historic)?  Why is this the
proper type of RFC?  Is this type of RFC indicated in the title page
header?

  Proposed Standard.  Yes, the header calls for a Standards Track RFC.


(2) The IESG approval announcement includes a Document Announcement
Write-Up.  Please provide such a Document Announcement Write-Up.  Recent
examples can be found in the "Action" announcements for approved
documents.  The approval announcement contains the following sections:

  Technical Summary:

  The Manufacturer Usage Description (MUD) specification describes the
  access and network functionality required a device to properly
  function.  The MUD description has to reflect the software running on
  the device and its configuration.  Thus, an appropriate entity for
  describing device network access requirements the the software developer.

  A network presented with a MUD file by a device allows detection of
  misbehavior by the device software and configuration of access
  control.

  This document defines a way to link a SUIT manifest to a MUD file
  offering a stronger binding between the two.

  Working Group Summary:

  There is consensus for this document in the SUIT WG.
   
  Personnel:

  Russ Housley is the document shepherd.
  Roman Danyliw is the responsible area director.


(3) Briefly describe the review of this document that was performed by
the Document Shepherd.  If this version of the document is not ready for
publication, please explain why the document is being forwarded to the
IESG.

  The document shepherd did a thorough review of the document during
  WG Last Call.  All issues that were raised during WG Last Call have
  been resolved.  However, there were few comments on the document even
  though there was strong consensus in the WG that inclusion of the MUD
  file in the SUIT Manifest was a good idea.


(4) Does the document Shepherd have any concerns about the depth or
breadth of the reviews that have been performed?

  No concerns.


(5) Do portions of the document need review from a particular or from
broader perspective, e.g., security, operational complexity, AAA, DNS,
DHCP, XML, or internationalization?  If so, describe the review that took
place.

  No concerns.


(6) Describe any specific concerns or issues that the Document Shepherd
has with this document that the Responsible Area Director and/or the IESG
should be aware of?  For example, perhaps he or she is uncomfortable with
certain parts of the document, or has concerns whether there really is a
need for it.  In any event, if the WG has discussed those issues and has
indicated that it still wishes to advance the document, detail those
concerns here.

  No concerns.


(7) Has each author confirmed that any and all appropriate IPR
disclosures required for full conformance with the provisions of BCP 78
and BCP 79 have already been filed.  If not, explain why?

The authors have explicitly stated that all known IPR has been
disclosed.


(8) Has an IPR disclosure been filed that references this document?  If
so, summarize any WG discussion and conclusion regarding the IPR
disclosures.

  There are no IPR disclosures against this document.


(9) How solid is the WG consensus behind this document?  Does it
represent the strong concurrence of a few individuals, with others being
silent, or does the WG as a whole understand and agree with it?

  There is strong consensus for the inclusion of a MUD file in the SUIT
  Manifest.  However, the number of people that spoke during the WG
  Last Call was pretty slim.


(10) Has anyone threatened an appeal or otherwise indicated extreme
discontent?  If so, please summarise the areas of conflict in separate
email messages to the Responsible Area Director.  (It should be in a
separate email because this questionnaire is publicly available.)

  No one has threatened an appeal.


(11) Identify any ID nits the Document Shepherd has found in this
document.  (See http://www.ietf.org/tools/idnits/ and the Internet-Drafts
Checklist).  Boilerplate checks are not enough; this check needs to be
thorough.

  There is a non-ASCII character in the text file, which is in the author's
  name of a referenced document.


(12) Describe how the document meets any required formal review criteria,
such as the MIB Doctor, media type, and URI type reviews.

  No special reviews are needed.  CBOR experts have looked at the very
  simple syntax in Section 5.


(13) Have all references within this document been identified as either
normative or informative?

  All of the references are normative.


(14) Are there normative references to documents that are not ready for
advancement or are otherwise in an unclear state?  If such normative
references exist, what is the plan for their completion?

  No.


(15) Are there downward normative references references (see RFC 3967)?
If so, list these downward references to support the Area Director in the
Last Call procedure.

  There are no downward normative references.


(16) Will publication of this document change the status of any existing
RFCs?  Are those RFCs listed on the title page header, listed in the
abstract, and discussed in the introduction?  If the RFCs are not listed
in the Abstract and Introduction, explain why, and point to the part of
the document where the relationship of this document to the other RFCs is
discussed.  If this information is not in the document, explain why the
WG considers it unnecessary.

  No.


(17) Describe the Document Shepherd's review of the IANA considerations
section, especially with regard to its consistency with the body of the
document.  Confirm that all protocol extensions that the document makes
are associated with the appropriate reservations in IANA registries.
Confirm that any referenced IANA registries have been clearly identified.
Confirm that newly created IANA registries include a detailed
specification of the initial contents for the registry, that allocations
procedures for future registrations are defined, and a reasonable name
for the new registry has been suggested (see RFC 5226).

  Section 7 describes assignments in one existing IANA registry.


(18) List any new IANA registries that require Expert Review for future
allocations.  Provide any public guidance that the IESG would find useful
in selecting the IANA Experts for these new registries.

  No new IANA regestries are requested.


(19) Describe reviews and automated checks performed by the Document
Shepherd to validate sections of the document written in a formal
language, such as XML code, BNF rules, MIB definitions, etc.

  None are needed.