[core] Re: draft-ietf-core-groupcomm-bis-14 ietf last call Tsvart review

[Magnus Westerlund <[e-mail]>]

Hi,

Thanks for this detailed email. Very clarifications and good suggestions and I have seen that they have been incorporated into -15. I am sorry that I didn’t see this email when it was sent it, I will blame my email filtering setup.

I sent a follow up review where I marked this document as READY from my perspective.

Thanks for addressing my comments.

Magnus Westerlund

From: Esko Dijk <[e-mail]>
Date: Tuesday, 9 September 2025 at 21:53
To: Magnus Westerlund <[e-mail]>
Cc: [e-mail] <[e-mail]>, [e-mail] <[e-mail]>, [e-mail] <[e-mail]>, [e-mail] <[e-mail]>
Subject: Re: [core] draft-ietf-core-groupcomm-bis-14 ietf last call Tsvart review
Hello Magnus, (cc: tsv-art, core)

Thanks for your review of the groupcomm-bis draft! We're currently working on text updates based on the reviews so far.
Before we make changes based on your comments, we wanted to check if you agree with the proposed resolutions: see the author's comments inline below, marked with "[A]".
On 29-7-2025 13:21, Magnus Westerlund via Datatracker wrote:

Document: draft-ietf-core-groupcomm-bis

Title: Group Communication for the Constrained Application Protocol (CoAP)

Reviewer: Magnus Westerlund

Review result: Ready with Issues



This document has been reviewed as part of the transport area review team's

ongoing effort to review key IETF documents. These comments were written

primarily for the transport area directors, but are copied to the document's

authors and WG to allow them to address any issues raised and also to the IETF

discussion list for information.



When done at the time of IETF Last Call, the authors should consider this

review as part of the last-call comments they receive. Please always CC

[e-mail]<mailto:[e-mail]> if you reply to or forward this review.



First of all I will note that this publication is moving a specification from

Experimental to Proposed Standard thus a higher bar for robustness in

congestion control and security issue mitigation is to me reasonable and to be

expected.



General:

So what multicast models are really supported by this specification? To my

reading it appears focused on Any Source Multicast, and Source Specific

Multicast (RFC4607) does not work as the unicast responses are sent to the

source address of the multicast packet containing the COAP request. I think it

would be good to be clearer on these limitations. To me it is unclear if a

forward proxy would work as an interface and the specific source for a SSM

group. Some clarification on this would be good.
[A] The intended scope and focus is indeed Any Source Multicast (ASM), while Source Specific Multicast (SSM) is not really considered for constrained/IoT applications.
In RFC 7390, this was said explicitly in Section 1.2.
This explicit scope statement was probably removed again during editing because we didn't (and still don't) see any fundamental problem using SSM with CoAP multicast.

There are, however, some practical issues like the CoAP server being required to know the IP address of the CoAP client (source). So this would require some text on how sources are discovered in constrained/IoT applications.
And for the proxy case, the source address of the proxy would be required to know instead of the original client's address.
But we don’t want the document to go into such details, since we don’t currently anticipate constrained/IoT use cases making use of SSM. To make that clear, an explicit scope statement would be good.

We propose the following update in Section 1.1:

OLD
This document defines UDP/IP multicast as the default transport protocol for CoAP group requests, as in [RFC7252]. Other transport protocols …

NEW (emphasis mine)
This document defines UDP/IP multicast as the default transport protocol for CoAP group requests, as in [RFC7252]. Only the Any Source Multicast (ASM) mode [RFC5110] of IP multicast operation is in scope. Other transport protocols …

The reference to RFC 5110 is normative, like it is in RFC 7390.



I think there are several areas where this document is taking way to much an

toolbox approach rather than being descriptive on what is normative to

implement and use for particular use cases and deployments. This especially in

relation to security mitigations. There are a lot of things mentioned in the

security conisderations that I think should be normatively required to be

supported and implemented to ensure secure deployment of groupcomm. Examples of

this includes mitigation of amplification attacks. Also the use of NoSec mode

should be stated early on the draft basically as an application statement for

this mode. To my understanding NoSec is extremely limited and that should be

made clear up front.

[A] The mentioned “toolbox approach” is mostly intended: CoAP has diverse applications with different requirements. For example when used in satellites vs a home door sensor on a wireless mesh network.

Specifically about the example on mitigation of amplification attacks, Section 6.3 “Risk of Amplification” in the security considerations does include normative requirements to mitigate such attacks. Are particular mitigations missing, or do we need to make more clear that there are normative requirements in 6.3 by providing a forward pointer from earlier sections?

About the NoSec mode: as we understand from your comment, the following could be highlighted earlier in the text:

* The “NoSec” mode provides no secure communication and message protection at all.
* The “NoSec” mode is discouraged and is deemed acceptable/unavoidable only in a few, very specific cases. Hence, its use is generally NOT RECOMMENDED. Only after serious considerations and understanding, is its use “opt-in” in particular circumstances, as enabled through a specific application statement.

Currently, the first two occurrences of the term “NoSec” are:

1. In Section 1.3 “Changes to Other Documents”
2. in Section 2.1.3 “Security Group”

We can make the following update in section 1 “Introduction”, by extending the third from last paragraph:

OLD
Both unsecured and secured CoAP group communication are specified in this document. …

NEW (emphasis mine)
Both unsecured and secured CoAP group communication are specified in this document. Unsecured group communication relies on the NoSec mode, whose use is strongly discouraged and is limited to specific cases (see Section 4).

We consider adding some text also in Section 2.1.3 “Security Group”, within the fifth paragraph already mentioning the “NoSec” mode:

> If the NoSec mode is used (see Section 4), …

However, this paragraph already explains that there’s no security in this mode and provides the forward pointer to Section 4, which in turn provides the specific cases/limitations of NoSec.
Section 4 also provides forward references to Sections 6.1 and 6.3 for the details, e.g. explanations of why NoSec can be used in the initial-discovery use case.
So it seems that this could be already sufficiently clear in Section 2.1.3, without adding further text.

Would the above work for you?





Section 3.1.3

Request repetition is proposed of two different types but it is unclear how a

client should be able to determine that the loss happened on the client to

server, vs server to client path. Shouldn't at least one of the methods be the

recommended one, like using the same token value and message ID that can be

suppressed on server side?



[A] So there is the loss on the “client to server path”, which is the multicast request CoAP message, and the “server to client path”, which is the unicast CoAP response message. For completeness: in case the server decides to (i.e., it is programmed/configured to) send a Confirmable (CON) CoAP response back to the client, there’s also the CoAP Ack message on the “client to server path” which may be lost.

In most cases, the client is not able to understand what exactly has happened, i.e., whether the group request hasn’t reached some servers or whether only the responses sent by those servers (if any) have been lost. In general, the client may not even know how many responses to expect and/or whether those servers are suppressing their responses.

About recommending one of the two methods, we have had some discussion: our conclusion was that it is up to the client, i.e. the client’s implementer, to select a method that fits the particular use case, if the client wishes to make such a selection. The selection can be even deployment-specific, or differ per-resource.

In case the client “doesn’t care” or the developer of the client is not aware of this possibility of having a choice in the first place, then the client would fall back (automatically) to a default method. The default method is what the base CoAP RFC specifies by default for this case, and what a CoAP stack implementation would do by default, which is to send a Non-Confirmable (NON) message only once and not repeat the message with the same Message ID (MID) multiple times.

See Section 4.3 of RFC 7252:

A sender MAY choose to transmit multiple copies of a Non-confirmable message within MAX_TRANSMIT_SPAN …

This repeating of the same NON message with the same Message ID is not something that a CoAP stack implementation would likely do by default: it would have to be explicitly configured or requested. Some CoAP stacks may not even offer the option of repeatedly sending the same message: it’s optional, after all, and we have no intention to change that.

We assume that the most common method of repeating a NON request (e.g., invoked if no answer comes within a certain time) would be for the higher layer application to resend the same request again via the CoAP stack API. In this case, the request message would get sent with a different MID value because it’s treated as a new request, causing a new message from the CoAP stack point of view.

So the second method would be the “default” one, we think. Do you think that this is a good direction?



Section 3.6:

I guess the general principle described is the simplest that gives some

back-off. However, I think more guidance are needed on both the variables used

in computing the lb_leisure value as well as the default values PROBING_RATE

and DEFAULT_LEISUIRE.



It is a bit unfortunate that the protocol setup results in it being difficult

for any endpoint to judge the server group size. Thus it needs to be

configured. Response size (S) could be estimated based on sent responses. The

data transfer rate given to groupcomm responses (R) appear to be needs

configuration. Also which level of load factor is deemed acceptable in relation

to link speeds? Some one configuring a whole system needs to take into account

all the different application groups here.



I think there are also potential to discuss the issue of client request rates.

I assume that there exist both deployments when the client is not also a server

and thus (I guess) is not part of the multicast group, as well as where it is a

member. If the client is a multicast member it could actually attempt to judge

the current request rate and based on that determine if it can send the

request. Unfortunately an individual client struggles to determine if the

multicast group or unicast response somewhere leads to overload.

[A] We agree that more and clearer guidance around the CoAP variables and lb_Leisure computation can be given.

For what it’s worth, Section 3.6 is silently and largely inheriting the body of recommendations defined for CoAP group communication in Section 8.2 of RFC 7252, which we didn’t want to re-explain.

A few considerations and suggestions on how to improve Section 3.6 of this document:

  *   We can recap the existence and meaning of the parameters NSTART, PROBING_RATE, and DEFAULT_LEISURE; and the expression/formula lb_Leisure from Section 8.2 of RFC 7252.
  *   On computing lb_Leisure, the only difference compared to RFC 7252 seems the estimated response size S. With the recommended use of Group OSCORE, protected responses are larger in size than their plain versions, due to the CoAP OSCORE Option and the larger protected CoAP payload.

In turn, this is greatly affected by: i) a response being protected with the group mode or the pairwise mode of Group OSCORE; ii) specific actions that the server originating the response takes when protecting a response with Group OSCORE (e.g., including the “Partial IV” field or the “kid context” field in the OSCORE option).

About a server computing the lb_Leisure value for itself, the server cannot know how exactly other servers are going to protect their responses. However, the guidelines below can apply.

When the group mode is used, it’s safe to assume a minimum overhead due to Group OSCORE equal to 76 bytes (3 bytes of CoAP OSCORE Option including its own 1-byte header, the flag byte, and a 1-byte “kid” field; CoAP payload enlarged by 1+8+64 bytes, i.e., encrypted REST code, the smallest integrity tag, and the counter signature). This can easily go up to 90 or 100 bytes, e.g., if an encryption algorithm with a 16-byte integrity tag is used, and the OSCORE option also includes the “Partial IV” field, the “kid context” field, and a larger “kid” field.

When the pairwise mode is used, it’s safe to assume a minimum overhead due to Group OSCORE equal to 10 bytes (1 byte of empty CoAP OSCORE Option thus including only its own 1-byte header; CoAP payload enlarged by 1+8 bytes, i.e., encrypted REST code and smallest integrity tag). This can easily go up to 30 bytes, e.g., if an encryption algorithm with a 16-byte integrity tag is used, and the OSCORE option also includes the “Partial IV” field, the “kid context” field, and a larger “kid” field.

Given that RFC 7252 conservatively considers S equal to 100 bytes, we can say that, when Group OSCORE is used as recommended, S is conservatively considered to be 200 bytes if the OSCORE group is set to (also) use the group mode, and to 130 bytes otherwise (i.e., if it is set to use only the pairwise mode). In either case, a more accurate setting of S depends on the exact setting and use of Group OSCORE in the group.

Using these values of S in the formula to compute the lower bound of lb_Leisure in Section 8.2 of RFC 7252, and using the same example values for G and R, the worst case is modeled by a lower bound of:

     *   20 seconds, if the OSCORE group is set to (also) use the group mode.
     *   13 seconds, it the OSCORE group is set to use only the pairwise mode.

  *   Following-up on the previous point and building on the same “halving-rationale” in Section 8.2 of RFC 7252, the suggested DEFAULT_LEISURE can be:

     *   10 seconds, if the OSCORE group is set to (also) use the group mode.
     *   6.5 seconds, it the OSCORE group is set to use only the pairwise mode.

  *   As to PROBING_RATE, we think that we can still keep 1 byte/second as defined in Section 4.8 of RFC 7252. We can explicitly state that the same default value applies here.
  *   As to NSTART, we can clarify/correct RFC 7252 on the below text in Section 4.7 of 7252. This text defines NSTART in terms of one given CoAP server, however for the purpose of CoAP group communication a group request sent to a group of multiple servers would still count as 1 for the NSTART limit. I.e. it’s about the number of simultaneous outstanding interactions to a given IP multicast address, not a given server as written in 7252:

In order not to cause congestion, clients (including proxies) MUST
strictly limit the number of simultaneous outstanding interactions
that they maintain to a given server (including proxies) to NSTART.

  *   Like in Section 4.8.1 of RFC 7252, we can also explicitly state that, also for CoAP group communication:

… DEFAULT_LEISURE (…) and PROBING_RATE may be configured to values specific to the application environment (including dynamically adjusted values); however, the configuration method is out of scope of this document.

  *   Yes, appropriately configuring these parameters is not simple, might require their re-configuration over time, and has to take into account all the application groups and CoAP groups that are set up.
  *   Yes, a client might be client-only, hence not a member of a CoAP group to which it sends group requests over multicast. But even if the client is also a server, hence a member of a CoAP group, that client cannot really “attempt to judge the current request rate and based on that determine if it can send the request”.

In general, there is a high chance that such a judgment is in fact based on wild guesses, due to the unpredictable behavior of other endpoints sending messages. That is, even by considering the recently monitored network activities, a client is hardly in the position to reliably determine a possible upcoming traffic overload.

For example, there may be significant activity on the network due to other protocols than CoAP group communication, or to/from members of other CoAP groups that the server is not aware of.

Instead, it is better to rely on explicitly configured values (if possible) or otherwise default values for the already existing parameters from RFC 7252 to be used for enforcing congestion control when group communication is used.

Our proposal is to add a new Section 3.6.1 that focuses on Leisure (as part of Section 3.6 “Congestion Control”). This new section can include an example for an IEEE 802.15.4 / 6LoWPAN based network; and present the new lb_Leisure / DEFAULT_LEISURE values as calculated above.

Would the above work for you?



Section 3.7:

Rate limiting observation notificatitons. So per RFC 7641 there are some

recommendations for congestion control of the Obersvation notification. What I

can determine from reviewing RFC 7641 Section 4.5.1 and RFC 7252 Section 4.7

the number of outstanding or non-confirmable notifications  is NSTAT and for

the later NSTAT will be 1. The issue I see with this is that with the groupcomm

a client can request notifications from all servers in the application group.

If the resource that is observed is something that will be synchronized across

a large group of server a feedback implosion can be generated. Thus my question

is if the sending of observation notification when the request has been

received over groupcomm should default to use a random backoff time to attempt

to smear out the notifications over time.

[A] Currently, Observe notifications sent in response to a request received over GroupComm are already governed by the leisure period as discussed above and defined in Section 8.2 of RFC 7252.

Highlighting the relevant part with emphasis:

The server SHOULD then pick a random point of time within the chosen leisure period to send back the unicast response to the multicast request. If further responses need to be sent based on the same multicast address membership, a new leisure period starts at the earliest after the previous one finishes.

In the draft, we could clarify that an Observe notification (e.g., the second or third one sent by a server, etc.) is a specific example of a “further response” as defined in this quote. So each notification always gets its own leisure period and all leisure intervals related to a particular multicast group address need to be non-overlapping, as specified in the highlighted sentence.
So, the leisure random delay is applied 10 times in sequence, when for example 10 different clients have to be notified, if these 10 clients were subscribed via a request using the same IP multicast group address.

Such a statement/clarification could be made in Section 3.6 or in a new Section 3.6.1 “Leisure” that we proposed also earlier in this mail.

Note that the above applies to all types (NON/CON) of notifications. Most often, observe notifications are Non-Confirmable. As per Section 4.5 of RFC 7641, a server has to intersperse those with notifications sent as a Confirmable message. For the Confirmable notifications, there’s a random backoff time based on the CoAP retransmission algorithm - applied only to retransmissions of the original CON response. In this case the retransmissions are different messages but are the same response, so the Leisure interval will not be applied again for each retransmission - only the CoAP retransmission random backoff time will be applied in this case.

Would the above work for you? And should the explanation of the previous paragraph be clarified in the draft, or would that be obvious to a reader?


(Section 3.7)

I believe that there is an overload attack possible using this mechanism. An

attacker sends an Oberserve requet for a resource that exists on a large number

of servers in the application group. This request has a spoofed address of the

target of the attack. When wanting to overload said target the attacker send a

request that will change the resource being observed using groupcomm to all

targets. Thus triggering a notification storm towards target from all of the

servers. I think to protect from this attack there are two levels of defense.

The first is to require authorization to request observation. That prevents

security group external resources from triggering the attack. But, unless there

is hard binding between the IP+port and the security credentials of the

endpoint this will not prevent an insider from setting up this attack. For the

later I think one would need either the strict address binding, source address

validation or a return routability check would be needed to prevent this. Most

of this attack is discussed in Security Consideration. The insider attacker

appears to be mostly ignored. Secondly, I think the risk of triggering

notifications on many servers was not really discussed, but maybe I missed the

text.



So why isn't this section discussing the ECHO Option, that is first discussed

in Section 6.2.3. and why are the requirements first stated in Section 6.3

rather than earlier as part of section 3?

[A] Answering on the different points:

  *   Triggering notifications on many servers is not a “risk”. It is a deliberate feature defined in Section 3.7 as a point of update to RFC 7641 (see the last bullet point of Section 1.3 of that document).

The intention is exactly to have a client registering its interest to observe the same resource at multiple servers, by sending a single Observe registration request targeting all servers at once.

  *   This Section 3.7 is meant to describe how to make an Observe registration request intended for multiple servers at once. This feature can certainly be abused to boost the impact of an amplification attack, but it is not a pre-requirement to perform the attack. That is, an amplification attack can leverage group communication without necessarily considering Observe too.

Instead, the amplification attack in its different variants and the use of the Echo option to mitigate it are strictly security related, and it feels natural and appropriate to discuss those in the security considerations of Section 6.2.3. (Note that Section 6.2.3 does not list “requirements”, but rather “guarantees” and “properties” of Group OSCORE)

Perhaps it helps to make the following updates:

  *   In Section 3.7, add one more paragraph at the end, with a heads-up about amplification attacks and a forward pointer to the further discussion in Sections 6.2.3 and 6.3.
  *   In Section 6.2.3, extend the description of the Echo Option as mitigation against amplification attacks, clarifying that it is effective against an external attacker and against an internal (group member) and not-on-path attacker. And clarify it is not effective against an internal (group-member) and on-path attacker, although such an attacker would be exposed and accountable by its use of its own authentication credential, thus facilitating its identification and its eviction from the group through a group rekeying.

Does the above resolution work for you?





Section 5.3:



I think this section and the discussion on proxies in this document should be

clearer on that yes proxies do exist, but this document will not answer the

details needed to actually use them. That will require the

draft-ietf-core-groupcomm-proxy document to be able to implement it especially

in combination with security. Especially as this document have a MUST support

OSCORE groupcomm I think there is an imbalance here when it comes to be able to

implement it. I think you either make groupcomm-proxy normative and MUST be

implemented, or you scope the support for proxies differently in this document

so that it is possbile to later use groupcomm-proxies as the specification to

follow as soon as proxies and groupcomm are relevant.

[A] Indeed, this document does not answer the details needed to actually use proxies.

Note that draft-ietf-core-groupcomm-proxy is not required. It only describes a possible way to implement proxy functionalities for group communication, consistent with the high-level baseline and requirements defined in this document, and addressing the issues introduced by proxies that are raised in this document.

Your suggested scope on using proxies with group communication is what we want. It’s probably not clear enough in the text.

We plan to extend Section 3.5 “Proxy Operation” as follows:

  *   State upfront that the deployment and use of proxies is optional.
  *   Clarify the intended scope of this document about proxies.

We can use a reworked version of our answer to the AD review archived at [AD-REVIEW], where a related point was raised due to the informative reference to draft-ietf-core-groupcomm-proxy.

In the archived answer, that is discussed in the response starting with “Building on RFC 7252 and on the …”

[AD-REVIEW] https://mailarchive.ietf.org/arch/msg/core/zXvisnhjBVAuh12W7tNT5tZwbUg/

Would the above work for you?





Section 6.3:

[I-D.irtf-t2trg-amplification-attacks], is likely not an informative reference,

but an normative as it becomes crucial to understand the attacks discussed here.

[A]  We believe that it is appropriate to have draft-irtf-t2trg-amplification-attacks as an informative reference. The present document is just saying that those attacks are possible, and that they can be mitigated by suppressing error responses to multicast requests and by using the Echo option for doing routability checks (RFC 9175 is a normative reference).

Even without reading the additional information and details from draft-irtf-t2trg-amplification-attacks, one is still perfectly able to implement the present document and its mitigations against amplification attacks.

In Section 6.3, we can revisit the paragraph that includes the reference to draft-irtf-t2trg-amplification-attacks. In particular:

  *   We can provide a short description of the amplification attack, both with group communication alone and with group communication combined with Observe. That’s what the referred draft describes in its Section 2.3.
  *   We can rephrase the current text to say that the referred document provides additional discussion and examples on amplification attacks.

Does the above resolution work for you?







"Thus, consistent with Section 7 of [RFC7641], a server in a CoAP group MUST

strictly limit the number of notifications it sends between receiving

acknowledgements that confirm the actual interest of the client in continuing

the observation." So what is this limitation that one should implement?

[A] The limit to implement is not fully specified in the present document, but rather in RFC 7641. Quoting the text from Section 7 of RFC 7641:



Without client authentication, a server therefore MUST strictly limit the number of notifications that it sends between receiving acknowledgements that confirm the actual interest of the client in the data; i.e., any notifications sent in non-confirmable messages MUST be interspersed with confirmable messages. Note that an attacker may still spoof the acknowledgements if the confirmable messages are sufficiently predictable.

So there is no strict requirement of a number of how many notifications can be sent as NON, before a CON needs to be sent. Or, how long (time period) notifications can be sent without getting any proof of client’s interest. The intended limit is defined there by the “i.e.” part - any notifications sent in non-confirmable messages MUST be interspersed with confirmable messages.

We don’t aim to change this aspect of RFC 7641, which would require adding, e.g., more actionable/concrete numbers. If we do such a thing, it would need to go into a “bis” document for RFC 7641 and is not limited only to the scope of CoAP group communication, we believe.

What we can do is slightly clarify the intention for this “limit” mechanism by this text in Section 6.3:

OLD
Thus, consistent with Section 7 of [RFC7641], a server in a CoAP group MUST strictly limit the number of notifications it sends between receiving acknowledgements that confirm the actual interest of the client in continuing the observation.

NEW
When CoAP group communication is combined with resource observation [RFC7641], a server in a CoAP group MUST strictly limit the number of notifications it sends between receiving acknowledgements that confirm the actual interest of the client in continuing the observation (see Section 7 of [RFC7641]). That is, any notifications sent in non-confirmable messages MUST be interspersed with confirmable messages. Note that an attacker may still spoof the acknowledgements if the confirmable messages are sufficiently predictable.

(Just as background info: having the occasional CON message enables the cleanup of stale clients due to the mechanism in Section 4.5 of RFC 7641 (5th paragraph). If the CON notification times out, the client is removed from the observers list.)

Would this clarification work for you?



To conclude I think a lot of aspects have been considered but the actually

recommendations and default or limit values should be more clearly specified.


[A]  As proposed in the above points, we can certainly add some more details to parameter choices, default mechanisms, limit values, and other elements!
Just let us know if these proposals are in the right direction. Thanks again for your detailed review!

best regards,

Esko Dijk / Marco Tiloca