Draft: draft-ietf-core-groupcomm-bis

Commentary: I did a high - level review of all the recent updates ; thanks ! For the Multi - ETag and Group - ETag options I think a separate draft would be needed as it seems to go beyond the scope of updated GroupComm RFC . We can also include these new features and let the working group discuss where it should go . For the new features I feel that some motivation and typical use cases are needed ; e.g. a constrained CoAP client would n't use these ( too much complexity / code ? ) but an unconstrained client accessing constrained servers via an unconstrained  might happily use these to reduce network load on the constrained network ( near the servers ) . But this could be later also .
Paragraph (version A):
This document specifies the use of the Constrained Application
Protocol (CoAP) for group communication, using UDP/IP multicast as
the underlying data transport.  Both unsecured and secured CoAP group
communication are specified.  Security is achieved by use of the
Group Object Security for Constrained RESTful Environments (Group
OSCORE) protocol.  The target application area of this specification
is any group communication use cases that involve resource-
constrained networks.  The most common of such use cases are also
discussed.  This document replaces RFC7390 and updates RFC7252 and
RFC7641.
Paragraph (version A):
All guidelines in RFC7390 are updated by this document, which
replaces and obsoletes RFC7390.  Furthermore, this document updates
RFC7252, by specifying a group request/response model and by adding
security for CoAP group communication.  Finally, this document also
updates RFC7641, by adding the multicast usage of CoAP Observe for
both the GET and FETCH methods.
Paragraph (version B):
All guidelines in RFC7390 are updated by this document, which
replaces and obsoletes RFC7390.  Furthermore, this document updates
RFC7252, by specifying: a group request/response model; cachability
of responses to group requests at proxies; a response validation
model for responses to group requests; and the use of Group OSCORE I-
D.ietf-core-oscore-groupcomm to achieve security for CoAP group
communication.  Finally, this document also updates RFC7641, by
defining the multicast usage of the CoAP Observe Option for both the
GET and FETCH methods.
Paragraph (version A):
The general operation of group communication, both unsecured and
secured, is specified in this section.  First, different group types
are defined in sec-groupdef.  Group configuration, including group
creation and maintenance by an application, user or commissioning
entity is considered next in sec-groupconf.  Then the use of CoAP for
group communication including support for protocol extensions (block-
wise transfer, Observe) follows in sec-coap-usage.  How CoAP group
messages are carried over various transport layers is the subject of
sec-transport.  Finally, sec-other-protocols covers the interworking
of CoAP group communication with other protocols that may operate in
the same network.
Paragraph (version B):
In the following, different group types are first defined in sec-
groupdef.  Then, Group configuration, including group creation and
maintenance by an application, user or commissioning entity is
considered in sec-groupconf.
Paragraph (version A):
CoAP request.  If not explicitly encoded, the application group is
implicitly derived by the receiver, based on information in the CoAP
request.  See sec-groupnaming for more details on identifying the
application group.
Paragraph (version B):
CoAP request, for example as a name in the URI path.  If not
explicitly encoded, the application group is implicitly derived by
the receiver, based on information in the CoAP request.  See sec-
groupnaming for more details on identifying the application group.
Paragraph (version A):
layer and/or application layer.
Paragraph (version B):
layer nor at the CoAP layer.
Paragraph (version A):
On one hand, multiple application groups may use the same security
group.  Thus, the same group security material is used to protect the
messages targeting any of those application groups.  In this case, a
CoAP endpoint is supposed to know the exact application group to
refer to for each message, based on, e.g., the used server port
number, the targeted resource, or the content and structure of the
message payload.
Paragraph (version A):
On the other hand, a single application group may use multiple
security groups.  Thus, different messages targeting the resources of
the application group can be protected with different security
material.  This can be convenient, for example, if the security
groups differ with respect to the crytpographic algorithms and
related parameters they use.  In this case, a CoAP client can join
just one of the security groups, based on what it supports and
prefers, while a CoAP server in the application group would rather
have to join all of them.
Paragraph (version A):
Beyond this particular case, applications should be greatly careful
in associating a same application group to multiple security groups.
In particular, it is NOT RECOMMENDED using different security groups
to reflect different access policies for resources in a same
application group.  That is, being a member of a security group
actually grants access only to exchanged secure messages, while
access to resources in the application group belongs to a separate
security domain, and has to be separately enforced by leveraging the
resource properties or through dedicated access control credentials
assessed by separate means.
Paragraph (version A):
fig-group-relation summarizes the relations between the different
types of groups described above in UML class diagram notation.  The
items in square brackets are optionally defined.
Paragraph (version B):
On one hand, multiple application groups may use the same security
group.  Thus, the same group security material is used to protect the
messages targeting any of those application groups.  This has the
benefit that typically less storage, configuration and updating are
required for security material.  In this case, a CoAP endpoint is
supposed to know the exact application group to refer to for each
message that is sent or received, based on, e.g., the used server
port number, the targeted resource, or the content and structure of
the message payload.
Paragraph (version B):
On the other hand, a single application group may use multiple
security groups.  Thus, different messages targeting the resources of
the application group can be protected with different security
material.  This can be convenient, for example, if the security
groups differ with respect to the cryptographic algorithms and
related parameters they use.  In this case, a CoAP client can join
just one of the security groups, based on what it supports and
prefers, while a CoAP server in the application group would rather
have to join all of them.
Paragraph (version B):
Beyond this particular case, applications should be careful in
associating a same application group to multiple security groups.  In
particular, it is NOT RECOMMENDED to use different security groups to
reflect different access policies for resources in a same application
group.  That is, being a member of a security group actually grants
access only to exchange secured messages and enables authentication
of group members, while access control (authorization) to use
resources in the application group belongs to a separate security
domain.  It has to be separately enforced by leveraging the resource
properties or through dedicated access control credentials assessed
by separate means.
Paragraph (version B):
fig-group-relation summarizes the relations between the different
types of groups described above in UML class diagram notation.  The
class attributes in square brackets are optionally defined.
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.  One cient (Cli4) is 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 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).
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 on which
all the shown resources are hosted for each server.
Paragraph (version B):
The following defines how groups of different types are named,
created, discovered and maintained.
Paragraph (version A):
application group into a Resource Directory, along with the CoAP
group it uses and the resources supported by the application group.
In this example an application group identifier is not explicitly
encoded in the RD nor in CoAP requests made to the group, but it
implicitly follows from the CoAP group used for the request.  So
there is a one-to-one binding between the CoAP group and the
application group.  The "NoSec" security group is used.
Paragraph (version B):
application group into a Resource Directory (RD), along with the CoAP
group it uses and the resources supported by the application group.
In this example an application group identifier is not explicitly
encoded in the RD nor in CoAP requests made to the group, but it
implicitly follows from the CoAP group used for the request.  So
there is a one-to-one binding between the CoAP group and the
application group.  The "NoSec" security group is used.
Paragraph (version A):
To create a security group, a configuring entity defines an initial
subset of the related security material.  This comprises a set of
group properties including the crytpographic algorithms and
parameters used in the group, as well as additional information
relevant throughout the group life-cycle, such as the security group
name and description.  This task MAY be entrusted to a dedicated
administrator, that interacts with a Group Manager as defined in
chap-oscore.  After that, further security material to protect group
communications have to be generated, as compatible with the specified
group configuration.
Paragraph (version B):
To create a security group, a configuring entity defines an initial
subset of the related security material.  This comprises a set of
group properties including the cryptographic algorithms and
parameters used in the group, as well as additional information
relevant throughout the group life-cycle, such as the security group
name and description.  This task MAY be entrusted to a dedicated
administrator, that interacts with a Group Manager as defined in
chap-oscore.  After that, further security materials to protect group
communications have to be generated, compatible with the specified
group configuration.
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 (central) configuring entity that needs to
provide the security material for this group.  This means that group
creation and membership cannot be tightly controlled for the "NoSec"
group.
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.  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):
For unsecured group communication (see chap-unsecured-groupcomm),
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 protocol Group
OSCORE I-D.ietf-core-oscore-groupcomm is mandatory to implement.
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.
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 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.  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):
This section specifies the usage of CoAP in group communication, both
unsecured and secured.  This includes additional support for protocol
extensions, such as Observe (see sec-observe) and block-wise transfer
(see sec-block-wise).
Paragraph (version B):
How CoAP group messages are carried over various transport layers is
the subject of sec-transport.  Finally, sec-other-protocols covers
the interworking of CoAP group communication with other protocols
that may operate in the same network.
Paragraph (version A):
All CoAP requests that are sent via IP multicast MUST be Non-
confirmable (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.
Paragraph (version A):
A server sends back a unicast response to the CoAP group request -
but the server MAY suppress the response for various reasons
(Section 8.2 of RFC7252).  This document adds the requirement that a
server SHOULD suppress the response in case of error or in case there
is nothing useful to respond, unless the application related to a
particular resource requires such a response to be made for that
resource.  The unicast responses received by the CoAP client may be a
mixture of success (e.g., 2.05 Content) and failure (e.g., 4.04 Not
Found) 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.
Paragraph (version B):
A server sends back a unicast response to the CoAP group request -
but the server MAY suppress the response for various reasons given in
Section 8.2 of RFC7252.  This document adds the requirement that a
server SHOULD suppress the response in case of error or in case there
is nothing useful to respond, unless the application related to a
particular resource requires such a response to be made for that
resource.  The unicast responses received by the CoAP client may be a
mixture of success (e.g., 2.05 Content) and failure (e.g., 4.04 Not
Found) codes, depending on the individual server processing results.
Paragraph (version A):
A CoAP client MAY also repeat a multicast request using the same
Token value and a different Message ID, in which case all servers
that received the initial request will again process the repeated
request since it appears within a new CoAP message.  This is useful
in case a client suspects that one or more response(s) to its
original request were lost and the client needs to collect more, or
even all, responses from group members, even if this comes at the
cost of the overhead of certain group members responding twice (once
to the original request, and once to the repeated request with
different Message ID).
Paragraph (version A):
The CoAP client can distinguish the origin of multiple server
responses by the source IP address of the UDP message containing the
CoAP response and/or any other available application-specific source
identifiers contained in the CoAP response, such as an application-
level unique ID associated to the server.  If secure communication is
provided with Group OSCORE (see chap-oscore), additional security-
related identifiers enable the client to retrieve the right security
material for decrypting each response and authenticating its source.
Paragraph (version A):
While processing a response, the source endpoint of the response is
not matched to the destination endpoint of the request, since for a
multicast request these will never match.  This is specified in
Section 8.2 of RFC7252.  It implies also that a server MAY respond
from a UDP port number that differs from the destination UDP port
number of the request, yet a CoAP server normally SHOULD respond from
the UDP port number that equals the destination port of the request
-- following the convention for UDP-based protocols.  In case a
single client has sent multiple group requests and concurrent CoAP
transactions are ongoing, the responses received by that client are
matched to an active request using only the Token value.  Due to UDP
level multiplexing, the UDP destination port of the response MUST
match to the client endpoint's UDP port value, i.e. to the UDP source
port of the client's request.
Paragraph (version B):
The CoAP client can distinguish the origin of multiple server
responses by the source IP address of the UDP message containing the
CoAP response and/or any other available application-specific source
identifiers contained in the CoAP response payload or CoAP response
options, such as an application-level unique ID associated to the
server.  If secure communication is provided with Group OSCORE (see
chap-oscore), additional security-related identifiers in the CoAP
response enable the client to retrieve the right security material
for decrypting each response and authenticating its source.
Paragraph (version A):
than 500 seconds.
Paragraph (version A):
When securing Group CoAP communications with Group OSCORE I-D.ietf-
core-oscore-groupcomm, secure binding between requests and responses
is ensured (see chap-oscore).  Thus, a client may reuse a Token value
after it has been freed up, as discussed above for the multicast case
and considering a reuse time greater than MIN_TOKEN_REUSE_TIME.  If
an alternative security protocol for Group CoAP is defined in the
future and it does not ensure secure binding between requests and
responses, a client MUST follow the Token processing requirements for
the unicast case discussed above, as defined in I-D.ietf-core-echo-
request-tag.
Paragraph (version B):
than MIN_TOKEN_REUSE_TIME = 500 seconds.
Paragraph (version A):
Since a client sending a multicast request with a Token T will accept
multiple responses with the same Token T, there is a risk that the
same server sends multiple responses with the same Token T back to
the client.  For example, this server might not implement the
optional CoAP message deduplication based on Message ID, or it might
be a malicious/compromised server acting out of specification.  To
mitigate issues with multiple responses from one server bound to a
same multicast request, the client has to ensure that, as long as the
the CoAP Token used for a multicast request is retained, at most one
response to that request per server is accepted, with the exception
of Observe notifications RFC7641 (see sec-observe).
Paragraph (version A):
To this end, upon receiving a response corresponding to a multicast
request, the client MUST perform the following actions.  First, the
client checks whether it previously received a valid response to this
request from the same originating server of the just-received
response.  If the check yields a positive match and the response is
not an Observe notification (i.e., it does not include an Observe
option), the client SHALL stop processing the response.  Upon
eventually freeing up the Token value of a multicast request for
possible reuse, the client MUST also delete the list of responding
servers associated to that request.
Paragraph (version B):
When this happens, the client normally processes at the CoAP layer
each of those responses to the same request coming from the same
server.  If the processing of a response is successful, the client
delivers this response to the application as usual.
Paragraph (version B):
Then, the application is in a better position to decide what to do,
depending on the available context information.  For instance, it
might accept and process all the responses from the same server, even
if they are not Observe notifications (i.e., they do not include an
Observe option).  Alternatively, the application might accept and
process only one of those responses, such as the most recent one from
that server, e.g. when this can trigger a change of state within the
application.
Paragraph (version B):
CoAP endpoints that are members of a CoAP group MAY cache responses
to a group request as defined in Section 5.6 of RFC7252.  In
particular, these same rules apply to determine the set of request
options used as "Cache-Key".
Paragraph (version B):
A client MAY revalidate a cached response by making a GET or FETCH
request on the related unicast request URI.
Paragraph (version B):
Note that, in the presence of proxies, doing any of the above
(optional) unicast requests requires the client to distinguish the
different responses to a group request, as well as to distinguish the
different origin servers that responded.  This in turn requires
additional means to provide the client with information about the
origin server of each response, as discussed in sec-proxy-caching.
Paragraph (version B):
The following subsections define the freshness model and validation
model to use for cached responses, which update the models defined in
Section 5.6.1 and Section 5.6.2 of RFC7252, respectively.
Paragraph (version B):
For caching at endpoints, the same freshness model relying on the
Max-Age Option as defined in Section 5.6.1 of RFC7252 applies.
Paragraph (version B):
For caching at proxies, the freshness model defined in sec-proxy-
caching of this specification applies.
Paragraph (version B):
Section 5.6.2 of RFC7252 defines a model to "validate" or
"revalidate" responses stored in cache, hence enabling the
suppression of responses that the client already has.
Paragraph (version B):
This relies on the ETag Option defined in Section 5.10.6 of RFC7252,
with its usage limited to exchanges between a CoAP client and one
CoAP server.  That is, Section 8.2.1 of RFC7252 explicitly forbids
using an ETag Option in requests sent over multicast, and leaves a
mechanism to suppress responses for that case for further study.
Paragraph (version B):
This section provides such a model to "validate" or "revalidate"
responses that the client already has cached.  In particular, the
group request can indicate entity-tag values separately for each CoAP
server from which the client wishes to get a response revalidation,
together with addressing information identifying that server.
Paragraph (version B):
To this end, this specification defines the new Multi-ETag Option.
Operations related to this validation model and using the new option
are defined in sec-caching-validation-client for the client side, and
in sec-caching-validation-server for the server side.
Paragraph (version B):
The Multi-ETag Option has the properties summarized in fig-response-
multi-etag-option, which extends Table 4 of RFC7252.  The Multi-ETag
Option is elective, safe to forward, part of the cache key, and
repeatable.
Paragraph (version B):
The option is intended only for group requests, as directly sent to a
CoAP group or to a CoAP proxy that forwards it to the CoAP group (see
sec-proxy).
Paragraph (version B):
The Multi-ETag Option has the same properties of the ETag Option
defined in Section 5.10.6 of RFC7252, but it differs in the format
and length, as well as having a different reason for its
repeatability.
Paragraph (version B):
The first element specifies the addressing information of the
corresponding server, encoded as defined in sec-caching-
validation-tpinfo.
Paragraph (version B):
This mirrors the format of the Multicast-Signaling option defined
in Section 3 of I-D.tiloca-core-groupcomm-proxy.  Thus, in the
presence of a forward proxy supporting the mechanism defined in I-
D.tiloca-core-groupcomm-proxy, the client can seamlessly use the
server addressing information obtained from the proxy, when this
forwards back a response to a group request from that server.
Paragraph (version B):
The following M elements are CBOR byte strings, each of which has
as value an entity-tag value that the client wants to try against
the corresponding server.
Paragraph (version B):
The entity-tag values included in the Multi-ETag Option are
subject to the same considerations for the entity-tag values used
in an ETag Option (see Section 5.10.6 of RFC7252).
Paragraph (version B):
The Multi-ETag Option is of class E in terms of OSCORE processing
(see Section 4.1 of RFC8613).
Paragraph (version B):
The first element of the CBOR sequence in the Multi-ETag Option value
is set to the byte serialization of the CBOR array 'tp_info' defined
in Section 2.2.1 of I-D.tiloca-core-observe-multicast-notifications,
including only the set of elements 'srv_addr'.
Paragraph (version B):
In turn, the set includes the integer 'tp_id' identifying the used
transport protocol, and further elements whose number, format and
encoding depend on the value of 'tp_id'.
Paragraph (version B):
When the Multi-ETag Option is used in group requests transported over
UDP as in this specification, the 'tp_info' array includes the
following elements, encoded as defined in Section 2.2.1.1 of I-
D.tiloca-core-observe-multicast-notifications.
Paragraph (version B):
'srv_host': a CBOR byte string, with value the unicast IP address
of the server.  This element is tagged and identified by the CBOR
tag 260 "Network Address (IPv4 or IPv6 or MAC Address)".
Paragraph (version B):
'srv_port': as a CBOR unsigned integer or the CBOR simple value
Null.  If it is a CBOR integer, it has as value the destination
port number where to send individual requests intended to the
server.  This element MAY be present.  If not included, the
default port number 5683 is assumed.
Paragraph (version B):
The CDDL notation RFC8610 provided below describes the 'tp_info' CBOR
array using the format above.
Paragraph (version B):
Similar to what is defined in Section 5.6.2 of RFC7252, the client
may have one or more stored responses for a GET or FETCH group
request sent to the CoAP group, but cannot use any of them (e.g.
because they are not fresh).
Paragraph (version B):
In that case, the client can send a GET or FETCH group request, in
order to give the origin servers an opportunity both to select a
stored response to be used, and to update its freshness.  As in
RFC7252, this process is known as "validating" or "revalidating" the
stored response.
Paragraph (version B):
When sending such a group request, the endpoint SHOULD include one
Multi-ETag Option for each server it wishes to revalidate the
corresponding response with.  As defined in sec-caching-validation,
the Multi-ETag Option can include multiple entity-tag values, each
applicable to a stored response from the corresponding server for
that group request.
Paragraph (version B):
The client MUST NOT include one or more ETag Option(s) together
with one or more Multi-ETag Option(s).
Paragraph (version B):
The client MUST include only one Multi-ETag Option for each server
it wishes to get a response revalidation from.
Paragraph (version B):
The client SHOULD limit the number of Multi-ETag Options, hence
limiting the number of servers as intended target of the
revalidation process, and SHOULD rather spread revalidation with
different sets of servers over different group requests.  Also,
the client SHOULD limit the number of entity-tag values specified
in each Multi-ETag Option, preferably indicating only one entity-
tag value.
Paragraph (version B):
This allows for limiting the overall size of the group request.
As a guideline, the server addressing information can be 9-24
bytes in size, while each entity-tag value can be 1-8 bytes in
size.  Thus, a single Multi-ETag Option can be up to (24 + 8 * M)
bytes in size, where M is the number of entity-tag values it
includes.
Paragraph (version B):
A 2.03 (Valid) response indicates that the stored response identified
by the entity-tag given in the response's ETag Option can be reused,
after updating the stored response as described in Section 5.9.1.3 of
RFC7252.  So the client can determine if any one of the stored
representations from that server is current, without need to transfer
the current resource representation again.
Paragraph (version B):
Any other Response Code indicates that none of the stored responses
from that server, identified in the Multi-ETag Option of the group
request, are suitable.  Instead, such response SHOULD be used to
satisfy the request and MAY replace the stored response.
Paragraph (version B):
If a GET or FETCH request includes both one or more ETag Options
together with one or more Multi-ETag Options, then the server MUST
ignore all the included ETag and Multi-ETag Options.
Paragraph (version B):
The server MUST ignore any Multi-ETag Option which is malformed, or
included in a request that is neither GET nor FETCH, or which
specifies addressing information not matching with its own endpoint
address.
Paragraph (version B):
The server considers only its pertaining Multi-ETag Option, i.e.
specifying addressing information associated to its own endpoint.
The server MUST ignore any pertaining Multi-ETag Option that occurs
more than once.
Paragraph (version B):
If the pertaining Multi-ETag Option specifies the CBOR simple value
Null for the 'srv_port' element of 'tp_info' (see sec-caching-
validation-tpinfo), the server MUST assume the default port number
5683.
Paragraph (version B):
Then, the server can issue a 2.03 (Valid) response in place of a 2.05
(Content) response, if one of the entity-tag values from the
pertaining Multi-ETag Option is the entity-tag for the current
resource representation, i.e. it is valid.  The 2.03 (Valid) response
echoes this specific entity-tag within an ETag Option included in the
response.
Paragraph (version B):
The inclusion of an ETag Option in a response works as defined in
Section 5.6.10.1 of RFC7252.
Paragraph (version A):
A server that is a member of a CoAP group listens for CoAP messages
on the group's IP multicast address, usually on the CoAP default UDP
port 5683, or another non-default UDP port if configured.  Regardless
of the method for selecting the port number, the same port number
MUST be used across all CoAP servers that are members of a CoAP group
and across all CoAP clients performing the requests to that group.
The URI Path used in the request is preferably a path that is known
to be supported across all group members.  However there are valid
use cases where a request is known to be successful 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 multicast request or respond with an error
status code.
Paragraph (version A):
One way to create multiple CoAP groups is using different UDP ports
with the same IP multicast address, in case the devices' network
stack only supports a limited number of multicast address
subscriptions.  However, it must be taken into account that this
incurs additional processing overhead on each CoAP server
participating in at least one of these groups: messages to groups
that are not of interest to the node are only discarded at the higher
transport (UDP) layer instead of directly at the network (IP) layer.
Paragraph (version A):
Port 5684 is reserved for DTLS-secured CoAP and MUST NOT be used for
any CoAP group communication.
Paragraph (version B):
One way to create multiple CoAP groups is using different UDP ports
with the same IP multicast address, in case the devices' network
stack only supports a limited number of multicast address
subscriptions.  However, it must be taken into account that this
incurs additional processing overhead on each CoAP server
participating in at least one of these groups: messages to groups
that are not of interest to the node are only discarded at the higher
transport (UDP) layer instead of directly at the network (IP) layer.
Also, a constrained network may be additionally burdened in this case
with multicast traffic that is eventually discarded at the UDP layer
by most nodes.
Paragraph (version B):
Port 5684 is reserved for DTLS-secured unicast CoAP and MUST NOT be
used for any CoAP group communication.
Paragraph (version B):
This section defines how proxies operate in a group communication
scenario.  In particular, sec-proxy-forward defines operations of
forward-proxies, sec-proxy-reverse defines operations of reverse-
proxies, and sec-proxy-caching defines operations of proxies that
employ a cache for responses to group requests.
Paragraph (version A):
A method based on this approach and addressing the issues raised
above is defined in I-D.tiloca-core-groupcomm-proxy.
Paragraph (version A):
The proxy does not know how many members there are in the CoAP
group or how many group members will actually respond.  Also, the
proxy does not know for how long to collect responses before
sending back the aggregated response to the client.  A CoAP client
that is not using a Proxy might face the same problems in
collecting responses to a multicast request.  However, the client
itself would typically have application-specific rules or
knowledge on how to handle this situation, while an application-
agnostic CoAP Proxy would typically not have this knowledge.  For
example, a CoAP client could monitor incoming responses and use
this information to decide how long to continue collecting
responses - which is something a proxy cannot do.
Paragraph (version B):
A forward-proxying method using this approach and addressing the
issues raised above is defined in I-D.tiloca-core-groupcomm-proxy.
Paragraph (version B):
Like for the approach discussed above, the proxy does not know for
how long to collect responses before sending back the aggregated
response to the client.  Analogous considerations apply to this
approach too, both on the client and proxy side.
Paragraph (version A):
Due to the above issues, it is RECOMMENDED that a CoAP Proxy only
processes a group URI request if it is explicitly enabled to do so.
The default response (if the function is not explicitly enabled) to a
group URI request is 5.01 (Not Implemented).  Furthermore, a proxy
SHOULD be explicitly configured (e.g. by white-listing and/or client
authentication) to allow proxied CoAP multicast requests only from
specific client(s).
Paragraph (version B):
CoAP enables the use of a reverse-proxy, as an endpoint that stands
in for one or more other server(s), and satisfies requests on behalf
of these, doing any necessary translations (see Section 5.7.3 of
RFC7252).
Paragraph (version B):
Furthermore, the reverse-proxy can actually stand in for (and thus
prevent to directly reach) 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 three issues and limitations defined in sec-proxy-forward for
a forward proxy apply to a reverse-proxy as well, and have to be
addressed, e.g. using the signaling method defined in I-D.tiloca-
core-groupcomm-proxy or other means.
Paragraph (version B):
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 client that is configured to access a reverse-proxy resource
(i.e. one that triggers a CoAP group communication request) SHOULD
be configured also to handle potentially multiple responses with
the same Token value caused by a single request.
Paragraph (version B):
That is,the client needs to preserve the Token value used for the
request also after the reception of the first response forwarded
back by the proxy (see sec-request-response) and keep the request
open to potential further responses with this Token.  This
requirement can be met by a combination of client implementation
and proper proxied group communication configuration on the
client.
Paragraph (version B):
A client might re-use a Token value in a valid new request to the
reverse-proxy, while the reverse-proxy still has an ongoing group
communication request for this client with the same Token value
(i.e. its time period for response collection has not ended yet).
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 B):
If the reverse-proxy supports the signalling protocol of I-
D.tiloca-core-groupcomm-proxy it can include a Multicast-Signaling
Option in the error response to convey the reason for the error in
a machine-readable way.
Paragraph (version B):
For the operation of HTTP-to-CoAP reverse proxies, see the last
paragraph of sec-proxy-forward which applies also to this case.
Paragraph (version B):
A proxy that supports forwarding of group requests and that employs a
cache maintains the following two types of cache entry.
Paragraph (version B):
The first type, "individual" cache entry, is associated to one
server and stores one response from that server, regardless
whether it is a response to a unicast request or to a group
request.
Paragraph (version B):
A hit to this entry would be produced by a matching request
intended to that server, i.e. to the corresponding unicast URI.
Paragraph (version B):
When the response is a response to a unicast request to the
server, the unicast URI is the same target URI used for the
request.
Paragraph (version B):
When the response is a response to a group request to the CoAP
group, the unicast URI is obtained by replacing the authority part
of the group URI in the group request with the transport-layer
source address and port number of the response message.
Paragraph (version B):
The second type, "aggregated" cache entry, is associated to the
CoAP group, and stores all the responses that: the proxy has
received as a response to a group request to that group; and that
have been also forwarded back to the client that sent the group
request.
Paragraph (version B):
A hit to this entry would be produced by a matching group request
intended to the CoAP group, i.e. to the corresponding group URI.
Paragraph (version B):
When forwarding a group request to a CoAP group using the request's
group URI and processing the responses, the proxy handles its cache
entries as follows.  The same applies if the proxy spontaneously re-
sends a group request to the CoAP group, in order to refresh an
aggregated cache entry after its expiration or invalidation.
Paragraph (version B):
The proxy creates or refreshes the individual cache entry
associated to the origin server and for that response.  That
is, the response is stored in the individual cache entry, and
the lifetime of the cache entry is set to the lifetime of the
response, as indicated by the Max-Age Option if present, or as
the default value of 60 seconds otherwise (see Section 5.6.1 of
RFC7252).  This cache entry becomes immediately usable to serve
requests from clients.
Paragraph (version B):
The proxy adds the response to a temporary list L.
Paragraph (version B):
The proxy creates an aggregated cache entry associated to the
group for that group request, if not existing yet.  In case of
an existing entry to be refreshed, the proxy deletes all the
responses stored in the entry.
Paragraph (version B):
The proxy stores all the responses from the list L in the
aggregated cache entry.
Paragraph (version B):
The proxy sets the lifetime of the cache entry to the smallest
lifetime among all the responses stored in the entry,
determined in the same way as defined in step 1 above.
Paragraph (version B):
The proxy sets the aggregated cache entry as usable to serve
group requests from clients.
Paragraph (version B):
When forwarding a request to an individual server using the
associated unicast URI and processing its response, the proxy handles
its cache entries as follows.  The same applies if the proxy
spontaneously re-sends a unicast request to a single server, in order
to refresh an individual cache entry after its expiration or
invalidation.
Paragraph (version B):
The proxy creates or refreshes the individual cache entry
associated to the origin server and for that response.  That is,
the response is stored in the cache entry, and the lifetime of the
cache entry is set to the lifetime of the response, as indicated
by the Max-Age Option if present, or as the default value of 60
seconds otherwise (see Section 5.6.1 of RFC7252).  This cache
entry becomes immediately usable to serve requests from clients.
Paragraph (version B):
The proxy checks whether it has a non-expired and valid aggregated
cache entry, such that a hit would be produced by a group request
analogous to the forwarded unicast request.
Paragraph (version B):
That is, such group request would be intended to the group URI of
the CoAP group associated to the aggregated cache entry, rather
than intended to the unicast URI of the forwarded request.
Paragraph (version B):
The proxy stores the received response in the aggregated cache
entry, possibly replacing an already stored instance of that
response from that origin server.
Paragraph (version B):
The proxy sets as new lifetime of the aggregated cache entry
the minimum value between the current lifetime of the cache
entry and the lifetime of the just-stored response, as
indicated by the Max-Age Option if present, or as the default
value of 60 seconds otherwise (see Section 5.6.1 of RFC7252).
Paragraph (version B):
Note that a proxy embedded in a router can monitor network control
messages, hence learning when a new server has joined a CoAP group
and is listening to the multicast IP address of that CoAP group.
This information could be used to guide the proxy in refreshing an
aggregated cache entry, by sending a request to the CoAP group over
the group URI before the entry expires, and thus storing also a
response from the newly joined server.
Paragraph (version B):
Following the expiration or invalidation of a cache entry, as well as
if wishing to refresh a cache entry, the proxy can directly interact
with the servers in the CoAP group.  To this end, it takes the role
of a CoAP client as defined in sec-caching.  In particular, the proxy
can perform revalidation of responses to group requests by using the
Multi-ETag Option, as defined in sec-caching-validation.
Paragraph (version B):
As further discussed in chap-sec-group-caching, additional means are
required to enable cachability of responses at the proxy when
communications in the group are secured with Group OSCORE I-D.ietf-
core-oscore-groupcomm.
Paragraph (version B):
A client can revalidate the full set of responses to a group request
from the corresponding aggregated cache entry at the proxy.  To this
end, this specification defines the new Group-ETag Option.
Paragraph (version B):
The Group-ETag Option has the properties summarized in fig-response-
group-etag-option, which extends Table 4 of RFC7252.  The Group-ETag
Option is elective, safe to forward, part of the cache key, and
repeatable.
Paragraph (version B):
The option is intended for group requests sent to a Forward-Proxy, as
well as for the associated responses retrieved from the corresponding
aggregated cache entry at the proxy.
Paragraph (version B):
The Group-ETag Option has the same properties of the ETag Option
defined in Section 5.10.6 of RFC7252.
Paragraph (version B):
The Group-ETag Option is of class U in terms of OSCORE processing
(see Section 4.1 of RFC8613).
Paragraph (version B):
When providing 2.05 (Content) responses to a GET or FETCH group
request from an aggregated cache entry, the proxy can include one
Group-ETag Option, specifying the current entity-tag value associated
to that cache entry.  Each of such responses MUST NOT include more
than one Group-ETag Option.
Paragraph (version B):
If the proxy supports this form of response revalidation, it MUST
update the current entity-tag value associated to an aggregated cache
entry, every time a response is added to that cache entry or replaces
an already included response.
Paragraph (version B):
When sending a GET or FETCH group request to the proxy, to be
forwarded to a CoAP group, the client can include one or more Group-
ETag Option(s).  Each option specifies one entity-tag value, as
applicable to the aggregated cache entry for that group request.
Paragraph (version B):
In case the group request hits an aggregated cache entry and its
current entity-tag value matches with one of the entity-tag value(s)
specified in the Group-ETag option(s), then the proxy replies with a
single 2.03 (Valid) response.  This response has no payload and MUST
include one Group-ETag Option, specifying the current entity-tag
value of the aggregated cache entry.
Paragraph (version B):
That is, the 2.03 (Valid) response from the proxy indicates that the
stored responses idenfied by the entity-tag given in the response's
Group-ETag Option can be reused, after updating each of them as
described in Section 5.9.1.3 of RFC7252.  In effect, the client can
determine if any of the stored set of representations from the
aggregated cache entry at the proxy is current, without needing to
transfer any of them again.
Paragraph (version B):
Note that, if a client triggers the proxy to perform forwarding of a
group request (i.e., there is no hit of an aggregated cache entry),
this will result in a new aggregated cache entry created at the
proxy.  Then, the client cannot obtain an entity-tag value through a
Group-ETag Option in any of the responses forwarded back by the
proxy.
Paragraph (version B):
In fact, the proxy will only have an assigned entity-tag value to
provide after all responses have been forwarded back to that client,
which is the moment that the new aggregated cache entry is eventually
created.  However, when follow-up group requests from the same client
or different clients are served from this aggregated cache entry, the
proxy can include a Group-ETag Option in each returned response,
specifying the current entity-tag for the aggregated cache entry.
Paragraph (version A):
A server in a constrained network should only support group
communication with GET and FETCH for resources that are small.
This can consist, for example, in having the payload of the
response as limited to approximately 5% of the IP Maximum Transmit
Unit (MTU) size, so that it fits into a single link-layer frame in
case IPv6 over Low-Power Wireless Personal Area Networks (6LoWPAN)
(see Section 4 of RFC4944) is used.
Paragraph (version A):
This section updates RFC7641 with the use of the Observe Option in a
CoAP multicast GET request, and defines normative behavior for both
client and server.  Consistently with Section 2.4 of RFC8132, it is
also possible to use the Observe Option in a CoAP multicast FETCH
request.
Paragraph (version A):
A client that has sent a multicast GET or FETCH request with the
Observe Option MAY follow up by sending a new unicast CON request
with the same Token value and same Observe Option value to a
particular server, in order to ensure that the particular server
receives the request.  This is useful in case a specific group
member, that was expected to respond to the initial group request,
did not respond to the initial request.  In this case, the client
always uses a Message ID that differs from the initial multicast
message.
Paragraph (version A):
Furthermore, consistently with Section 3.3.1 of RFC7641 and following
its guidelines, a client MAY at any time send a new multicast GET or
FETCH request with the same Token value and same Observe Option value
as the original request.  This allows the client to verify that it
has an up-to-date representation of an observed resource and/or to
re-register its interest to observe a resource.
Paragraph (version A):
A server that receives a GET or FETCH request with the Observe
Option, for which request processing is successful, SHOULD respond to
this request and not suppress the response.  A server that adds a
client to the list of observers for a resource due to an Observe
request MUST respond to this request and not suppress it.
Paragraph (version B):
A server that receives a GET or FETCH request with the Observe
Option, for which request processing is successful, SHOULD respond to
this request and not suppress the response.  A server that adds a
client to the list (as a new entry) of observers for a resource due
to an Observe request MUST respond to this request and not suppress
it.
Paragraph (version A):
A client can use the unicast cancellation methods of Section 3.6 of
RFC7641 and stop the ongoing observation of a particular resource on
members of a CoAP group.  This can be used to remove specific
observed servers, or even all servers in the group.  In addition, a
client MAY explicitly deregister from all those servers at once, by
sending a multicast GET or FETCH request that includes the Token
value of the observation to be cancelled and includes an Observe
Option with the value set to 1 (deregister).  In case not all the
servers in the CoAP group received this deregistration request,
either the unicast cancellation methods can be used or the multicast
deregistration request MAY be repeated upon receiving another observe
response from a server.
Paragraph (version A):
For observing a group of servers through a CoAP-to-CoAP proxy, the
limitations stated in sec-proxy apply.  The method defined in I-
D.tiloca-core-groupcomm-proxy enables group communication through
proxies and addresses those limitations.
Paragraph (version A):
Section 2.8 of RFC7959 specifies how a client can use block-wise
transfer (Block2 Option) in a multicast GET request to limit the size
of the initial response of each server.  Consistently with
Section 2.5 of RFC8132, the same can be done with a multicast FETCH
request.
Paragraph (version B):
For observing a group of servers through a CoAP-to-CoAP proxy, the
limitations stated in sec-proxy apply.  The method defined in I-
D.tiloca-core-groupcomm-proxy enables group communication including
resource observation through proxies and addresses those limitations.
Paragraph (version B):
Section 2.8 of RFC7959 specifies how a client can use block-wise
transfer (Block2 Option) in a multicast GET request to limit the size
of the initial response of each server.  Consistent with Section 2.5
of RFC8132, the same can be done with a multicast FETCH request.
Paragraph (version A):
In 6LoWPAN RFC4944 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.  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 A):
The MLDv2 protocol RFC3810 is the standard IPv6 method to achieve
this; therefore, this method SHOULD be used by members of a CoAP
group to subscribe to its multicast IPv6 address, on IPv6 networks
that support it.  CoAP server nodes then act in the role of MLD
Multicast Address Listener.  Constrained IPv6 networks that implement
either RPL (see sec-rpl) or MPL (see sec-mpl) typically do not
support MLD as they have their own mechanisms defined.
Paragraph (version B):
The MLDv2 protocol RFC3810 is the standard IPv6 method to achieve
this; therefore, this method SHOULD be used by members of a CoAP
group to subscribe to its multicast IPv6 address, on IPv6 networks
that support it.  CoAP server nodes then act in the role of MLD
Multicast Address Listener.  MLDv2 uses link-local communication
between Listeners and IP multicast routers.  Constrained IPv6
networks that implement either RPL (see sec-rpl) or MPL (see sec-mpl)
typically do not support MLDv2 as they have their own mechanisms
defined for subscribing to multicast groups.
Paragraph (version A):
The same DAO mechanism can be used to convey CoAP group membership
information to an edge router (e.g., 6LBR), in case the edge router
is also the root of the RPL Destination-Oriented Directed Acyclic
Graph (DODAG).  This is useful because the edge router then learns
which IP multicast traffic it needs to pass through from the backbone
network into the LLN subnet.  In LLNs, such ingress filtering helps
to avoid congestion of the resource-constrained network segment, due
to IP multicast traffic from the high-speed backbone IP network.
Paragraph (version B):
The same DAO mechanism can be used to convey CoAP group membership
information to an edge router (e.g., 6LBR), in case the edge router
is also the root of the RPL Destination-Oriented Directed Acyclic
Graph (DODAG).  This is useful because the edge router then learns
which IP multicast traffic it needs to pass through from the backbone
network into the LLN subnet, and which traffic not.  In LLNs, such
ingress filtering helps to avoid congestion of the resource-
constrained network segment, due to IP multicast traffic from the
high-speed backbone IP network.
Paragraph (version A):
Manual configuration on the ingress MPL Forwarder.
Paragraph (version A):
A protocol to register multicast groups at an ingress MPL
Forwarder.  This could be a protocol offering features similar to
MLDv2.
Paragraph (version B):
Manual configuration on each ingress MPL Forwarder.
Paragraph (version B):
MLDv2 protocol, which works only in case all CoAP servers joining
a group are in link-local communication range of an ingress MPL
Forwarder.  This is typically not the case on mesh networks.
Paragraph (version B):
A new/custom protocol to register multicast groups at an ingress
MPL Forwarder.  This could be for example a CoAP-based protocol
offering multicast group subscription features similar to MLDv2.
Paragraph (version A):
OSCORE uses COSE I-D.ietf-cose-rfc8152bis-algs to perform encryption
operations and protect a CoAP message in a COSE object, by using an
Authenticated Encryption with Associated Data (AEAD) algorithm.  In
particular, OSCORE takes as input an unprotected CoAP message and
transforms it into a protected CoAP message transporting the COSE
object.
Paragraph (version B):
OSCORE uses COSE I-D.ietf-cose-rfc8152bis-algs to perform encryption
operations and protect a CoAP message carried in a COSE object, by
using an Authenticated Encryption with Associated Data (AEAD)
algorithm.  In particular, OSCORE takes as input an unprotected CoAP
message and transforms it into a protected CoAP message transporting
the COSE object.
Paragraph (version A):
The first method, namely group mode, relies on digital signatures.
That is, sender devices sign their outgoing messages using their own
private key, and embed the signature in the protected CoAP message.
Paragraph (version A):
The second method, namely pairwise mode, relies on a symmetric key,
which is derived from a pairwise shared secret computed from the
asymmetric keys of the message sender and recipient.  This method is
intended for one-to-one messages sent in the group, such as all
responses as individually sent by servers, as well as requests
addressed to an individual server.
Paragraph (version A):
A Group Manager is responsible for one or multiple OSCORE groups.  In
particular, the Group Manager acts as repository of public keys of
group members; manages, renews and provides security material in the
group; and handles the join process of new group members.
Paragraph (version B):
The first method, called group mode, relies on digital signatures.
That is, sender devices sign their outgoing messages using their own
private key, and embed the signature in the protected CoAP message.
Paragraph (version B):
The second method, called pairwise mode, relies on a symmetric key,
which is derived from a pairwise shared secret computed from the
asymmetric keys of the message sender and recipient.  This method is
intended for one-to-one messages sent in the group, such as all
responses individually sent by servers, as well as requests addressed
to an individual server.
Paragraph (version B):
A Group Manager is responsible for managing one or multiple OSCORE
groups.  In particular, the Group Manager acts as repository of
public keys of group members; manages, renews and provides security
material in the group; and handles the join process of new group
members.
Paragraph (version A):
A CoAP endpoint can discover OSCORE groups and retrieve information
to join them through their 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 I-D.ietf-core-resource-directory.
Paragraph (version A):
All members of the CoAP group, i.e. the CoAP endpoints configured
(also) as CoAP servers and listening to the group's multicast IP
address.
Paragraph (version B):
When using Group OSCORE to protect communications end-to-end between
a client and multiple servers in the group, it is normally not
possible for an intermediary proxy to cache protected responses.
Paragraph (version B):
In fact, when starting from the same plain CoAP message, different
clients generate different protected requests to send on the wire.
This prevents different clients to generate potential cache hits, and
thus makes response caching at the proxy pointless.
Paragraph (version B):
For application scenarios that require secure group communication, it
is still possible to achieve cachability of responses at proxies, by
using the approach defined in I-D.amsuess-core-cachable-oscore which
is based on Deterministic Requests protected with the pairwise mode
of Group OSCORE.  This approach is limited to group requests that are
safe (in the RESTful sense) to process and do not yield side effects
at the server.  As for any protected group request, it requires the
clients and all the servers in the CoAP group to have already joined
the correct OSCORE group.
Paragraph (version B):
Starting from the same plain CoAP request, this allows different
clients in the OSCORE group to deterministically generate a same
request protected with Group OSCORE, which is sent to the proxy for
being forwarded to the CoAP group.  The proxy can now effectively
cache the resulting responses from the servers in the CoAP group,
since the same plain CoAP request will result again in the same
Deterministic Request and thus will produce a cache hit.
Paragraph (version B):
When caching of Group OSCORE secured responses is enabled at the
proxy, the same as defined in sec-proxy-caching applies, with respect
to cache entries and their lifetimes.
Paragraph (version B):
Note that different Deterministic Requests result in different cache
entries at the proxy.  This includes the case where different plain
group requests differ only in their set of Multi-ETag Options.
Paragraph (version B):
That is, even though the servers would produce the same plain CoAP
responses in reply to the different Deterministic Requests, those
will result in different protected responses to each respective
Deterministic Request, and hence in different cache entries at the
proxy.
Paragraph (version B):
Thus, given a plain group request, a client needs to reuse the same
set of Multi-ETag Options, in order to send that group request as a
Deterministic Request that can actually produce a cache hit at the
proxy.  However, while this would prevent the caching at the proxy to
be inefficient and unnecessarily redundant, it would also limit the
flexibility of end-to-end response revalidation for a client.
Paragraph (version B):
When directly interacting with the servers in the CoAP group to
refresh its cache entries, the proxy cannot rely on response
revalidation anymore.  In fact, responses protected with Group OSCORE
cannot have 2.03 (Valid) as Outer Code.  Response revalidation
remains possible end-to-end between the client and the servers in the
group, by means of including inner ETag Option(s) or inner Multi-ETag
Option(s).
Paragraph (version B):
Finally, it is not possible for a client to revalidate responses to a
group request from an aggregated cache entry at the proxy, by using
the outer Group-ETag Option as defined in sec-proxy-caching-valid.
In fact, that would require the proxy to respond with an unprotected
2.03 (Valid) response potentially.  However, success responses have
to be protected with Group OSCORE, so cannot have 2.03 (Valid) as
Outer Code.
Paragraph (version A):
In fact, it may be desirable to not rekey the group upon every single
membership change, in case members' joining and leaving are frequent,
and at the same time a single group rekeying instance takes a non
negligible time to complete.
Paragraph (version A):
In such a case, the Group Manager may 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 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 fact, it may be desirable to not rekey the group upon every single
membership change, in case members' joining and leaving are frequent,
and at the same time a single group rekeying instance takes a non-
negligible time to complete.
Paragraph (version B):
In such a case, the Group Manager may 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 A):
Since Group OSCORE provides end-to-end confidentiality and
integrity of request/response messages, proxies in multicast
settings cannot break message protection, and thus cannot act as
man-in-the-middle beyond their legitimate duties (see Section 11.2
of RFC7252).  In fact, intermediaries such as proxies are not
assumed to have access to the OSCORE Security Context used by
group members.  Also, with the notable addition of
countersignatures for the group mode, Group OSCORE protects
messages using the same constructions of OSCORE (see Sections 8.1
and 8.3 of I-D.ietf-core-oscore-groupcomm), and especially
processes CoAP options according to the same classification in
U/I/E classes.
Paragraph (version A):
Group OSCORE does not require group members to be equipped with a
good source of entropy for generating security material (see
Section 11.6 of RFC7252), and thus does not contribute to create
an attack vector against such (constrained) CoAP endpoints.  In
particular, the symmetric keys used for message encryption and
decryption are derived through the same HMAC-based HKDF scheme
used for OSCORE (see Section 3.2 of RFC8613).  Besides, the OSCORE
Master Secret used in such derivation is securely generated by the
Group Manager responsible for the OSCORE group, and securely
provided to the CoAP endpoints when they join the group.
Paragraph (version B):
Group OSCORE does not require group members to be equipped with a
good source of entropy for generating security material (see
Section 11.6 of RFC7252), and thus does not contribute to create
an entropy-related attack vector against such (constrained) CoAP
endpoints.  In particular, the symmetric keys used for message
encryption and decryption are derived through the same HMAC-based
HKDF scheme used for OSCORE (see Section 3.2 of RFC8613).
Besides, the OSCORE Master Secret used in such derivation is
securely generated by the Group Manager responsible for the OSCORE
group, and securely provided to the CoAP endpoints when they join
the group.
Paragraph (version A):
Since all requests sent over IP multicast are Non-confirmable, a
client might not be able to know if an adversary has actually
captured one of its trasmitted requests and later re-injected it in
the group as a replay to the server nodes.  In fact, even if the
servers sent back responses to the replayed request, the client would
not have a valid matching request anymore to suspect of the attack.
Paragraph (version B):
Since all requests sent over IP multicast are Non-confirmable, a
client might not be able to know if an adversary has actually
captured one of its transmitted requests and later re-injected it in
the group as a replay to the server nodes.  In fact, even if the
servers sent back responses to the replayed request, the client would
typically not have a valid matching request active anymore so this
attack would not accomplish anything in the client.
Paragraph (version A):
In a 6LoWPAN network, a multicast IPv6 packet may be fragmented prior
to transmission.  A 6LoWPAN Router that forwards a fragmented packet
can have a relatively high impact on the occupation of the wireless
channel and on the memory load of the local node due to packet buffer
occupation.  For example, the MPL RFC7731 protocol requires an MPL
Forwarder to store the packet for a longer duration, to allow
multiple forwarding transmissions to neighboring Forwarders.  If only
one of the fragments is not received correctly by an MPL Forwarder,
the receiver needs to discard all received fragments and it needs to
receive all the packet fragments again on a future occasion.
Paragraph (version A):
For these reasons, a fragmented IPv6 multicast packet is a possible
attack vector in a Denial of Service (DoS) amplification attack.  See
Section 11.3 of RFC7252 for more details on amplification.  To
mitigate the risk, applications sending multicast IPv6 requests to
6LoWPAN hosted CoAP servers SHOULD limit the size of the request to
avoid 6LoWPAN fragmentation.  A 6LoWPAN Router or multicast forwarder
SHOULD deprioritize forwarding for multi-fragment 6LoWPAN multicast
packets.  Also, a 6LoWPAN Border Router SHOULD implement multicast
packet filtering to prevent unwanted multicast traffic from entering
a 6LoWPAN network from the outside.  For example, it could filter out
all multicast packet for which there is no known multicast listener
on the 6LoWPAN network.
Paragraph (version B):
In a 6LoWPAN network, a multicast IPv6 packet may be fragmented prior
to transmission.  A 6LoWPAN Router that forwards a fragmented packet
may have a relatively high impact on the occupation of the wireless
channel and may locally experience high memory load due to packet
buffering.  For example, the MPL RFC7731 protocol requires an MPL
Forwarder to store the packet for a longer duration, to allow
multiple forwarding transmissions to neighboring Forwarders.  If one
or more of the fragments are not received correctly by an MPL
Forwarder during its packet reassembly time window, the Forwarder
discards all received fragments and at a future point in time it
needs to receive again all the packet fragments (this time, possibly
from another neighboring MPL Forwarder).
Paragraph (version B):
For these reasons, a fragmented IPv6 multicast packet is a possible
attack vector in a Denial of Service (DoS) amplification attack.  See
Section 11.3 of RFC7252 for more details on amplification.  To
mitigate the risk, applications sending multicast IPv6 requests to
6LoWPAN hosted CoAP servers SHOULD limit the size of the request to
avoid 6LoWPAN fragmentation of the request packet.  A 6LoWPAN Router
or multicast forwarder SHOULD deprioritize forwarding for multi-
fragment 6LoWPAN multicast packets.  Also, a 6LoWPAN Border Router
SHOULD implement multicast packet filtering to prevent unwanted
multicast traffic from entering a 6LoWPAN network from the outside.
For example, it could filter out all multicast packet for which there
is no known multicast listener on the 6LoWPAN network.  See sec-
other-protocols for protocols that allow multicast listeners to
signal which groups they would like to listen to.
Paragraph (version A):
A key additional threat consideration for group communication is
pervasive monitoring RFC7258.  CoAP group communication solutions
that are built on top of IP multicast need to pay particular heed to
these dangers.  This is because IP multicast is easier to intercept
(and to secretly record) compared to IP unicast.  Also, CoAP traffic
is meant for the Internet of Things.  This means that CoAP multicast
may be used for the control and monitoring of critical infrastructure
(e.g., lights, alarms, etc.) that may be prime targets for attack.
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 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.  Thus, for example,
site-local IP multicast scope is always preferred over global scope
IP multicast if this fulfills the application needs.
Paragraph (version B):
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 B):
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 B):
This document has the following actions for IANA.