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

[Esko Dijk <[e-mail]>]

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] 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:

      o 20 seconds, if the OSCORE group is set to (also) use the group mode.
      o 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:

      o 10 seconds, if the OSCORE group is set to (also) use the group mode.
      o 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