Draft: draft-ietf-core-groupcomm-bis

Commentary: Generalize to non - IP - multicast transports and other security methods , for issue 
 Based on  's review ( ) , verify if transport protocol can be generalized , from UDP / IP only to any CoAP - capable transports . If so adapt the text at various places to enable this , using UDP / IP multicast as the default transport binding while not excluding others . 
 Part of this verification : if transport can be generalized , then review all instances of " multicast request " and " group request " - make uniform terminology . If a group request is meant , use " group request " . For a group request specifically and only sent over a multicast transport , a phrase like " multicast group request " could be used . 
 Did a check of the text ; it looks like it can be easily generalized to any alternative CoAP transports . The concept of " CoAP group " remains . In the alternative transports , the concept of " port " may be absent so for sections that define requirements related to " port " some care in the wording is needed - it pertains specifically to any transports that do have the ' port ' concept . In addition , the " security group " may be generalized to use an alternative security means ( not OSCORE ) . The intro can explain that this draft focuses by default on " UDP multicast " as transport and " Group OSCORE " for security ; but many considerations also hold when alternatives are used for these . 
 It looks good and ready to merge . Thanks !
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 devices or networks.  This document replaces RFC7390,
while it updates RFC7252 and RFC7641.
Paragraph (version A):
This document specifies group communication using the Constrained
Application Protocol (CoAP) RFC7252 together with UDP/IP multicast.
CoAP is a RESTful communication protocol that is used in resource-
constrained nodes, and in resource-constrained networks where packet
sizes should be small.  This area of use is summarized as Constrained
RESTful Environments (CoRE).
Paragraph (version B):
This document specifies the use of the Constrained Application
Protocol (CoAP) for group communication, including the use of UDP/IP
multicast as the default 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 devices or networks that support CoAP.  This
document replaces RFC7390, while it updates RFC7252 and RFC7641.
Paragraph (version B):
This document specifies group communication using the Constrained
Application Protocol (CoAP) RFC7252, together with UDP/IP multicast
as the default transport for CoAP group communication messages.  CoAP
is a RESTful communication protocol that is used in resource-
constrained nodes, and in resource-constrained networks where packet
sizes should be small.  This area of use is summarized as Constrained
RESTful Environments (CoRE).
Paragraph (version A):
Both unsecured and secured CoAP group communication over UDP/IP
multicast are specified in this document.  Security is achieved by
using Group Object Security for Constrained RESTful Environments
(Group OSCORE) I-D.ietf-core-oscore-groupcomm, which in turn builds
on Object Security for Constrained Restful Environments (OSCORE)
RFC8613.  This method provides end-to-end application-layer security
protection of CoAP messages, by using CBOR Object Signing and
Encryption (COSE) I-D.ietf-cose-rfc8152bis-algs.
Paragraph (version B):
Both unsecured and secured CoAP group communication are specified in
this document.  Security is achieved by using Group Object Security
for Constrained RESTful Environments (Group OSCORE) I-D.ietf-core-
oscore-groupcomm, which in turn builds on Object Security for
Constrained Restful Environments (OSCORE) RFC8613.  This method
provides end-to-end application-layer security protection of CoAP
messages, by using CBOR Object Signing and Encryption (COSE) I-
D.ietf-cose-rfc8152bis-algs.
Paragraph (version A):
For group communication, only solutions that use CoAP over UDP/IP
multicast are in the scope of this document.  There are alternative
methods to achieve group communication using CoAP, for example
Publish-Subscribe I-D.ietf-core-coap-pubsub which uses a central
broker server that CoAP clients access via unicast communication.
These methods may be usable for the same or similar use cases as are
targeted in this document.
Paragraph (version A):
Furthermore, this document defines Group OSCORE I-D.ietf-core-oscore-
groupcomm as the default group communication security solution for
CoAP.  Security solutions for group communication and configuration
other than Group OSCORE are not in scope.  General principles for
secure group configuration are in scope.
Paragraph (version B):
For group communication, only those solutions that use CoAP messages
over a "one-to-many" (i.e. non-unicast) transport protocol are in the
scope of this document.  There are alternative methods to achieve
group communication using CoAP, using unicast only.  One example is
Publish-Subscribe I-D.ietf-core-coap-pubsub which uses a central
broker server that CoAP clients access via unicast communication.
These alternative methods may be usable for the same or similar use
cases as the ones targeted in this document.
Paragraph (version B):
This document defines UDP/IP multicast as the default transport
protocol for CoAP group requests, as in RFC7252.  Other transport
protocols (which may include broadcast, non-IP multicast, geocast,
etc.) are not described in detail and are left for future work.
Although UDP/IP multicast transport is assumed in most of the text in
this document, we expect many of the considerations for UDP/IP
multicast can be re-used for alternative transport protocols.
Paragraph (version B):
Furthermore, this document defines Group OSCORE I-D.ietf-core-oscore-
groupcomm as the default group communication security solution for
CoAP.  Security solutions for group communication and configuration
other than Group OSCORE are left for future work.  General principles
for secure group configuration are in scope.
Paragraph (version A):
A CoAP group is defined as a set of CoAP endpoints, where each
endpoint is configured to receive CoAP multicast messages that are
sent to the group's associated IP multicast address and UDP port.  An
endpoint may be a member of multiple CoAP groups by subscribing to
multiple IP multicast groups and/or listening on multiple UDP ports.
Group membership(s) of an endpoint may dynamically change over time.
A device sending a CoAP multicast message to a CoAP group is not
necessarily itself a member of this CoAP group: it is a member only
if it also has a CoAP endpoint listening on the group's associated IP
multicast address and UDP port.  A CoAP group can be encoded within a
Group URI.  This is defined as a CoAP URI that has the "coap" scheme
and includes in the authority part either an IP multicast address or
a group hostname (e.g., a Group Fully Qualified Domain Name (FQDN))
that can be resolved to an IP multicast address.  A Group URI also
contains an optional UDP port number in the authority part.  Group
URIs follow the regular CoAP URI syntax (see Section 6 of RFC7252).
Paragraph (version B):
A CoAP group is defined as a set of CoAP endpoints, where each
endpoint is configured to receive CoAP group messages that are sent
to the group's associated IP multicast address and UDP port.  An
endpoint may be a member of multiple CoAP groups by subscribing to
multiple IP multicast groups and/or listening on multiple UDP ports.
Group membership(s) of an endpoint may dynamically change over time.
A device sending a CoAP group message to a CoAP group is not
necessarily itself a member of this CoAP group: it is a member only
if it also has a CoAP endpoint listening on the group's associated IP
multicast address and UDP port.  A CoAP group can be encoded within a
Group URI.  This is defined as a CoAP URI that has the "coap" scheme
and includes in the authority part either an IP multicast address or
a group hostname (e.g., a Group Fully Qualified Domain Name (FQDN))
that can be resolved to an IP multicast address.  A Group URI also
contains an optional UDP port number in the authority part.  Group
URIs follow the regular CoAP URI syntax (see Section 6 of RFC7252).
Paragraph (version A):
CoAP endpoints can also discover application groups by performing a
multicast discovery query using the /.well-known/core resource.  Such
a request may be sent to a known CoAP group multicast address
associated to application group(s), or to the All CoAP Nodes
multicast address.
Paragraph (version B):
CoAP endpoints can also discover application groups by performing a
group discovery query using the /.well-known/core resource.  Such a
request may be sent to a known CoAP group multicast address
associated to application group(s), or to the All CoAP Nodes
multicast address.
Paragraph (version A):
A CoAP client MAY repeat a multicast request using the same Token
value and same Message ID value, in order to ensure that enough (or
all) group members have been reached with the request.  This is
useful in case a number of group members did not respond to the
initial request and the client suspects that the request did not
reach these group members.  However, in case one or more servers did
receive the initial request but the response to that request was
lost, this repeat does not help to retrieve the lost response(s) if
the server(s) implement the optional Message ID based deduplication
(Section 4.5 of RFC7252).
Paragraph (version A):
A CoAP client MAY 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):
A 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):
While processing a response on the client, 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, although 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 A):
where NON_LIFETIME and MAX_LATENCY are defined in Section 4.8 of
RFC7252.  This specification defines MAX_SERVER_RESPONSE_DELAY as was
done in RFC7390, that is: the expected maximum response delay over
all servers that the client can send a multicast request to.  This
delay includes the maximum Leisure time period as defined in
Section 8.2 of RFC7252.  However, CoAP does not define a time limit
for the server response delay.  Using the default CoAP parameters,
the Token reuse time MUST be greater than 250 seconds plus
MAX_SERVER_RESPONSE_DELAY.  A preferred solution to meet this
requirement is to generate a new unique Token for every new multicast
request, such that a Token value is never reused.  If a client has to
reuse Token values for some reason, and also
MAX_SERVER_RESPONSE_DELAY is unknown, then using
MAX_SERVER_RESPONSE_DELAY = 250 seconds is a reasonable guideline.
The time between Token reuses is in that case set to a value greater
than MIN_TOKEN_REUSE_TIME = 500 seconds.
Paragraph (version B):
A CoAP client MAY repeat a group request using the same Token value
and same Message ID value, in order to ensure that enough (or all)
group members have been reached with the request.  This is useful in
case a number of group members did not respond to the initial request
and the client suspects that the request did not reach these group
members.  However, in case one or more servers did receive the
initial request but the response to that request was lost, this
repeat does not help to retrieve the lost response(s) if the
server(s) implement the optional Message ID based deduplication
(Section 4.5 of RFC7252).
Paragraph (version B):
A CoAP client MAY repeat a group 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 B):
A CoAP client can distinguish the origin of multiple server responses
by the source IP address of the 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 B):
While processing a response on the client, the source endpoint of the
response is not matched to the destination endpoint of the request,
since for a group request these will never match.  This is specified
in Section 8.2 of RFC7252, with reference to IP multicast.  Also,
when UDP transport is used, this implies that a server MAY respond
from a UDP port number that differs from the destination UDP port
number of the request, although 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):
where NON_LIFETIME and MAX_LATENCY are defined in Section 4.8 of
RFC7252.  This specification defines MAX_SERVER_RESPONSE_DELAY as was
done in RFC7390, that is: the expected maximum response delay over
all servers that the client can send a CoAP group request to.  This
delay includes the maximum Leisure time period as defined in
Section 8.2 of RFC7252.  However, CoAP does not define a time limit
for the server response delay.  Using the default CoAP parameters,
the Token reuse time MUST be greater than 250 seconds plus
MAX_SERVER_RESPONSE_DELAY.  A preferred solution to meet this
requirement is to generate a new unique Token for every new group
request, such that a Token value is never reused.  If a client has to
reuse Token values for some reason, and also
MAX_SERVER_RESPONSE_DELAY is unknown, then using
MAX_SERVER_RESPONSE_DELAY = 250 seconds is a reasonable guideline.
The time between Token reuses is in that case set to a value greater
than MIN_TOKEN_REUSE_TIME = 500 seconds.
Paragraph (version A):
When securing CoAP group communication 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 CoAP group communication is
defined in the future which does not ensure secure binding between
requests and responses, a client MUST follow the Token processing
requirements as defined in I-D.ietf-core-echo-request-tag.
Paragraph (version B):
When securing CoAP group communication 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 and considering a
reuse time greater than MIN_TOKEN_REUSE_TIME.  If an alternative
security protocol for CoAP group communication is used which does not
ensure secure binding between requests and responses, a client MUST
follow the Token processing requirements as defined in I-D.ietf-core-
echo-request-tag.
Paragraph (version A):
Since a client sending a multicast request with a Token T will accept
multiple responses with the same Token T, it is possible in
particular 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 acting out of specification as a malicious,
compromised or faulty server.
Paragraph (version B):
Since a client sending a group request with a Token T will accept
multiple responses with the same Token T, it is possible in
particular 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 acting out of specification as a malicious,
compromised or faulty server.
Paragraph (version A):
A client sending a GET or FETCH group request over multicast MAY
update a cache with the responses from the servers in the CoAP
group.  Then, the client uses both cached-still-fresh and new
responses as the result of the group request.
Paragraph (version A):
A client sending a GET or FETCH group request over multicast MAY
use a response received from a server, to satisfy a subsequent
sent request intended to that server on the related unicast
request URI.  In particular, the unicast request URI is obtained
by replacing the authority part of the request URI with the
transport-layer source address of the cached response message.
Paragraph (version B):
A client sending a GET or FETCH group request MAY update a cache
with the responses from the servers in the CoAP group.  Then, the
client uses both cached-still-fresh and new responses as the
result of the group request.
Paragraph (version B):
A client sending a GET or FETCH group request MAY use a response
received from a server, to satisfy a subsequent sent request
intended to that server on the related unicast request URI.  In
particular, the unicast request URI is obtained by replacing the
authority part of the request URI with the transport-layer source
address of the cached response message.
Paragraph (version A):
For caching at client endpoints, the same freshness model relying on
the Max-Age Option as defined in Section 5.6.1 of RFC7252 applies,
and the multicast caching rules of Section 8.2.1 of RFC7252 apply
except for the one discussed below.
Paragraph (version B):
For caching of group communication responses at client endpoints, the
same freshness model relying on the Max-Age Option as defined in
Section 5.6.1 of RFC7252 applies, and the multicast caching rules of
Section 8.2.1 of RFC7252 apply except for the one discussed below.
Paragraph (version A):
For validation at client endpoints, the multicast validation rules in
Section 8.2.1 of RFC7252 apply, except for the last paragraph which
states "A GET request to a multicast group MUST NOT contain an ETag
option".  This document updates RFC7252 by allowing a group request
to contain ETag Options as specified below.
Paragraph (version B):
For validation of cached group communication responses at client
endpoints, the multicast validation rules in Section 8.2.1 of RFC7252
apply, except for the last paragraph which states "A GET request to a
multicast group MUST NOT contain an ETag option".  This document
updates RFC7252 by allowing a group request to contain ETag Options
as specified below.
Paragraph (version A):
Note: a legacy CoAP server might treat an ETag Option in a multicast
request as an unrecognized option per Sections 5.4 and 8.2.1 of
RFC7252, causing it to ignore this (elective) ETag Option regardless
of its value, and process the request normally as if that ETag Option
was not included.
Paragraph (version B):
Note: a legacy CoAP server might treat an ETag Option in a group
request as an unrecognized option per Sections 5.4 and 8.2.1 of
RFC7252, causing it to ignore this (elective) ETag Option regardless
of its value, and process the request normally as if that ETag Option
was not included.
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.
Paragraph (version A):
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 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 multicast 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 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):
A server that is a member of a CoAP group listens for CoAP request
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 sending group requests to that
group.
Paragraph (version A):
CoAP enables a client to request a forward-proxy to process a CoAP
request on its behalf, as described in Sections 5.7.2 and 8.2.2 of
RFC7252.  For this purpose, the client specifies either the request
group URI as a string in the Proxy-URI Option or it uses the Proxy-
Scheme Option with the group URI constructed from the usual Uri-*
Options.  The forward-proxy then resolves the group URI to a
destination CoAP group, multicasts the CoAP request, receives the
responses and forwards all the individual (unicast) responses back to
the client.
Paragraph (version B):
CoAP enables a client to request a forward-proxy to process a CoAP
request on its behalf, as described in Sections 5.7.2 and 8.2.2 of
RFC7252.  For this purpose, the client specifies either the request
group URI as a string in the Proxy-URI Option or it uses the Proxy-
Scheme Option with the group URI constructed from the usual Uri-*
Options.  The forward-proxy then resolves the group URI to a
destination CoAP group, sends (e.g. multicasts) the CoAP group
request, receives the responses and forwards all the individual
(unicast) responses back to the client.
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 it
stops forwarding them 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):
The proxy does not necessarily 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 it stops forwarding them to the client.  A CoAP client that
is not using a Proxy might face the same problems in collecting
responses to a group 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 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 allow-listing and/or client
authentication) to allow proxied CoAP multicast requests only from
specific client(s).
Paragraph (version B):
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 allow-listing and/or client
authentication) to allow proxied CoAP group requests only from
specific client(s).
Paragraph (version A):
In a group communication scenario, a reverse-proxy can rely on its
configuration and/or on information in a request from a client, in
order to determine that the request has to be forwarded to a group of
servers over IP multicast.  For example, specific resources on the
reverse-proxy could be allocated, each to a specific application
group and/or CoAP group.  Or alternatively, the application group
and/or CoAP group in question could be encoded as URI path segments.
The URI path encodings for a reverse-proxy may also use a URI mapping
template as described in Section 5.4 of RFC8075.
Paragraph (version B):
In a group communication scenario, a reverse-proxy can rely on its
configuration and/or on information in a request from a client, in
order to determine that a group request has to be sent to a group of
servers over a one-to-many transport such as IP/UDP multicast.
Paragraph (version B):
For example, specific resources on the reverse-proxy could be
allocated, each to a specific application group and/or CoAP group.
Or alternatively, the application group and/or CoAP group in question
could be encoded as URI path segments.  The URI path encodings for a
reverse-proxy may also use a URI mapping template as described in
Section 5.4 of RFC8075.
Paragraph (version A):
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):
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-multi) 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 A):
CoAP group requests may result in a multitude of responses from
different nodes, potentially causing congestion.  Therefore, both the
sending of IP multicast requests and the sending of the unicast CoAP
responses to these multicast requests should be conservatively
controlled.
Paragraph (version B):
CoAP group requests may result in a multitude of responses from
different nodes, potentially causing congestion.  Therefore, both the
sending of CoAP group requests and the sending of the unicast CoAP
responses to these group requests should be conservatively
controlled.
Paragraph (version A):
A server in a constrained network SHOULD only support group
communication for resources that have a small representation
(where the representation may be retrieved via a GET, FETCH or
POST method in the request).  For example, "small" can be defined
as a response payload 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 sec-6lowpan) is used on the
constrained network.
Paragraph (version A):
A server SHOULD minimize the payload size of a response to a
multicast GET or FETCH on "/.well-known/core" by using hierarchy
in arranging link descriptions for the response.  An example of
this is given in Section 5 of RFC6690.
Paragraph (version A):
A server MAY minimize the payload size of a response to a
multicast GET or FETCH (e.g., on "/.well-known/core") by using
CoAP block-wise transfers RFC7959 in case the payload is long,
returning only a first block of the CoRE Link Format description.
For this reason, a CoAP client sending an IP multicast CoAP
request to "/.well-known/core" SHOULD support block-wise
transfers.  See also sec-block-wise.
Paragraph (version B):
A server in a constrained network SHOULD only support group
requests for resources that have a small representation (where the
representation may be retrieved via a GET, FETCH or POST method in
the request).  For example, "small" can be defined as a response
payload 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 sec-6lowpan) is used on the constrained network.
Paragraph (version B):
A server SHOULD minimize the payload size of a response to a group
GET or FETCH request on "/.well-known/core" by using hierarchy in
arranging link descriptions for the response.  An example of this
is given in Section 5 of RFC6690.
Paragraph (version B):
A server MAY minimize the payload size of a response to a group
GET or FETCH request (e.g., on "/.well-known/core") by using CoAP
block-wise transfers RFC7959 in case the payload is long,
returning only a first block of the CoRE Link Format description.
For this reason, a CoAP client sending a CoAP group request to
"/.well-known/core" SHOULD support block-wise transfers.  See also
sec-block-wise.
Paragraph (version A):
The CoAP Observe Option RFC7641 is a protocol extension of CoAP, that
allows a CoAP client to retrieve a representation of a resource and
automatically keep this representation up-to-date over a longer
period of time.  The client gets notified when the representation has
changed.  RFC7641 does not mention whether the Observe Option can be
combined with CoAP multicast.
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.  Consistent with Section 2.4 of RFC8132, it is
also possible to use the Observe Option in a CoAP multicast FETCH
request.
Paragraph (version B):
The CoAP Observe Option RFC7641 is a protocol extension of CoAP, that
allows a CoAP client to retrieve a representation of a resource and
automatically keep this representation up-to-date over a longer
period of time.  The client gets notified when the representation has
changed.  RFC7641 does not mention whether the Observe Option can be
combined with CoAP (multicast) group communication.
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, it is
also possible to use the Observe Option in a CoAP FETCH group
request.
Paragraph (version A):
Multicast Observe is a useful way to start observing a particular
resource on all members of a CoAP group at the same time.  Group
members that do not have this particular resource or do not allow the
GET or FETCH method on it will either respond with an error status --
silently suppress the response following the rules of sec-request-
response, depending on server-specific configuration.
Paragraph (version B):
Multicast Observe is a useful way to start observing a particular
resource on all members of a CoAP group at the same time.  Group
members that do not have this particular resource or do not allow the
GET or FETCH method on it will either respond with an error status --
silently suppress the response following the rules of sec-request-
response-suppress, depending on server-specific configuration.
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
MUST use a Message ID that differs from the initial multicast
message.
Paragraph (version A):
Furthermore, consistent 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 B):
A client that has sent a group 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 MUST use a Message ID
that differs from the initial group request message.
Paragraph (version B):
Furthermore, consistent with Section 3.3.1 of RFC7641 and following
its guidelines, a client MAY at any time send a new group/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.  If a server adds a
client (as a new entry) to the list of observers for a resource due
to an Observe request, the server SHOULD respond to this request and
SHOULD NOT suppress the response.  An exception to the above is the
overriding of response suppression according to a CoAP No-Response
Option RFC7967 specified by the client in the GET or FETCH request
(see sec-request-response).
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.  If a server adds a
client (as a new entry) to the list of observers for a resource due
to an Observe request, the server SHOULD respond to this request and
SHOULD NOT suppress the response.  An exception to the above is the
overriding of response suppression according to a CoAP No-Response
Option RFC7967 specified by the client in the GET or FETCH request
(see sec-request-response-suppress).
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 (using serial
unicast to each known group member).  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 at a later point in time or the
multicast deregistration request MAY be repeated upon receiving
another observe response from a server.
Paragraph (version B):
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 (using serial
unicast to each known group member).  In addition, a client MAY
explicitly deregister from all those servers at once, by sending a
group/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 at a later point in time or the
group/multicast deregistration request MAY be repeated upon receiving
another observe response from a server.
Paragraph (version A):
The client has to use unicast for any further request, separately
addressing each different server, in order to retrieve more blocks of
the resource from that server, if any.  Also, a server (member of a
targeted CoAP group) that needs to respond to a multicast request
with a particularly large resource can use block-wise transfer
(Block2 Option) at its own initiative, to limit the size of the
initial response.  Again, a client would have to use unicast for any
further requests to retrieve more blocks of the resource.
Paragraph (version A):
A solution for multicast block-wise transfer using the Block1 Option
is not specified in RFC7959 nor in the present document.  Such a
solution would be useful for multicast FETCH/PUT/POST/PATCH/iPATCH
requests, to efficiently distribute a large request payload as
multiple blocks to all members of a CoAP group.  Multicast usage of
Block1 is non-trivial due to potential message loss (leading to
missing blocks or missing confirmations), and potential diverging
block size preferences of different members of the CoAP group.
Paragraph (version B):
The client has to use unicast for any further request, separately
addressing each different server, in order to retrieve more blocks of
the resource from that server, if any.  Also, a server (member of a
targeted CoAP group) that needs to respond to a group request with a
particularly large resource can use block-wise transfer (Block2
Option) at its own initiative, to limit the size of the initial
response.  Again, a client would have to use unicast for any further
requests to retrieve more blocks of the resource.
Paragraph (version B):
A solution for group/multicast block-wise transfer using the Block1
Option is not specified in RFC7959 nor in the present document.  Such
a solution would be useful for group FETCH/PUT/POST/PATCH/iPATCH
requests, to efficiently distribute a large request payload as
multiple blocks to all members of a CoAP group.  Multicast usage of
Block1 is non-trivial due to potential message loss (leading to
missing blocks or missing confirmations), and potential diverging
block size preferences of different members of the CoAP group.
Paragraph (version A):
In this document only UDP is considered as a transport protocol, both
over IPv4 and IPv6.  Therefore, RFC8323 (CoAP over TCP, TLS, and
WebSockets) is not in scope as a transport for group communication.
Paragraph (version B):
In this document UDP, both over IPv4 and IPv6, is considered as the
default transport protocol for CoAP group communication.
Paragraph (version B):
CoAP group communication may be used over transports other than UDP/
IP multicast.  For example broadcast, non-UDP multicast, geocast,
serial unicast, etc.  In such cases the particular considerations for
UDP/IP multicast in this document may need to be applied to that
particular transport.
Paragraph (version B):
Because it supports unicast only, RFC8323 (CoAP over TCP, TLS, and
WebSockets) is not in scope as a transport for CoAP group
communication.
Paragraph (version A):
The Multicast Protocol for Low-Power and Lossy Networks (MPL) RFC7731
can be used for propagation of IPv6 multicast packets throughout a
defined network domain, over multiple hops.  MPL is designed to work
in LLNs and can operate alone or in combination with RPL.  The
protocol involves a predefined group of MPL Forwarders to
collectively distribute IPv6 multicast packets throughout their MPL
Domain.  An MPL Forwarder may be associated to multiple MPL Domains
at the same time.  Non-Forwarders will receive IPv6 multicast packets
from one or more of their neighboring Forwarders.  Therefore, MPL can
be used to propagate a CoAP multicast request to all group members.
Paragraph (version B):
The Multicast Protocol for Low-Power and Lossy Networks (MPL) RFC7731
can be used for propagation of IPv6 multicast packets throughout a
defined network domain, over multiple hops.  MPL is designed to work
in LLNs and can operate alone or in combination with RPL.  The
protocol involves a predefined group of MPL Forwarders to
collectively distribute IPv6 multicast packets throughout their MPL
Domain.  An MPL Forwarder may be associated to multiple MPL Domains
at the same time.  Non-Forwarders will receive IPv6 multicast packets
from one or more of their neighboring Forwarders.  Therefore, MPL can
be used to propagate a CoAP multicast group request to all group
members.
Paragraph (version A):
In particular, Group OSCORE protects CoAP requests sent over IP
multicast by a CoAP client, as well as multiple corresponding CoAP
responses sent over IP unicast by different CoAP servers.  However,
the same security material can also be used to protect CoAP requests
sent over IP unicast to a single CoAP server in the OSCORE group, as
well as the corresponding responses.
Paragraph (version B):
In particular, Group OSCORE protects CoAP group requests sent by a
CoAP client, e.g. over UDP/IP multicast, as well as multiple
corresponding CoAP responses sent as (IP) unicast by different CoAP
servers.  However, the same security material can also be used to
protect CoAP requests sent over (IP) unicast to a single CoAP server
in the OSCORE group, as well as the corresponding responses.
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 on the group's UDP port.
Paragraph (version A):
All further CoAP endpoints configured only as CoAP clients, that
send (multicast) CoAP requests to the CoAP group.
Paragraph (version B):
All members of the CoAP group, i.e. the CoAP endpoints configured
to receive CoAP group messages sent to the particular group and --
in case of IP multicast transport -- are listening to the group's
multicast IP address on the group's UDP port.
Paragraph (version B):
All further CoAP endpoints configured only as CoAP clients, that
may send CoAP group requests to the CoAP group.
Paragraph (version A):
This section provides security considerations for CoAP group
communication using IP multicast.
Paragraph (version B):
This section provides security considerations for CoAP group
communication, in general and for the particular transport of IP
multicast.
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 procedure as OSCORE (see Sections 8.1 and
CoAP options according to the same classification in U/I/E
classes.
Paragraph (version B):
Since Group OSCORE provides end-to-end confidentiality and
integrity of request/response messages, proxies capable of group
communication 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 procedure as OSCORE (see Sections 8.1 and
CoAP options according to the same classification in U/I/E
classes.
Paragraph (version A):
Section 11.3 of RFC7252 highlights that CoAP group requests may be
used for accidentally or deliberately performing Denial of Service
attacks, especially in the form of a high-volume amplification
attack, by using all the servers in the CoAP group as attack vectors.
Since potentially all the servers in the CoAP group may reply, the
achieved amplification factor can be considerably high, as multiple
responses are sent and all are likely larger than the group request.
Paragraph (version B):
Section 11.3 of RFC7252 highlights that CoAP group requests may be
used for accidentally or deliberately performing Denial of Service
attacks, especially in the form of a high-volume amplification
attack, by using all the servers in the CoAP group as attack vectors.
Since potentially all the servers in the CoAP group may respond, the
achieved amplification factor can be high, as multiple responses are
sent and all are likely larger than the group request.
Paragraph (version A):
When CoAP group communication is used in CoAP NoSec (No Security)
mode (see chap-unsecured-groupcomm), the CoAP No-Response Option
RFC7967 could be misused by a malicious client to evoke as much
responses from servers to a multicast request as possible, by using
the value '0' - Interested in all responses.  This even overrides the
default behaviour of a CoAP server to suppress the response in case
there is nothing of interest to respond with.  Therefore, this option
can be used to perform an amplification attack (see ssec-
amplification).
Paragraph (version B):
When CoAP group communication is used in CoAP NoSec (No Security)
mode (see chap-unsecured-groupcomm), the CoAP No-Response Option
RFC7967 could be misused by a malicious client to evoke as much
responses from servers to a group request as possible, by using the
value '0' - Interested in all responses.  This even overrides the
default behaviour of a CoAP server to suppress the response in case
there is nothing of interest to respond with.  Therefore, this option
can be used to perform an amplification attack (see ssec-
amplification).
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
compared to IP unicast.  Also, CoAP traffic is typically used 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, HVAC, electrical grid, etc.) that may be prime targets for
attack.
Paragraph (version B):
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
compared to IP unicast.  Also, CoAP traffic is typically used for the
Internet of Things.  This means that CoAP (multicast) group
communication may be used for the control and monitoring of critical
infrastructure (e.g., lights, alarms, HVAC, electrical grid, etc.)
that may be prime targets for attack.