Draft: draft-ietf-core-groupcomm-bis

Commentary: this PR to view the edits in the carsten - comments branch 
 Like RFC 7390 already did , this document is also considering realm - local scope and global scope as possible IP multicast scope to use . However , Section 12.8 " Multicast Address Registration " of RFC 7252 says : RFC 7346 defining the realm - local scope came later than RFC 7252 . Thus , it is worth including the possible use of realm - local scope and global scope as part of the update to RFC 7252 that this document is providing , as summarized in its Section 1.3 . 
 E.g. same CoAP group may be named as [ [ ff15::1234]:5683 [ [ ff15::1234 ] And maybe additionally also as : ( etc . ) 
 Can add a reference in Section 1 .
Paragraph (version A):
It strongly discourages unsecured group communication for CoAP
based on the "NoSec" mode (see chap-unsecured-groupcomm and chap-
security-considerations-nosec-mode) and highlights the risk of
amplification attacks (see ssec-amplification).
Paragraph (version B):
It strongly discourages unsecured group communication for CoAP
based on the CoAP NoSec (No Security) mode (see chap-unsecured-
groupcomm and chap-security-considerations-nosec-mode) and
highlights the risk of amplification attacks (see ssec-
amplification).
Paragraph (version B):
It defines the measures against congestion risk specified in
RFC7252 to be applicable also to alternative transports other than
IP multicast, and defines additional guidelines to reduce
congestion risks (see sec-congestion).
Paragraph (version A):
A special security group named "NoSec" identifies group communication
without any security at the transport layer nor at the CoAP layer.
Further details on identifying a security group are provided in sec-
groupnaming-sec.
Paragraph (version B):
Further details on identifying a security group are provided in sec-
groupnaming-sec.
Paragraph (version B):
If the NoSec mode is used, group communication does not rely on
security at the transport layer nor at the CoAP layer, hence the
communicating endpoints do not refer to a security group.
Paragraph (version A):
fig-group-relation-example provides a deployment example of the
relations between the different types of groups.  It shows six CoAP
servers (Srv1-Srv6) and their respective resources hosted (/resX).
There are three application groups (1, 2, 3) and two security groups
(1, 2).  Security Group 1 is used by both Application Group 1 and 2.
Three clients (Cli1, Cli2, Cli3) are configured with security
material for Security Group 1.  Two clients (Cli2, Cli4) are
configured with security material for Security Group 2.  All the
shown application groups use the same CoAP group (not shown in the
figure), i.e., one specific multicast IP address and UDP port number
on which all the shown resources are hosted for each server.
Paragraph (version B):
fig-group-relation-example provides a deployment example of the
relations between the different types of groups.  It shows six CoAP
servers (Srv1-Srv6) and their respective resources hosted (/resX).
Although in real-life deployments using group commmunication the
number of servers and resources would usually be higher, only limited
numbers are shown here for ease of representation.  There are three
application groups (1, 2, 3) and two security groups (1, 2).  The
Security Group 1 may for example include all lighting devices on a
floor of an office building, while Security Group 2 includes all HVAC
devices of that floor.  Security Group 1 is used by both Application
Group 1 and 2.  The Application Group 1 for example may consist of
all lights in a hallway, while Application Group 2 includes all
lights in a storage room.  Three clients (Cli1, Cli2, Cli3) are
configured with security material for Security Group 1.  These
clients may be motion sensors and a control panel (Cli3), that send
multicast messages to /resA to inform the lights of any motion or
user activity detected.  The control panel Cli3 additionally sends a
multicast message to /resB to communicate the latest light preset
selected by a user.  The latter action only influences the lighting
in the storage room (Application Group 2).  Two clients (Cli2, Cli4)
are configured with security material for Security Group 2.  These
clients may be temperature/humidity sensors that report measurements
periodically to all HVAC devices (Srv5, Srv6) in the Application
Group 3, using for example /resC to report temperature and /resD to
report humidity.  All the shown application groups may use the same
CoAP group (not shown in the figure), for example the CoAP group with
site-local, site-specific multicast IP address ff15::3456 and default
UDP port number 5683 on which all the shown resources are hosted for
each server.  Other floors of the same building may replicate the
shown structure, but using different security groups and different
CoAP groups.
Paragraph (version A):
A CoAP group is identified and named by the authority component in
the group URI (see sec-groupdef-coapgroup), which includes the host
subcomponent (possibly an IP multicast address literal) and an
optional UDP port number.  Note that the two authority components
<HOST> and <HOST>:5683 both identify the same CoAP group, whose
members listen to the CoAP default port number 5683.
Paragraph (version B):
A CoAP group is identified and named by the authority component in
the group URI (see sec-groupdef-coapgroup), which includes the host
subcomponent (possibly an IP multicast address literal) and an
optional UDP port number.  Note that, when using the "coap" scheme,
the two authority components <HOST> and <HOST>:5683 both identify the
same CoAP group, whose members listen to the CoAP default port number
5683.
Paragraph (version A):
URI path component - This is the most common and RECOMMENDED
method to encode the application group name.  When using this
method in constrained networks, an application group name
GROUPNAME should be as short as possible.
Paragraph (version B):
URI path component - This is the most common and RECOMMENDED
method to encode the application group name.  When using this
method in constrained networks, an application group name
GROUPNAME should be kept short.
Paragraph (version A):
A best practice for doing so is to use a URI path component such
that: i) it includes a path segment as delimiter with a designated
value, e.g., "gp", followed by ii) a path segment with value the
name of the application group, followed by iii) the path
segment(s) that identify the targeted resource within the
application group.  For example, both /gp/GROUPNAME/res1 and
/base/gp/GROUPNAME/res1/res2 conform to this practice.  Just like
application group names, the path segment used as delimiter should
be as short as possible in constrained networks.
Paragraph (version B):
A best practice for doing so is to use a URI path component such
that: i) it includes a path segment as delimiter with a designated
value, e.g., "gp", followed by ii) a path segment with value the
name of the application group, followed by iii) the path
segment(s) that identify the targeted resource within the
application group.  For example, both /gp/GROUPNAME/res1 and
/base/gp/GROUPNAME/res1/res2 conform to this practice.  Just like
application group names, the path segment used as delimiter should
be kept short in constrained networks.
Paragraph (version A):
As a first alternative, the URI query component consists of
only one parameter, which has no value and has the name of the
application group as its own identifier.  That is, the query
component ?GROUPNAME conforms to this format.
Paragraph (version A):
A full example is provided in fig-gname-query1-example.
Paragraph (version A):
As a second alternative, the URI query component includes a
query parameter as designated indicator, e.g., "gp", with value
the name of the application group.  That is, assuming "gp" to
be used as designated indicator, both the query components
?gp=GROUPNAME and ?par1=v1&gp=GROUPNAME conform to this format.
Paragraph (version A):
A full example is provided in fig-gname-query2-example.
Paragraph (version A):
URI authority component - If this method is used, the application
group is identified by the authority component as a whole.
Paragraph (version B):
As a first alternative, the URI query component consists of
only one parameter, which has no value and has the name of the
application group as its own identifier.  That is, the query
component ?GROUPNAME conforms to this format (see example in
fig-gname-query1-example).
Paragraph (version B):
As a second alternative, the URI query component includes a
query parameter as designated indicator, e.g., "gp", with value
the name of the application group.  That is, assuming "gp" to
be used as designated indicator, both the query components
?gp=GROUPNAME and ?par1=v1&gp=GROUPNAME conform to this format
(see example in fig-gname-query2-example).
Paragraph (version B):
URI authority component - If this method is used, the application
group is identified by the authority component as a whole (see
example in fig-gname-auth-example).
Paragraph (version A):
A full example is provided in fig-gname-auth-example.
Paragraph (version A):
URI host subcomponent - If this method is used, the application
group is identified solely by the host subcomponent of the
authority component.
Paragraph (version A):
Since an application group can be associated with only one CoAP
group (see sec-groupdef-grouprelations), using this method implies
that any two CoAP groups cannot differ only by the port
subcomponent of the URI authority component.
Paragraph (version A):
A full example is provided in fig-gname-host-example.
Paragraph (version A):
URI port subcomponent - By using this method, the application
group is uniquely identified by the destination port number
encoded in the port subcomponent of the authority component.
Paragraph (version A):
A full example is provided in fig-gname-post-example.
Paragraph (version A):
The application group name can be encoded in a new (e.g., custom,
application-specific) CoAP Option, which the client adds to the
CoAP request before sending it out.
Paragraph (version A):
A full example is provided in fig-gname-custom-option-example.
Paragraph (version B):
URI host subcomponent - If this method is used, the application
group is identified solely by the host subcomponent of the
authority component (see example in fig-gname-host-example).
Paragraph (version B):
Since an application group can be associated with only one CoAP
group (see sec-groupdef-grouprelations), using this method implies
that, given any two CoAP groups, the port subcomponent of the URI
authority component MUST NOT be the only information
distinguishing them.
Paragraph (version B):
URI port subcomponent - By using this method, the application
group is uniquely identified by the destination port number
encoded in the port subcomponent of the authority component (see
example in fig-gname-post-example).
Paragraph (version B):
The application group name can be encoded in a new (e.g., custom,
application-specific) CoAP Option, which the client adds to the
CoAP request before sending it out (see example in fig-gname-
custom-option-example).
Paragraph (version A):
Finally, Appendix A of I-D.ietf-core-resource-directory provides an
example of an application group registered to a Resource Directory
(RD), along with the CoAP group it uses and the resources it
supports.  In that example, an application group name "lights" is
encoded in the "ep" (endpoint) attribute of the RD registration
entry.  At the same time, the CoAP group is
ff35:30:2001:db8:f1::8000:1 and the "NoSec" security group is used.
Paragraph (version A):
A security group is identified by a stable and invariant string used
as group name.  This is generally not related with other kinds of
group identifiers that may be specific of the used security solution.
Paragraph (version A):
The "NoSec" security group name MUST be only used to represent the
case of group communication without any security.  This typically
results in CoAP messages that do not include any security group name,
identifier, or security-related data structures.
Paragraph (version B):
Finally, Appendix A of RFC9176 provides an example of an application
group registered to a Resource Directory (RD), along with the CoAP
group it uses and the resources it supports.  In that example, an
application group name "lights" is encoded in the "ep" (endpoint)
attribute of the RD registration entry, while the CoAP group
ff35:30:2001:db8:f1::8000:1 is specified in the authority component
of the URI encoded in the "base" attribute.
Paragraph (version B):
A security group is identified by a stable and invariant string used
as group name.  This is generally not related to other kinds of group
identifiers that may be specific of the used security solution.
Paragraph (version B):
The name of a security group is not expected to be used in messages
exchanged among its members, unless the application requires
otherwise.  At the same time, it is useful to identify the security
group when performing a number of side tasks related to secure group
communication, such as the following ones.
Paragraph (version B):
An administrator may have to request for an authorization to
configure security groups at an available Group Manager (see chap-
oscore).  During the authorization process, as well as during the
interaction between the administrator and the Group Manager, the
group name identifies the specific security group that the
administrator wishes to configure and is authorized to.
Paragraph (version B):
A CoAP endpoint may have to request for an authorization to join a
specific security group through the respective Group Manager, and
thus obtain the required group security material (see chap-
oscore).  During the authorization process, as well as during the
interaction between the CoAP endpoint and the Group Manager, the
group name identifies the specific security group that the CoAP
endpoint wishes to join and is authorized to.
Paragraph (version B):
A CoAP endpoint may first need to discover the specific security
groups to join through the respective Group Manager (see sssec-
discovery-from-rd).  Results from the discovery process include
the name of the security groups to join, together with additional
information such as a pointer to the respective Group Manager.
Paragraph (version B):
It is discouraged to use "NoSec" and any of its lowercase/uppercase
combinations as name of a security group.  Indications that endpoints
can use the NoSec mode MUST NOT rely on setting up and advertising a
pseudo security group with name "NoSec" or any of its lowercase/
uppercase combinations.
Paragraph (version A):
To create a CoAP group, a configuring entity defines an IP multicast
address (or hostname) for the group and optionally a UDP port number
in case it differs from the default CoAP port number 5683.  Then, it
configures one or more devices as listeners to that IP multicast
address, with a CoAP endpoint listening on the group's associated UDP
port.  These endpoints/devices are the group members.  The
configuring entity can be, for example, a local application with pre-
configuration, a user, a software developer, a cloud service, or a
local commissioning tool.  Also, the devices sending CoAP requests to
the group in the role of CoAP client need to be configured with the
same information, even though they are not necessarily group members.
One way to configure a client is to supply it with a group URI.  The
IETF does not define a mandatory protocol to accomplish CoAP group
creation.  RFC7390 defined an experimental protocol for configuration
of group membership for unsecured group communication, based on JSON-
formatted configuration resources.  For IPv6 CoAP groups, common
multicast address ranges that are used to configure group addresses
from are ff1x::/16 and ff3x::/16.
Paragraph (version B):
To create a CoAP group, a configuring entity defines an IP multicast
address (or hostname) for the group and optionally a UDP port number
in case it differs from the default CoAP port number 5683.  Then, it
configures one or more devices as listeners to that IP multicast
address, with a CoAP endpoint listening on the group's associated UDP
port.  These endpoints/devices are the group members.
Paragraph (version B):
The configuring entity can be, for example, a local application with
pre-configuration, a user, a software developer, a cloud service, or
a local commissioning tool.  Also, the devices sending CoAP requests
to the group in the role of CoAP client need to be configured with
the same information, even though they are not necessarily group
members.  One way to configure a client is to supply it with a group
URI.
Paragraph (version B):
The IETF does not define a mandatory protocol to accomplish CoAP
group creation.  RFC7390 defined an experimental protocol for
configuration of group membership for unsecured group communication,
based on JSON-formatted configuration resources.  However, using such
experimental protocol is not a recommended approach.  For IPv6 CoAP
groups, common multicast address ranges that are used to configure
group addresses from are ff1x::/16 and ff3x::/16.
Paragraph (version A):
To participate in a security group, CoAP endpoints have to be
configured with the group security material used to protect
communications in the associated application/CoAP groups.  The part
of the process that involves secure distribution of group security
material MAY use standardized communication with a Group Manager as
defined in chap-oscore.  For unsecure group communication using the
"NoSec" security group, any CoAP endpoint may become a group member
at any time: there is no configuring entity that needs to provide
security material for this group, as there is no security material
for it.  This means that group creation and membership cannot be
tightly controlled for the "NoSec" group.
Paragraph (version A):
The configuration of groups and membership may be performed at
different moments in the life-cycle of a device; for example during
product (software) creation, in the factory, at a reseller, on-site
during first deployment, or on-site during a system reconfiguration
operation.
Paragraph (version B):
To participate in a security group, CoAP endpoints have to be
configured with the group security material used to protect
communications in the associated application/CoAP groups.  The part
of the process that involves secure distribution of group security
material MAY use standardized communication with a Group Manager as
defined in chap-oscore.
Paragraph (version B):
For unsecure group communication using the NoSec mode, there is no
security material to be provided, hence there is no security group
for CoAP endpoints to participate in.
Paragraph (version B):
The configuration of groups and membership may be performed at
different moments in the life-cycle of a device.  For example, it can
occur during product (software) creation, in the factory, at a
reseller, on-site during first deployment, or on-site during a system
reconfiguration operation.
Paragraph (version A):
It is possible for CoAP endpoints to discover application groups as
well as CoAP groups, by using the RD-Groups usage pattern of the CoRE
Resource Directory (RD), as defined in Appendix A of I-D.ietf-core-
resource-directory.
Paragraph (version B):
It is possible for CoAP endpoints to discover application groups as
well as CoAP groups, by using the RD-Groups usage pattern of the CoRE
Resource Directory (RD), as defined in Appendix A of RFC9176.
Paragraph (version A):
In particular, the responsible OSCORE Group Manager registers its
security groups to the RD, as links to its own corresponding
resources for joining the security groups I-D.ietf-ace-key-groupcomm-
oscore.  Later on, CoAP endpoints can discover the registered
security groups and related application groups, by using the lookup
interface of the RD, and then join the security group through the
respective Group Manager.
Paragraph (version B):
In particular, the responsible OSCORE Group Manager registers its
security groups to the RD, as links to its own corresponding
resources for joining the security groups I-D.ietf-ace-key-groupcomm-
oscore.  Later on, CoAP endpoints can discover the names of the
registered security groups and related application groups, by using
the lookup interface of the RD, and then join the security group
through the respective Group Manager.
Paragraph (version A):
A full example is provided in fig-app-gp-discovery-example2.  Note
that the servers need to respond now with an absolute URI and not
a relative URI like in the previous example, because the group
resource "gp1" is hosted at the authority indicated by the CoAP
group (grp.example.org:5685) and not by the authority that is
serving the Link Format document (which is [ff03::fd]:5683).
Paragraph (version B):
A full example is provided in fig-app-gp-discovery-example2.  Note
that the servers need to respond now with an absolute URI and not
a relative URI like in the previous example, because the
responding CoAP endpoint (on port 5683) serving the Link Format
document is a different CoAP endpoint from the one hosting the
group resource "gp1" (on port 5685).  Due to this situation, the
server includes the full (absolute) URI in the Link Format
response from which the client conveniently can learn the CoAP
group.  Also note that a server could equally well respond with
the literal IPv6 multicast address within square brackets instead
of the CoAP group name "grp.example.org".  In that case the client
would still learn the CoAP group, albeit in a different
representation.
Paragraph (version A):
For unsecured group communication (see chap-unsecured-groupcomm),
i.e., the "NoSec" security group, addition/removal of CoAP group
members is simply done by configuring these devices to start/stop
listening to the group IP multicast address on the group's UDP port.
Paragraph (version A):
For secured group communication (see chap-oscore), the maintenance
operations of the protocol Group OSCORE I-D.ietf-core-oscore-
groupcomm MUST be implemented.  When using Group OSCORE, CoAP
endpoints participating in group communication are also members of a
corresponding OSCORE security group, and thus share common security
material.  Additional related maintenance operations are discussed in
chap-sec-group-maintenance.
Paragraph (version B):
For unsecured group communication (see chap-unsecured-groupcomm),
i.e., when the NoSec mode is used, addition/removal of CoAP group
members is simply done by configuring these devices to start/stop
listening to the group IP multicast address on the group's UDP port.
Paragraph (version B):
For secured group communication (see chap-oscore), the maintenance
operations of the protocol Group OSCORE I-D.ietf-core-oscore-
groupcomm MUST be implemented as well.  When using Group OSCORE, CoAP
endpoints participating in group communication are also members of a
corresponding OSCORE security group, and thus share common security
material.  Additional related maintenance operations are discussed in
chap-sec-group-maintenance.
Paragraph (version A):
All CoAP requests that are sent via IP multicast MUST be Non-
confirmable, see Section 8.1 of RFC7252.  The Message ID in an IP
multicast CoAP message is used for optional message deduplication by
both clients and servers, as detailed in Section 4.5 of RFC7252.  A
server sends back a unicast response to a CoAP group request.  The
unicast responses received by the CoAP client may carry a mixture of
success (e.g., 2.05 Content) and failure (e.g., 4.04 Not Found)
response codes, depending on the individual server processing
results.
Paragraph (version B):
All CoAP requests that are sent via IP multicast MUST be Non-
confirmable, see Section 8.1 of RFC7252.  The Message ID in an IP
multicast CoAP message is used for optional message deduplication by
both clients and servers, as detailed in Section 4.5 of RFC7252.  A
server sends back a unicast response to a CoAP group request.  The
unicast responses received by the CoAP client may carry a mixture of
success (e.g., 2.05 (Content)) and failure (e.g., 4.04 (Not Found))
response codes, depending on the individual server processing
results.
Paragraph (version A):
The CoAP No-Response Option RFC7967 can be used by a client to
influence the default response suppression on the server side.  It is
RECOMMENDED for a server to support this option only on selected
resources where it is useful in the application context.  If the
option is supported on a resource, it MUST override the default
response suppression of that resource.
Paragraph (version A):
Any default response suppression by a server SHOULD be performed
consistently, as follows: if a request on a resource produces a
particular Response Code and this response is not suppressed, then
another request on the same resource that produces a response of the
same Response Code class is also not suppressed.  For example, if a
on a resource, then a 4.15 Unsupported Content-Format error response
code is also suppressed by default for that resource.
Paragraph (version B):
The CoAP No-Response Option RFC7967 can be used by a client to
influence the default response suppression on the server side.  It is
RECOMMENDED that a server supporting this option only takes it into
account when processing requests targeting selected resources, as
useful in the application context.
Paragraph (version B):
Any default response suppression by a server SHOULD be performed
consistently, as follows: if a request on a resource produces a
particular Response Code and this response is not suppressed, then
another request on the same resource that produces a response of the
same Response Code class is also not suppressed.  For example, if a
default on a resource, then a 4.15 Unsupported Content-Format error
response code is also suppressed by default for that resource.
Paragraph (version A):
How the client in the case above determines the current CoAP server
group members is out of scope for this document.  It may be, for
example, via a group manager server, or by observing group join
requests, or observing IGMP/MLD multicast group join messages, etc.
Paragraph (version B):
How the client in the case above determines the current CoAP server
group members is out of scope for this document.  It may be, for
example, via a group manager server, or by monitoring group joining
protocol exchanges.
Paragraph (version A):
A client endpoint MAY include one or more ETag Options in a GET or
FETCH group request to validate one or more stored responses it has
cached.  In case two or more servers in the group have responded to a
previous request to the same resource with an identical ETag value,
it is the responsibility of the client to handle this case.  In
particular, if the client wishes to validate, using a group request,
a response from server 1 with an ETag value N, while it does not wish
to validate a response from server 2 with the same ETag value N,
there is no way to achieve this.  In such cases of identical ETag
values returned by two or more servers, the client, by default,
SHOULD NOT include an ETag Option in a group request containing that
ETag value.
Paragraph (version A):
A server endpoint MUST process an ETag Option in a GET or FETCH group
request in the same way it processes an ETag Option for a unicast
request.  A server endpoint that includes an ETag Option in a
response to a group request SHOULD construct the ETag Option value in
such a way that the value will be unique to this particular server
with a high probability.  This can be done, for example, by embedding
a compact ID of the server within the ETag value, where the ID is
unique (or unique with a high probability) in the scope of the group.
Paragraph (version B):
A client endpoint MAY include one or more ETag Options in a GET or
FETCH group request to validate one or more stored responses it has
cached.  In case two or more servers in the group have responded to a
previous request to the same resource with an identical ETag value,
it is the responsibility of the client to handle this case.  In
particular, if the client wishes to validate, using a group request,
a response from server 1 with an ETag value N, while it does not wish
to validate a response from server 2 with the same ETag value N,
there is no way to achieve this.  In such cases where an identical
ETag value is returned by two or more servers, the client, by
default, SHOULD NOT include an ETag Option containing that ETag value
in a group request.
Paragraph (version B):
A server endpoint MUST process an ETag Option in a GET or FETCH group
request in the same way it processes an ETag Option for a unicast
request.  A server endpoint that includes an ETag Option in a
response to a group request SHOULD construct the ETag Option value in
such a way that the value will be unique to this particular server
with a high probability.  This practically prevents a collision of
the ETag values from different servers in the same application group,
which in turn allows the client to effectively validate a particular
response of an origin server.  This can be accomplished, for example,
by embedding a compact ID of the server within the ETag value, where
the ID is unique (or unique with a high probability) in the scope of
the group.
Paragraph (version A):
The URI Path used in a group request is preferably a path that is
known to be supported across all group members.  However, there are
valid use cases where a group request is known to be successful only
for a subset of the CoAP group, for example only members of a
specific application group, while those group members for which the
request is unsuccessful (for example because they are outside the
application group) either ignore the group request or respond with an
error status code.
Paragraph (version B):
The URI Path used in a group request is preferably a path that is
known to be supported across all group members.  However, there are
valid use cases where a group request is known to be successful only
for a subset of the CoAP group.  For instance, the subset may include
only members of a specific application group, while those group
members for which the request is unsuccessful (for example because
they are outside the application group) either respond with an error
status code or ignore the group request (see also sec-request-
response-suppress on response suppression).
Paragraph (version B):
This section defines how proxies operate in a group communication
scenario.  In particular, sec-proxy-forward defines operations of
forward-proxies, while sec-proxy-reverse defines operations of
reverse-proxies.  Furthermore, multicasting-to-proxies discusses the
case where a client sends a group request to multiple proxies at
once.  Security operations for a proxy are discussed later in chap-
proxy-security.
Paragraph (version A):
When intending to reach a CoAP group through a proxy, the client
sends a unicast CoAP group request to the proxy.  This request
specifies the group URI where the request has to be forwarded to,
either as a string in the Proxy-URI Option, or through the Proxy-
Scheme Option with the group URI constructed from the usual Uri-*
Options.  Then, the forward-proxy resolves the group URI to a
destination CoAP group, i.e., it sends (e.g., multicasts) the CoAP
group request to the group URI, receives the responses and forwards
all the individual (unicast) responses back to the client.
Paragraph (version B):
When intending to reach a CoAP group through a proxy, the client
sends a unicast CoAP group request to the proxy.  The group URI where
the request has to be forwarded to is specified in the request,
either as a string in the Proxy-URI Option, or through the Proxy-
Scheme Option with the group URI constructed from the usual Uri-*
Options.  Then, the forward-proxy resolves the group URI to a
destination CoAP group, i.e., it sends (e.g., multicasts) the CoAP
group request to the group URI, receives the responses and forwards
all the individual (unicast) responses back to the client.
Paragraph (version B):
Unlike a CoAP client, the proxy is likely to lack "application
context".  In particular, the proxy is not expected to know how
many members there are in the CoAP group (not even the order of
magnitude), how many group members will actually respond, or the
minimal amount/percentage of those that will respond.
Paragraph (version B):
Therefore, while still capable to forward the group request to the
CoAP group and the corresponding responses to the client, the
proxy does not know and cannot reliably determine for how long to
collect responses, before it stops forwarding them to the client.
Paragraph (version B):
A forward-proxying method for HTTP-to-CoAP proxies addressing the
issues raised above is defined in I-D.tiloca-core-groupcomm-proxy.
Paragraph (version A):
Furthermore, the reverse-proxy can actually stand in for (and thus
prevent directly reaching) only the whole set of servers in the
group, or also for each of those individual servers (e.g., if acting
as firewall).
Paragraph (version B):
The reverse-proxy practically stands in for a CoAP group, thus
preventing the client from reaching the group as a whole with a
single group request directly addressed to that group (e.g., via
multicast).  In addition to that, the reverse-proxy may also stand in
for each of the individual servers in the CoAP group (e.g., if acting
as firewall), thus also preventing the client from individually
reaching any server in the group with a unicast request directly
addressed to that server.
Paragraph (version A):
A reverse-proxy MAY have preconfigured time duration(s) that are
used for the collecting of server responses and forwarding these
back to the client.  These duration(s) may be set as global
configuration or resource-specific configurations.  If there is
such preconfiguration, then an explicit signaling of the time
period in the client's request as defined in I-D.tiloca-core-
groupcomm-proxy is not necessarily needed.
Paragraph (version B):
A reverse-proxy MAY have preconfigured time duration(s) that are
used for collecting server responses and forwarding these back to
the client.  These duration(s) may be set as global configuration
or as resource-specific configurations.  If there is such
preconfiguration, then an explicit signaling of the time period in
the client's request as defined in I-D.tiloca-core-groupcomm-proxy
is not necessarily needed.  Note that a reverse-proxy is in an
explicit relation with the origin servers it stands in for.  Thus,
compared to a forward-proxy, it has a much better basis for
determining and configuring such time durations.
Paragraph (version A):
If this happens, the reverse-proxy MUST stop the ongoing request
and associated response forwarding, it MUST NOT forward the new
request to the group of servers, and it MUST send a 4.00 Bad
Request error response to the client.  The diagnostic payload of
the error response SHOULD indicate to the client that the resource
is a reverse-proxy resource, and that for this reason immediate
Token re-use is not possible.
Paragraph (version B):
If this happens, the reverse-proxy MUST stop the ongoing request
and associated response forwarding, it MUST NOT forward the new
request to the group of servers, and it MUST send a 4.00 (Bad
Request) error response to the client.  The diagnostic payload of
the error response SHOULD indicate to the client that the resource
is a reverse-proxy resource, and that for this reason immediate
Token re-use is not possible.
Paragraph (version A):
For the operation of HTTP-to-CoAP reverse proxies, see the last
paragraph of sec-proxy-forward which applies also to the case of
reverse-proxies.
Paragraph (version B):
For the operation of HTTP-to-CoAP reverse proxies, see the last two
paragraphs of sec-proxy-forward which applies also to the case of
reverse-proxies.
Paragraph (version B):
A client might send a group request to multiple proxies at once
(e.g., over IP multicast), so that each and every of those proxies
forwards it to the group of servers.  Assuming that no message loss
occurs and that N proxies receive and forward the group request, this
has the following implications.
Paragraph (version B):
Each server receives N copies of the group request, i.e., one copy
from each proxy.
Paragraph (version B):
Each server can reply to each of the N received requests with
multiple responses over time (see sec-request-response-multi).
All the responses to the same received request are sent to the
same proxy that has forwarded that request, which in turn
relays those responses to the client.
Paragraph (version B):
From each proxy, the client receives all the responses to the
group request that each server has sent to that proxy.  Even in
case the client is able to distinguish the different servers
originating the responses (e.g., by using the approach defined
in I-D.tiloca-core-groupcomm-proxy), the client would receive
the same response content originated by each server N times, as
relayed by the N proxies.
Paragraph (version B):
If secure group communication with Group OSCORE is used, each
server is able to determine that each received copy of the group
request is in fact originated by the same client.  In particular,
each server is able to determine that all such received requests
are copies of exactly the same group request.
Paragraph (version B):
Consistently, each server S accepts only the first copy of the
group request received from one of the proxies, say P, while
discarding as replay any later copies received from any other
proxy.
Paragraph (version B):
After that, the server S can reply to the accepted request with
multiple responses over time (see sec-request-response-multi).
All those responses are sent to the same proxy P that forwarded
the only accepted request, and that in turn relays those responses
to the client.
Paragraph (version B):
As a consequence, for each server, the client receives responses
originated by that server only from one proxy.  That is, the
client receives a certain response content only once, like in the
case with only one proxy.
Paragraph (version B):
This document also defines these measures to be applicable to
alternative transports (other than IP multicast), if not defined
otherwise.
Paragraph (version B):
This section updates RFC7641 with the use of the Observe Option in a
CoAP GET group request, and defines normative behavior for both
client and server.  Consistent with Section 2.4 of RFC8132, the same
rules apply when using the Observe Option in a CoAP FETCH group
request.
Paragraph (version A):
In 6LoWPAN RFC4944 RFC6282 networks, IPv6 packets (up to 1280 bytes)
may be fragmented into smaller IEEE 802.15.4 MAC frames (up to 127
bytes), if the packet size requires this.  Every 6LoWPAN IPv6 router
that receives a multi-fragment packet reassembles the packet and
refragments it upon transmission.  Since the loss of a single
fragment implies the loss of the entire IPv6 packet, the performance
in terms of packet loss and throughput of multi-fragment multicast
IPv6 packets is typically far worse than the performance of single-
fragment IPv6 multicast packets.  For this reason, a CoAP request
sent over multicast in 6LoWPAN networks SHOULD be sized in such a way
that it fits in a single IEEE 802.15.4 MAC frame, if possible.
Paragraph (version B):
In 6LoWPAN RFC4944 RFC6282 networks, IPv6 packets (up to 1280 bytes)
may be fragmented into smaller IEEE 802.15.4 MAC frames (up to 127
bytes), if the packet size requires this.
Paragraph (version B):
Every 6LoWPAN IPv6 router that receives a multi-fragment packet
reassembles the packet and refragments it upon transmission.  Since
the loss of a single fragment implies the loss of the entire IPv6
packet, the performance in terms of packet loss and throughput of
multi-fragment multicast IPv6 packets is typically far worse than the
performance of single-fragment IPv6 multicast packets.  Moreover,
unlike usually done for unicast packets, IEEE 802.15.4 radios cannot
rely on acknowledgment frames to increase delivery reliability for
multicast packets, thus further exacerbating the issue.
Paragraph (version B):
Due to the reasons above, a CoAP request sent over multicast in
6LoWPAN networks SHOULD be sized in such a way that it fits in a
single IEEE 802.15.4 MAC frame, if possible.
Paragraph (version A):
CoAP group communication can operate in CoAP NoSec (No Security)
mode, without using application-layer and transport-layer security
mechanisms.  The NoSec mode uses the "coap" scheme, and is defined in
Section 9 of RFC7252.  The conceptual "NoSec" security group as
defined in sec-groupdef is used for unsecured group communication.
Paragraph (version B):
CoAP group communication can operate in CoAP NoSec (No Security)
mode, without using application-layer and transport-layer security
mechanisms.  The NoSec mode uses the "coap" scheme, and is defined in
Section 9 of RFC7252.
Paragraph (version B):
The NoSec mode does not require and does not make use of a security
group.  Indications that endpoints can use the NoSec mode MUST NOT
rely on setting up and advertising a pseudo security group with name
NoSec or any of its lowercase/uppercase combinations.
Paragraph (version A):
This section defines how CoAP group communication can be secured.  In
particular, chap-group-oscore describes how the Group OSCORE security
protocol I-D.ietf-core-oscore-groupcomm can be used to protect
messages exchanged in a CoAP group, while chap-sec-group-maintenance
provides guidance on required maintenance operations for OSCORE
groups used as security groups.
Paragraph (version B):
This section discusses how CoAP group communication can be secured.
In particular, chap-group-oscore describes how the Group OSCORE
security protocol I-D.ietf-core-oscore-groupcomm can be used to
protect messages exchanged in a CoAP group, while chap-sec-group-
maintenance provides guidance on required maintenance operations for
OSCORE groups used as security groups.
Paragraph (version A):
A CoAP endpoint can discover OSCORE groups and retrieve information
to join them through their respective Group Managers by using the
method described in I-D.tiloca-core-oscore-discovery and based on the
CoRE Resource Directory I-D.ietf-core-resource-directory.
Paragraph (version B):
A CoAP endpoint can discover OSCORE groups and retrieve information
to join them through their respective Group Managers by using the
method described in I-D.tiloca-core-oscore-discovery and based on the
CoRE Resource Directory RFC9176.
Paragraph (version A):
Applications may need backward security.  That is, they may
require that, after having joined an OSCORE group, a new group
member cannot access messages exchanged in the group prior to its
joining, even if it has recorded them.
Paragraph (version B):
Applications may need backward security.  That is, they may
require that, after having joined an OSCORE group, a new group
member cannot read the cleartext of messages exchanged in the
group prior to its joining, even if it has recorded them.
Paragraph (version B):
The case of hop-by-hop security is only possible if the proxy can be
completely trusted and it is configured as a member of the OSCORE
security group(s) that it needs to access, when sending a group
request on behalf of clients.  The first leg of communication between
client and proxy is then protected with a security method for CoAP
unicast, such as (D)TLS, OSCORE or a combination of such methods.
The second leg between proxy and servers is protected using Group
OSCORE.  This can be useful in applications where for example the
origin client does not implement Group OSCORE, or the group
management operations are confined to a particular network domain and
the client is outside this domain.
Paragraph (version A):
In such a case, the Group Manager may cautiously consider to rekey
the group, e.g., after a minimum number of nodes has joined or left
the group within a pre-defined time interval, or according to
communication patterns with predictable time intervals of network
inactivity.  This would prevent paralyzing communications in the
group, when a slow rekeying scheme is used and frequently invoked.
Paragraph (version B):
In such a case, the Group Manager may cautiously consider to rekey
the group, e.g., after a minimum number of nodes has joined or left
the group within a pre-defined time interval, or according to
communication patterns with predictable time intervals of network
inactivity.  This would prevent from paralyzing communications in the
group, when a slow rekeying scheme is used and frequently invoked.
Paragraph (version A):
To this end, outgoing messages are either countersigned by the
message sender endpoint with its own private key (group mode), or
protected with a symmetric key, which is in turn derived using the
asymmetric keys of the message sender and recipient (pairwise mode).
Paragraph (version B):
To this end, outgoing messages are either signed by the message
sender endpoint with its own private key (group mode), or protected
with a symmetric key, which is in turn derived using the asymmetric
keys of the message sender and recipient (pairwise mode).
Paragraph (version A):
Group OSCORE limits the feasibility and impact of amplification
attacks, see ssec-amplification of this document and Section 11.3
of RFC7252.
Paragraph (version A):
In fact, upon receiving a group request protected with Group
OSCORE in group mode, a server is able to verify whether the
request is not a replay and originates from the alleged sender in
the OSCORE group, by verifying the signature included in the
request using the public key of that sender (see Section 8.2 of I-
D.ietf-core-oscore-groupcomm).  Furthermore, as also discussed in
Section 8 of I-D.ietf-core-oscore-groupcomm, it is recommended
that servers failing to decrypt and verify an incoming message do
not send back any error message.
Paragraph (version B):
Group OSCORE limits the feasibility and impact of amplification
attacks (see ssec-amplification of this document and Section 11.3
of RFC7252).
Paragraph (version B):
That is, upon receiving a group request protected with Group
OSCORE, a server verifies whether the request is not a replay, and
whether it originates from the alleged sender in the OSCORE group.
In order to perform the latter check of source authentication, the
server either: i) verifies the signature included in the request
by using the public key of the client, when the request is
protected using the group mode (see Section 8.2 of I-D.ietf-core-
oscore-groupcomm); or ii) decrypts and verifies the request by
means of an additionally derived pairwise key associated with the
client, when the request is protected using the pairwise mode (see
Section 9.4 of I-D.ietf-core-oscore-groupcomm).
Paragraph (version B):
As also discussed in Section 8 of I-D.ietf-core-oscore-groupcomm,
it is recommended that servers failing to decrypt and verify an
incoming message do not send back any error message.
Paragraph (version A):
Furthermore, the adversary needs to consider a group request that
specifically targets a resource for which the CoAP servers are
configured to respond.  While this can be often correctly assumed
or inferable from the application context, it is not explicit from
the group request itself, since Group OSCORE protects the Uri-Path
and Uri-Query CoAP Options conveying the respective components of
the target URI.
Paragraph (version B):
Furthermore, the adversary needs to consider a group request that
specifically targets a resource for which the CoAP servers are
configured to respond.  While this can be often correctly
inferable from the application context, it is not explicit from
the group request itself, since Group OSCORE protects the Uri-Path
and Uri-Query CoAP Options conveying the respective components of
the target URI.
Paragraph (version A):
As a further mitigation against amplification attacks, a server
can also rely on the Echo Option for CoAP defined in RFC9175 and
include it in a response to a group request.  By doing so, the
server can assert that the alleged sender of the group request
(i.e., the CoAP client associated with a certain authentication
credential including the corresponding public key) is indeed
reachable at the claimed source address, especially if this
differs from the one used in previous group requests from the same
CoAP client.  Although responses including the Echo Option do
still result in amplification, this is limited in volume compared
to when all servers reply with a full response.
Paragraph (version A):
Group OSCORE limits the impact of attacks based on IP spoofing
also over IP multicast (see Section 11.4 of RFC7252).  In fact,
requests and corresponding responses sent in the OSCORE group can
be correctly generated only by legitimate group members.
Paragraph (version B):
As a further mitigation against amplification attacks, a server
can also rely on the Echo Option for CoAP defined in RFC9175 and
include it in a response to a group request.  By doing so, the
server can assert that the alleged sender of the group request
(i.e., the CoAP client associated with a certain authentication
credential including the corresponding public key) is indeed
reachable at the claimed source address, especially if this
differs from the one used in previous group requests from the same
(authenticated) device.  Although responses including the Echo
Option do still result in amplification, this is limited in volume
compared to when all servers reply with a full response.
Paragraph (version B):
Group OSCORE limits the impact of attacks based on IP spoofing
over IP multicast (see Section 11.4 of RFC7252).  In fact,
requests and corresponding responses sent in the OSCORE group can
be correctly generated only by legitimate group members.
Paragraph (version A):
A relevant exceptional example is a CoAP client performing the
discovery of hosts such as a group manager or a Resource Directory I-
D.ietf-core-resource-directory, by probing for them through a group
request sent to the CoAP group.  This early, unprotected step is
relevant for a CoAP client that does not know the address of such
hosts in advance, and that does not have yet configured a mutual
security relation with them.  In this kind of deployments, such a
discovery procedure does not result in a considerable and harmful
amplification, since only the few CoAP servers that are the object of
discovery are going to respond to the group request targeting that
specific resource.  In particular, those hosts can be the only CoAP
servers in that specific CoAP group (hence listening for group
requests sent to that group), and/or the only CoAP servers explicitly
configured to respond to group requests targeting specific group
resources.
Paragraph (version B):
A relevant exceptional example is a CoAP client performing the
discovery of hosts such as a group manager or a Resource Directory
RFC9176, by probing for them through a group request sent to the CoAP
group.  This early, unprotected step is relevant for a CoAP client
that does not know the address of such hosts in advance, and that
does not have yet configured a mutual security relation with them.
In this kind of deployments, such a discovery procedure does not
result in a considerable and harmful amplification, since only the
few CoAP servers that are the object of discovery are going to
respond to the group request targeting that specific resource.  In
particular, those hosts can be the only CoAP servers in that specific
CoAP group (hence listening for group requests sent to that group),
and/or the only CoAP servers explicitly configured to respond to
group requests targeting specific group resources.
Paragraph (version A):
For example, an attacker may attempt to record all the CoAP traffic
going over a smart grid (i.e., networked electrical utility) and try
to determine critical nodes for further attacks.  For example, the
source node (controller) sends out CoAP group communication messages
which easily identifies it as a controller.  CoAP multicast traffic
is inherently more vulnerable compared to unicast, as the same packet
may be replicated over many more links, leading to a higher
probability of packet capture by a pervasive monitoring system.
Paragraph (version A):
One mitigation is to restrict the scope of IP multicast to the
minimal scope that fulfills the application need.  See the congestion
control recommendations in the last bullet of
sec-congestion to minimize the scope.  Thus, for example, realm-local
IP multicast scope is always preferred over site-local scope IP
multicast if this fulfills the application needs.
Paragraph (version A):
Even if all CoAP multicast traffic is encrypted/protected, an
attacker may still attempt to capture this traffic and perform an
off-line attack in the future.
Paragraph (version B):
CoAP traffic is typically used for the Internet of Things, and CoAP
(multicast) group communication may specifically be used for
conveniently controlling and monitoring critical infrastructure
(e.g., lights, alarms, HVAC, electrical grid, etc.).
Paragraph (version B):
However, this may be a prime target of pervasive monitoring attacks
RFC7258, which have to be considered as a key additional threat for
group communication.  For example, an attacker may attempt to record
all the CoAP traffic going over a smart grid (i.e., networked
electrical utility) and try to determine critical nodes for further
attacks.  For instance, the source node (controller) sends out CoAP
group messages, which easily identifies it as a controller.
Paragraph (version B):
CoAP group communication built on top of IP multicast is inherently
more vulnerable compared to communications solely relying on IP
unicast, since the same packet may be replicated over many multiple
links.  In particular, this yields a higher probability of packet
capture by a pervasive monitoring system, which in turn results in
more information available to analyze within the same time interval.
Moreover, a single CoAP group request potentially results in multiple
CoAP responses, thus further contributing to the information
available to analyze.
Paragraph (version B):
This requires CoAP group communication solutions that are built on
top of IP multicast to pay particular attention to these dangers.
Paragraph (version B):
In order to limit the ease of interception of group communication
messages, one mitigation is to restrict the scope of IP multicast to
the minimal scope that fulfills the application need.  See the
congestion control recommendations in the last bullet of sec-
congestion to minimize the scope.  Thus, for example, realm-local IP
multicast scope is always preferred over site-local scope IP
multicast, if it fulfills the application needs.
Paragraph (version B):
Even if CoAP group communications are encrypted/protected (see chap-
oscore), an attacker may still attempt to capture this traffic and
perform an off-line attack in the future.