[core] Re: Gorry Fairhurst's No Objection on draft-ietf-core-oscore-groupcomm-27: (with COMMENT)

[Marco Tiloca <[e-mail]>]

Hello Gorry,

Thanks a lot for your review! Please find in line below our detailed replies to your comments.

A GitHub PR where we have addressed your comments is available at [PR].

Unless any concern is raised, we plan to soon merge this PR (and the other ones related to other received reviews) and to submit the result as version -28 of the document.

Thanks,
/Marco

[PR] https://github.com/core-wg/oscore-groupcomm/pull/119

________________________________
From: Gorry Fairhurst via Datatracker <[e-mail]>
Sent: Tuesday, September 30, 2025 3:22 PM
To: The IESG <[e-mail]>
Cc: [e-mail] <[e-mail]>; [e-mail] <[e-mail]>; [e-mail] <[e-mail]>; [e-mail] <[e-mail]>; [e-mail] <[e-mail]>
Subject: Gorry Fairhurst's No Objection on draft-ietf-core-oscore-groupcomm-27: (with COMMENT)

Gorry Fairhurst has entered the following ballot position for
draft-ietf-core-oscore-groupcomm-27: No Objection

When responding, please keep the subject line intact and reply to all
email addresses included in the To and CC lines. (Feel free to cut this
introductory paragraph, however.)


Please refer to https://eur05.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww.ietf.org%2Fabout%2Fgroups%2Fiesg%2Fstatements%2Fhandling-ballot-positions%2F&data=05%7C02%7Cmarco.tiloca%40ri.se%7C3d28a1b4096b406cc92208de00247796%7C5a9809cf0bcb413a838a09ecc40cc9e8%7C0%7C0%7C638948353777334108%7CUnknown%7CTWFpbGZsb3d8eyJFbXB0eU1hcGkiOnRydWUsIlYiOiIwLjAuMDAwMCIsIlAiOiJXaW4zMiIsIkFOIjoiTWFpbCIsIldUIjoyfQ%3D%3D%7C0%7C%7C%7C&sdata=Zv34U0iibrhIUghyNszat4YLYZow0ptBGcQc25dvIcM%3D&reserved=0<https://www.ietf.org/about/groups/iesg/statements/handling-ballot-positions/>
for more information about how to handle DISCUSS and COMMENT positions.


The document, along with other ballot positions, can be found here:
https://eur05.safelinks.protection.outlook.com/?url=https%3A%2F%2Fdatatracker.ietf.org%2Fdoc%2Fdraft-ietf-core-oscore-groupcomm%2F&data=05%7C02%7Cmarco.tiloca%40ri.se%7C3d28a1b4096b406cc92208de00247796%7C5a9809cf0bcb413a838a09ecc40cc9e8%7C0%7C0%7C638948353777362913%7CUnknown%7CTWFpbGZsb3d8eyJFbXB0eU1hcGkiOnRydWUsIlYiOiIwLjAuMDAwMCIsIlAiOiJXaW4zMiIsIkFOIjoiTWFpbCIsIldUIjoyfQ%3D%3D%7C0%7C%7C%7C&sdata=ovz%2B1ZhWiQ6pfpX7dqH4uMnBKajKMlbRGedjRAgTH9o%3D&reserved=0<https://datatracker.ietf.org/doc/draft-ietf-core-oscore-groupcomm/>



----------------------------------------------------------------------
COMMENT:
----------------------------------------------------------------------

Thanks for preparing this document and thanks also to Joerg Ott for his
heplfpul TSV-ART review.

1) I include one topic here from the TSV-ART with an additional question:

Section 12.2, 2nd para states that "when possible, the delivery of rekeying
messages should use a reliable transport [...]"

This seems to suggest that an unreliable -- and possibly non-congestion
controlled -- transport is fine, too.  This appears risky if rapid membership
changes occur or are suggested in some way as this could cause floods of
rekeying messages.  Especially since (4th para), "The Group Manager MUST rekey
the group without undue delay when one or more endpoints leave the group."

An additional question: Is this a SHOULD use a reliable transport?
----

==>MT

Irrespective of the transport being reliable or unreliable, congestion control must always be ensured. This is already stated later in the same paragraph and now made even more explicit by addressing the next comment (see below).

Some group key management schemes might well use unreliable transports. For example, they can rely on rekeying messages sent to multiple/all group members at once, e.g., over UDP and IP multicast. In fact, this is in the interest of sending less rekeying messages than when targeting group members individually, thus limiting the rekeying traffic and completing the rekeying faster. In turn, it limits the fundamentally unavoidable impact of group key management operations in case of rapid membership changes.

In practice, the possible use of a reliable transport is limited to messages targeting a single recipient, and using a normative SHOULD is excessive and undesirable. In fact, for applications using Group OSCORE (hence most likely CoAP over UDP and IP multicast), it is expected that key management operations also rely on CoAP over UDP, with some group key management schemes further relying on UDP over IP multicast for (some of) their messages.

In the interest of clarity, we have made the following rephrasing.

OLD
> When possible, the delivery of rekeying messages should use a reliable transport, in order to reduce chances of group members missing a rekeying instance.

NEW
> Different group key management schemes rely on different approaches to compose and deliver rekeying messages, i.e., individually targeting single recipients, or targeting multiple recipients at once (e.g., over UDP/IP multicast), or a combination of the two approaches. As long as it is viable for the specific rekeying message to be delivered and it is supported by the intended message recipient(s), using a reliable transport to deliver a rekeying message should be preferred, as it reduces chances of group members missing a rekeying instance.

<==


2) In the following:
/The use of an
   unreliable transport MUST NOT forego enforcing congestion control as
   appropriate for that transport./

(a) Could this be rewritten as a requirement as something like:
/A transport (reliable or unreliable) MUST enforce appropriate congestion
control./ (b) I am content with the requirement, but it would be better if this
requirement also pointed to some examples where this was satisfied in other
documents.

==>MT

Regarding (a), yes, with a slightly different formulation:

> Irrespective of the transport used being reliable or unreliable, appropriate congestion control MUST be enforced.

Regarding (b), this is also related to the suggestion from Joerg Ott in his follow-up archived at https://mailarchive.ietf.org/arch/msg/core/28VfZG7V3R4fn54743X1N_K1528/

Overall, we have made the rephrasing below, adding RFC 4340, RFC 9000, and RFC 9002 as informative references.

OLD
> The use of an unreliable transport MUST NOT forego enforcing congestion control as appropriate for that transport.

NEW
> Irrespective of the transport used being reliable or unreliable, appropriate congestion control MUST be enforced. If the key distribution traffic uses CoAP over UDP or over other unreliable transports, mechanisms for enforcing congestion control are specified in Section 4.7 of [RFC7252] and in Section 3.6 of [I-D.ietf-core-groupcomm-bis] for the case of group communication (e.g., over UDP/IP multicast). If, irrespective of using CoAP, the key distribution traffic relies on alternative setups with unreliable transports, one can rely on general congestion-control mechanisms such as DCCP [RFC4340], or on dedicated congestion control mechanisms for the transport specifically used (e.g., those defined in [RFC9002] for QUIC [RFC9000]).

<==