Draft: draft-ietf-core-groupcomm-bis

Commentary: Based on  's review ( ) , expand a bit on the following text from RFC 7252 : " This specification attempts to reduce the amplification effects of multicast requests by limiting when a response is returned . To limit the possibility of malicious use , CoAP servers SHOULD NOT accept multicast requests that can not be authenticated in some way , cryptographically or by some multicast boundary limiting the potential sources . If possible , a CoAP server SHOULD limit the support for multicast requests to the specific resources where the feature is required . " A specific section 6.x on amplification attacks in general could be , even . ( To cross - check with what 6.2.3 writes about amplification attacks . ) 
 The commit adds : New text in Sections 4 , 6.1 , 6.2.3 ( second bullet point ) New Section 6.3 
 The commit revises the sections mentioned in the previous comment , mostly based on version -01 of [ 1 ] and the related slide 9 at [ 2 ] . [ 1 ] [ 2 ] 
 See 
 RFC 7252 writes : " A GET request to a multicast group MUST NOT contain an ETag option . " One reason to have this statement may be that known problems were found for doing ETag in a group request . Another reason could be : just be on the cautious side . Now if the currently defined Multi - ETag Option works , then in my view also ETag could work in exactly the same way . That is : server includes an ETag option in a response that is a binary concatenation of two items : { resource e - tag , unique - server - id - within - group } here the unique - id does n't need to be guaranteed - unique , only unique with some ( high / reasonable ) probability . It could be a group member number / id if those have been assigned . So the idea is that the server may use these ' extended ' e - tag values for any resources that support multicast . For example it could be used for resources that are in application context only used with multicast . Now we have something using ETag that works like Multi - ETag so should be correct . In case of " etag collission " i.e. two servers return the same ETag value for a resource representation the burden is on the client to detect this case and ensure this ETag value is not used in a subsequent request ( or : only used if the client really intends to validate the responses from both servers at the same time . ) Pros : the " unique server i d within group " can be made much shorter than the complete server IP address structure used in Multi - ETag will also work when some servers are unware of this special use of ETag ( i.e. for normal ETag values , these can be mixed into the set of responses . Client will handle potential collissions ) servers do n't need to support Multi - ETag Cons : burden on client to do " bookkeeping " in case of potentially colliding etags the Multi - Etag is more efficient in encoding multiple etag values for the same server ( using CBOR array ) , for a larger number of etag values ( but : is this usage likely in practice ? ) needs some concept of ' server i d within group ' and server should apply it to ETag generation if it has this i d. 
 Draft proposal text included in above commit . ( We can review and reopen this if needed . ) 
 Idea : an ingress   or 6LBR may filter ingress multicast packets based on size . E.g. , any packet that would lead to ( excessive ) 6LoWPAN fragmentation could be dropped as a policy . Or deprioritized just like we state for MPL Forwarders / 6LR Routers . Is this something we ought to mention in the security considerations ? 
 I think it 's good to add . 
 The intro text of Section 5 has become quite long - it could have its own section 5.1 . This is just a nice - to - have to make text easier to refer to . ( Some standards bodies use this convention . E.g. if I refer to " Section 5 " currently it is not clear whether I mean the intro text or the whole of Section 5 including subsections . ) Other sections already conform to this convention . ( Except section 1 . Introduction ; but for an intro section it is less common to apply this convention . ) 
 Same pattern can be applied to the text of 6.2 -6.2.1 
 As per the commit , done for Section 5 -5.1 . Instead , the introductory text in Section 6.2 seems already pretty short and self - contained to be further broken down . 
 A server receiving an Observe Option in the group request SHOULD respond , and MUST respond even when it adds the client as a new entry to the observers list for that resource . However , what if the client uses also No - Response ? I.e. it might include a weird combination of both options . Should one take precedence over the other ? E.g. an Observe request with suppression of 2.x responses does not make much sense ; the server could just decide to not put the client on the observers - list after the first initial processing of the request leads to a 2.x response . Or , it could ignore the conflicting No - Response option in this case . Or , we could say the behaviour is implementation dependent and the client MUST NOT use such particular combinations . 
 This seems relevant more generally also to non - group requests . Since RFC 7967 does not say so much on this combination , perhaps it 's better to not say more in this document and leave if for corrclarr [ 1 ] ? Just for information , we 've actually thought of a possible usage of a request with both Observe:0 ( Register ) and No - Response : 2 ( Not interested in 2.xx responses ) . See the last three paragraphs of [ 2 ] , where this is intentionally phrased just as a suggestion , since it 's unclear how much well Observe and No - Response are used together in implementations today . [ 1 ] [ 2 ] https://ace- 
 As per the commit , responding ( suppressing the response ) now follows a SHOULD ( SHOULD NOT ) rather than a MUST ( MUST NOT ) , pointing at the discussion about No - Response in Section 3.1 as an exception to that . 
 Agree , closing . 
 Can we refer to examples in an obsoleted RFC ? ( section 2.2.1 mentions the RFC 7390 examples ) 
 What is the purpose of referring to those ? If they are illustrating normative concepts , I 'd pull them over . If they are just " look , this is one way this has been done " , such a reference is OK IMHO . 
 The purpose is just to point to some examples ( that we did n't want to repeat ) , nothing normative . So it should be ok to do so . 
 You could emphasize this by using past tense ( ... RFC 7390 showed examples ... )
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 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; 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 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 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; 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):
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):
Besides CoAP groups, that have relevance at the level of IP networks
and CoAP endpoints, there are also application groups.  An
application group is a set of CoAP server endpoints that share a
common set of CoAP resources.  An endpoint may be a member of
multiple application groups.  An application group has relevance at
the application level -- for example an application group could
denote all lights in an office room or all sensors in a hallway.  A
client endpoint that sends a group communication message to an
application group is not necessarily itself a member of this
application group.  There can be a one-to-one or a one-to-many
relation between a CoAP group and application group(s).  An
application group identifier is optionally encoded explicitly in the
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 B):
Besides CoAP groups, that have relevance at the level of IP networks
and CoAP endpoints, there are also application groups.  An
application group is a set of CoAP server endpoints that share a
common set of CoAP resources.  An endpoint may be a member of
multiple application groups.  An application group has relevance at
the application level - for example an application group could denote
all lights in an office room or all sensors in a hallway.  A client
endpoint that sends a group communication message to an application
group is not necessarily itself a member of this application group.
There can be a one-to-one or a one-to-many relation between a CoAP
group and application group(s).  An application group identifier is
optionally encoded explicitly in the 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):
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):
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 A):
control application are shown in Section 2.2 of RFC7390.
Paragraph (version B):
control application were shown in Section 2.2 of RFC7390.
Paragraph (version A):
by RFC7252 -- which is potentially confusing.  Appendix A of I-
D.ietf-core-resource-directory shows an example registration of an
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 B):
by RFC7252 - which is potentially confusing.  Appendix A of I-D.ietf-
core-resource-directory shows an example registration of an
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):
The IETF does not define a mandatory, standardized protocol to
accomplish CoAP group creation.  RFC7390 defines an experimental
protocol for configuration of group membership for unsecured group
communication, based on JSON-formatted configuration resources.  For
IPv6 CoAP groups, common multicast address ranges that are used to
configure group addresses from are ff1x::/16 and ff3x::/16.
Paragraph (version B):
The IETF does not define a mandatory protocol to accomplish CoAP
group creation.  RFC7390 defined an experimental protocol for
configuration of group membership for unsecured group communication,
based on JSON-formatted configuration resources.  For IPv6 CoAP
groups, common multicast address ranges that are used to configure
group addresses from are ff1x::/16 and ff3x::/16.
Paragraph (version 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 A):
For unsecured group communication (see chap-unsecured-groupcomm) i.e.
the "NoSec" security group, addition/removal of CoAP group members is
simply done by configuring these devices to start/stop listening to
the group IP multicast address on the group's UDP port.
Paragraph (version 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 A):
All CoAP requests that are sent via IP multicast MUST be Non-
confirmable; see Section 8.1 of RFC7252.  The Message ID in an IP
multicast CoAP message is used for optional message deduplication by
both clients and servers, as detailed in Section 4.5 of RFC7252.
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 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 B):
All CoAP requests that are sent via IP multicast MUST be Non-
confirmable; see Section 8.1 of RFC7252.  The Message ID in an IP
multicast CoAP message is used for optional message deduplication by
both clients and servers, as detailed in Section 4.5 of RFC7252.  A
server sends back a unicast response to a CoAP group request.  The
unicast responses received by the CoAP client may 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):
A server MAY suppress its 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.
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):
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):
where NON_LIFETIME and MAX_LATENCY are defined in Section 4.8 of
RFC7252.  This specification defines MAX_SERVER_RESPONSE_DELAY as 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):
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):
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):
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):
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):
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 A):
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 A):
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 A):
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 A):
For caching at proxies, the freshness model defined in sec-proxy-
caching of this specification applies.
Paragraph (version A):
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 A):
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 A):
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 A):
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 A):
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 A):
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 A):
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 A):
The first element specifies the addressing information of the
corresponding server, encoded as defined in sec-caching-
validation-tpinfo.
Paragraph (version A):
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 A):
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 A):
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 A):
The Multi-ETag Option is of class E in terms of OSCORE processing
(see Section 4.1 of RFC8613).
Paragraph (version A):
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 A):
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 A):
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 A):
'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 A):
'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 A):
The CDDL notation RFC8610 provided below describes the 'tp_info' CBOR
array using the format above.
Paragraph (version A):
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 A):
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 A):
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 A):
The client MUST NOT include one or more ETag Option(s) together
with one or more Multi-ETag Option(s).
Paragraph (version A):
The client MUST include only one Multi-ETag Option for each server
it wishes to get a response revalidation from.
Paragraph (version A):
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 A):
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 A):
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 A):
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 A):
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 A):
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 A):
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 A):
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 A):
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 A):
The inclusion of an ETag Option in a response works as defined in
Section 5.6.10.1 of RFC7252.
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, e.g., using the forward-proxying
method defines in I-D.tiloca-core-groupcomm-proxy.
Paragraph (version B):
The following subsections define the freshness model and validation
model to use for cached responses, which update the models defined in
Sections 5.6.1 and 5.6.2 of RFC7252, respectively.
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 B):
The client knows all current CoAP server group members; and, for
each group member, the client's cache currently stores a fresh
response.
Paragraph (version B):
How the client in the case above determines the current CoAP server
group members is out of scope for this document.  It may be, for
example, via a group manager server, or by observing group join
requests, or observing IGMP/MLD multicast group join messages, etc.
Paragraph (version B):
For caching at proxies, the freshness model defined in I-D.tiloca-
core-groupcomm-proxy can be used.
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 B):
For validation at proxies, the validation model defined in I-
D.tiloca-core-groupcomm-proxy can be used.
Paragraph (version B):
A client endpoint MAY include one or more ETag Options in a GET or
FETCH group request to validate one or more stored responses it has
cached.  In case two or more servers in the group have responded to a
previous request to the same resource with an identical ETag value,
it is the responsibility of the client to handle this case.  In
particular, if the client wishes to validate, using a group request,
a response from server 1 with an ETag value N, while it does not wish
to validate a response from server 2 with the same ETag value N,
there is no way to achieve this.  In such cases of identical ETag
values returned by two or more servers, the client, by default,
SHOULD NOT include an ETag Option in a group request containing that
ETag value.
Paragraph (version B):
A server endpoint MUST process an ETag Option in a GET or FETCH group
request in the same way it processes an ETag Option for a unicast
request.  A server endpoint that includes an ETag Option in a
response to a group request SHOULD construct the ETag Option value in
such a way that the value will be unique to this particular server
with a high probability.  This can be done, for example, by embedding
a compact ID of the server within the ETag value, where the ID is
unique (or unique with a high probability) in the scope of the group.
Paragraph (version B):
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 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):
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):
CoAP enables a client to request a forward-proxy to process a CoAP
request on its behalf, as described in Section 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 operation of HTTP-to-CoAP proxies for multicast CoAP requests is
specified in Section 8.4 and 10.1 of RFC8075.  In this case, the
"application/http" media type is used to let the proxy return
multiple CoAP responses -- each translated to a HTTP response -- back
to the HTTP client.  Of course, in this case the HTTP client sending
a group URI to the proxy needs to be aware that it is going to
receive this format, and needs to be able to decode it into the
responses of multiple CoAP servers.  Also, the IP source address of
each CoAP response cannot be determined anymore from the
"application/http" response.  The HTTP client still identify the CoAP
servers by other means such as application-specific information in
the response payload.
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 B):
The operation of HTTP-to-CoAP proxies for multicast CoAP requests is
specified in Sections 8.4 and 10.1 of RFC8075.  In this case, the
"application/http" media type is used to let the proxy return
multiple CoAP responses - each translated to a HTTP response - back
to the HTTP client.  Of course, in this case the HTTP client sending
a group URI to the proxy needs to be aware that it is going to
receive this format, and needs to be able to decode it into the
responses of multiple CoAP servers.  Also, the IP source address of
each CoAP response cannot be determined anymore from the
"application/http" response.  The HTTP client still identify the CoAP
servers by other means such as application-specific information in
the response payload.
Paragraph (version A):
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 A):
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):
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 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 A):
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 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):
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-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):
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):
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 A):
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 A):
A proxy that supports forwarding of group requests and that employs a
cache maintains the following two types of cache entry.
Paragraph (version A):
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 A):
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 A):
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 A):
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 A):
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 A):
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 A):
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 A):
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 A):
The proxy adds the response to a temporary list L.
Paragraph (version A):
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 A):
The proxy stores all the responses from the list L in the
aggregated cache entry.
Paragraph (version A):
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 A):
The proxy sets the aggregated cache entry as usable to serve
group requests from clients.
Paragraph (version A):
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 A):
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 A):
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 A):
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 A):
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 A):
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 A):
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 A):
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 A):
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 A):
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 A):
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 A):
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 A):
The Group-ETag Option has the same properties of the ETag Option
defined in Section 5.10.6 of RFC7252.
Paragraph (version A):
The Group-ETag Option is of class U in terms of OSCORE processing
(see Section 4.1 of RFC8613).
Paragraph (version A):
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 A):
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 A):
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 A):
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 A):
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 A):
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 A):
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):
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):
For the operation of HTTP-to-CoAP reverse proxies, see the last
paragraph of sec-proxy-forward which applies also to the case of
reverse-proxies.
Paragraph (version B):
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 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):
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 --
4.04 Not Found or 4.05 Method Not Allowed, respectively -- or will
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 -
4.04 Not Found or 4.05 Method Not Allowed, respectively - or will
silently suppress the response following the rules of sec-request-
response-suppress, depending on server-specific configuration.
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.  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 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 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):
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):
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 B):
I-D.ietf-core-new-block specifies an alternative method for CoAP
block-wise transfer.  It specifies that "servers MUST ignore
multicast requests that contain the Q-Block2 Option".
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 A):
For a CoAP server node that supports resource discovery as defined in
Section 2.4 of RFC7252, the default port 5683 MUST be supported as
per Section 7.1 and 12.8 of RFC7252 for the "All CoAP Nodes"
multicast group.  An IPv6 CoAP server SHOULD support the "All CoAP
Nodes" groups with at least link-local (2), admin-local (4) and site-
local (5) scopes.  An IPv6 CoAP server on a 6LoWPAN node (see sec-
6lowpan) SHOULD also support the realm-local (3) scope.
Paragraph (version B):
For a CoAP server node that supports resource discovery as defined in
Section 2.4 of RFC7252, the default port 5683 MUST be supported as
per Sections 7.1 and 12.8 of RFC7252 for the "All CoAP Nodes"
multicast group.  An IPv6 CoAP server SHOULD support the "All CoAP
Nodes" groups with at least link-local (2), admin-local (4) and site-
local (5) scopes.  An IPv6 CoAP server on a 6LoWPAN node (see sec-
6lowpan) SHOULD also support the realm-local (3) scope.
Paragraph (version A):
CoAP group communication can use UDP over IPv4 as a transport
protocol, provided that IPv4 multicast is enabled.  For a CoAP server
node that supports resource discovery as defined in Section 2.4 of
RFC7252, the default port 5683 MUST be supported as per Section 7.1
and 12.8 of RFC7252, for the "All CoAP Nodes" IPv4 multicast group.
Paragraph (version B):
CoAP group communication can use UDP over IPv4 as a transport
protocol, provided that IPv4 multicast is enabled.  For a CoAP server
node that supports resource discovery as defined in Section 2.4 of
RFC7252, the default port 5683 MUST be supported as per Sections 7.1
and 12.8 of RFC7252, for the "All CoAP Nodes" IPv4 multicast group.
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):
For security and performance reasons also other filtering criteria
may be defined at an ingress MPL Forwarder.  See sec-security-
considerations-6lowpan-mpl for more details.
Paragraph (version A):
CoAP group communication can operate in CoAP NoSec (No Security)
mode, without using application-layer and transport-layer security
mechanisms.  The NoSec mode uses the "coap" scheme, and is defined in
Section 9 of RFC7252.  The conceptual "NoSec" security group as
defined in sec-groupdef is used for unsecured group communication.
Before using this mode of operation, the security implications (chap-
security-considerations-nosec-mode) must be well understood.
Paragraph (version B):
CoAP group communication can operate in CoAP NoSec (No Security)
mode, without using application-layer and transport-layer security
mechanisms.  The NoSec mode uses the "coap" scheme, and is defined in
Section 9 of RFC7252.  The conceptual "NoSec" security group as
defined in sec-groupdef is used for unsecured group communication.
Paragraph (version B):
Before using this mode of operation, the security implications (chap-
security-considerations-nosec-mode) must be well understood,
especially as to the risk and impact of amplification attacks (see
ssec-amplification).
Paragraph (version B):
This section defines how CoAP group communication can be secured.  In
particular, chap-group-oscore describes how the Group OSCORE security
protocol I-D.ietf-core-oscore-groupcomm can be used to protect
messages exchanged in a CoAP group, while chap-sec-group-maintenance
provides guidance on required maintenance operations for OSCORE
groups used as security groups.
Paragraph (version A):
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 B):
OSCORE uses COSE I-D.ietf-cose-rfc8152bis-struct 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 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 further CoAP endpoints configured only as CoAP clients, that
send (multicast) CoAP requests to the CoAP group.
Paragraph (version A):
Adding new members to a CoAP group or enabling new client-only
endpoints to interact with that group require also that each of
such members/endpoints join the corresponding OSCORE group.  By
doing so, they are securely provided with the necessary
cryptographic material.  In case backward security is needed, this
also requires to first renew such material and distribute it to
the current members/endpoints, before new ones are added and join
the OSCORE group.
Paragraph (version A):
In case forward security is needed, removing members from a CoAP
group or stopping client-only endpoints from interacting with that
group requires removing such members/endpoints from the
corresponding OSCORE group.  To this end, new cryptographic
material is generated and securely distributed only to the
remaining members/endpoints.  This ensures that only the members/
endpoints intended to remain are able to continue participating in
secure group communication, while the evicted ones are not able
to.
Paragraph (version A):
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 A):
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 A):
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 A):
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 A):
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 A):
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 A):
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 A):
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 A):
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 A):
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):
This section provides security considerations for CoAP group
communication using IP multicast.
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 B):
Adding new members to a CoAP group or enabling new client-only
endpoints to interact with that group require also that each of
such members/endpoints join the corresponding OSCORE group.  By
doing so, they are securely provided with the necessary
cryptographic material.
Paragraph (version B):
In case backward security is needed, this also requires to first
renew such material and distribute it to the current members/
endpoints, before new ones are added and join the OSCORE group.
This prevents the new group members to access secure group
communications that occurred in the group before their joining.
Paragraph (version B):
Removing members from a CoAP group or stopping client-only
endpoints from interacting with that group requires removing such
members/endpoints from the corresponding OSCORE group.  To this
end, new cryptographic material is generated and securely
distributed only to the remaining members/endpoints, together with
the list of removed members/endpoints.
Paragraph (version B):
This ensures that only the members/endpoints intended to remain
are able to continue participating in secure group communication,
while the evicted ones are not able to.  Also, it ensures that the
members/endpoints intended to remain are able to confidently
assert the group membership of other sender nodes, when receiving
protected messages in the group (see Section 3.2 of I-D.ietf-core-
oscore-groupcomm).
Paragraph (version B):
Different solutions may be selected for secure group communication
via a proxy depending on proxy type, use case and deployment
requirements.  In this section the options based on Group OSCORE are
listed.
Paragraph (version B):
For a client performing a group communication request via a forward-
proxy, end-to-end security should be implemented.  The client then
creates a group request protected with Group OSCORE and unicasts this
to the proxy.  The proxy adapts the request from a forward-proxy
request to a regular request and multicasts this adapted request to
the indicated CoAP group.  During the adaptation, the security
provided by Group OSCORE persists, in either case of using the group
mode or using the pairwise mode.  The first leg of communication from
client to proxy can optionally be further protected, e.g., by using
(D)TLS and/or OSCORE.
Paragraph (version B):
For a client performing a group communication request via a reverse-
proxy, either end-to-end-security or hop-by-hop security can be
implemented.  The case of end-to-end security is the same as for the
forward-proxy case.
Paragraph (version B):
For all the above cases, more details on using Group OSCORE are
defined in I-D.tiloca-core-groupcomm-proxy.
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):
Discovery of devices and resources is a typical use case where NoSec
mode is applied, since the devices involved do not have yet
configured any mutual security relations at the time the discovery
takes place.
Paragraph (version B):
Early discovery of devices and resources is a typical use case where
NoSec mode is applied, since the devices involved do not have yet
configured any mutual security relations at the time the discovery
takes place.
Paragraph (version B):
If NoSec mode is used, amplification attacks I-D.mattsson-core-coap-
attacks are especially feasible to perform and effective in their
impact.  Therefore, in order to prevent an easy proliferation of
high-volume amplification attacks, it is generally NOT RECOMMENDED to
use CoAP group communication in NoSec mode, as further discussed in
ssec-amplification.
Paragraph (version A):
A key management scheme for secure revocation and renewal of group
security material, namely group rekeying, should be adopted in OSCORE
groups.  In particular, the key management scheme should preserve
backward and forward security in the OSCORE group, if the application
requires so (see Section 3.1 of I-D.ietf-core-oscore-groupcomm).
Paragraph (version A):
Group policies should also take into account the time that the key
management scheme requires to rekey the group, on one hand, and the
expected frequency of group membership changes, i.e. nodes' joining
and leaving, on the other hand.
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 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):
This comes at the cost of not continuously preserving backward and
forward security, since group rekeying might not occur upon every
single group membership change.  That is, most recently joined nodes
would have access to the security material used prior to their join,
and thus be able to access past group communications protected with
that security material.  Similarly, until the group is rekeyed, most
recently left nodes would preserve access to group communications
protected with the retained security material.
Paragraph (version B):
A key management scheme for secure revocation and renewal of group
security material, namely group rekeying, is required to be adopted
in OSCORE groups.  The key management scheme has to preserve forward
security in the OSCORE group, as well as backward security if this is
required by the application.  In particular, the key management
scheme MUST comply with the functional steps defined in Section 3.2
of I-D.ietf-core-oscore-groupcomm.
Paragraph (version B):
Group policies should also take into account the time that the key
management scheme requires to rekey the group, on one hand, and the
expected frequency of group membership changes, i.e., nodes' joining
and leaving, on the other hand.
Paragraph (version B):
That is, 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 cautiously consider to rekey
the group, e.g., after a minimum number of nodes has joined or left
the group within a pre-defined time interval, or according to
communication patterns with predictable time intervals of network
inactivity.  This would prevent paralyzing communications in the
group, when a slow rekeying scheme is used and frequently invoked.
Paragraph (version B):
At the same, the security implications of delaying the rekeying
process have to be carefully considered and understood, before
enforcing such group policies.
Paragraph (version B):
In fact, this comes at the cost of not continuously preserving
backward and forward security, since group rekeying might not occur
upon every single group membership change.  That is, most recently
joined nodes would have access to the security material used prior to
their join, and thus be able to access past group communications
protected with that security material.  Similarly, until the group is
rekeyed, most recently left nodes would preserve access to group
communications protected with the retained security material.
Paragraph (version A):
Appendix F of I-D.ietf-core-oscore-groupcomm discusses a number of
cases where a recipient CoAP endpoint may skip the verification of
countersignatures in messages protected with the group mode, possibly
on a per-message basis.  However, this is NOT RECOMMENDED.  That is,
a CoAP endpoint receiving a message secured with the group mode of
Group OSCORE SHOULD always verify the countersignature.
Paragraph (version A):
Group OSCORE protects against amplification attacks (see
Section 11.3 of RFC7252), which are made e.g. by injecting (small)
requests over IP multicast from the (spoofed) IP address of a
victim client, and thus triggering the transmission of several
(much bigger) responses back to that client.  In fact, upon
receiving a request over IP multicast as protected with Group
OSCORE in group mode, a server is able to verify whether the
request is fresh and originates from the alleged sender in the
OSCORE group, by verifying the countersignature included in the
request using the public key of that sender (see Section 8.2 of I-
D.ietf-core-oscore-groupcomm).  Furthermore, as also discussed in
Section 8 of I-D.ietf-core-oscore-groupcomm, it is recommended
that servers failing to decrypt and verify an incoming message do
not send back any error message.
Paragraph (version B):
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 signatures
for the group mode, Group OSCORE protects messages using the same
procedure as OSCORE (see Sections 8 and 9 of I-D.ietf-core-oscore-
groupcomm), and especially processes CoAP options according to the
same classification in U/I/E classes.
Paragraph (version B):
Group OSCORE limits the feasibility and impact of amplification
attacks, see ssec-amplification of this document and Section 11.3
of RFC7252.
Paragraph (version B):
In fact, upon receiving a request over IP multicast as protected
with Group OSCORE in group mode, a server is able to verify
whether the request is not a replay and originates from the
alleged sender in the OSCORE group, by verifying the signature
included in the request using the public key of that sender (see
Section 8.2 of I-D.ietf-core-oscore-groupcomm).  Furthermore, as
also discussed in Section 8 of I-D.ietf-core-oscore-groupcomm, it
is recommended that servers failing to decrypt and verify an
incoming message do not send back any error message.
Paragraph (version B):
This limits an adversary to leveraging an intercepted group
request protected with Group OSCORE, and then altering the source
IP address to be the one of the intended amplification victim.
Paragraph (version B):
As discussed in the next point, a server can also rely on the Echo
Option for CoAP described in I-D.ietf-core-echo-request-tag, and
possibly use it to assert that the alleged sender of the group
request (i.e., the CoAP client associated to a certain public key)
is indeed reachable at the claimed source address, especially if
this differs from the one used in previous group requests from the
same CoAP client.  Although responses including the Echo Option do
result in amplification, this is limited in volume compared to
when all servers reply with a full-fledged response.
Paragraph (version B):
Furthermore, the adversary needs to consider a group request that
specifically targets a resource for which the CoAP servers are
configured to respond.  While this can be often correctly assumed
or inferrable from the application context, it is not explicit
from the group request itself, since Group OSCORE protects the
Uri-Path and Uri-Query CoAP Options conveying the respective
components of the target URI.
Paragraph (version A):
Within an OSCORE group, the shared symmetric-key security material
strictly provides only group-level authentication (see
Section 10.1 of I-D.ietf-core-oscore-groupcomm).  However, source
authentication of messages is also ensured, both in the group mode
by means of countersignatures (see Sections 8.1 and 8.3 of I-
D.ietf-core-oscore-groupcomm), and in the pairwise mode by using
additionally derived pairwise keys (see Sections 9.1 and 9.3 of I-
D.ietf-core-oscore-groupcomm).  Thus, recipient endpoints can
verify a message to be originated by the alleged, identifiable
sender in the OSCORE group.
Paragraph (version B):
Within an OSCORE group, the shared symmetric-key security material
strictly provides only group-level authentication.  However,
source authentication of messages is also ensured, both in the
group mode by means of signatures (see Sections 8.1 and 8.3 of I-
D.ietf-core-oscore-groupcomm), and in the pairwise mode by using
additionally derived pairwise keys (see Sections 9.3 and 9.5 of I-
D.ietf-core-oscore-groupcomm).  Thus, recipient endpoints can
verify a message to be originated by the alleged, identifiable
sender in the OSCORE group.
Paragraph (version A):
Group OSCORE prevents to make any single group member a target for
subverting security in the whole OSCORE group (see Section 11.6 of
RFC7252), even though all group members share (and can derive) the
same symmetric-key security material used in the OSCORE group (see
Section 10.1 of I-D.ietf-core-oscore-groupcomm).  In fact, source
authentication is always ensured for exchanged CoAP messages, as
verifiable to be originated by the alleged, identifiable sender in
the OSCORE group.  This relies on including a countersignature
computed with a node's individual private key (in the group mode),
or on protecting messages with a pairwise symmetric key, which is
in turn derived from the asymmetric keys of the sender and
recipient CoAP endpoints (in the pairwise mode).
Paragraph (version B):
Group OSCORE prevents to make any single group member a target for
subverting security in the whole OSCORE group (see Section 11.6 of
RFC7252), even though all group members share (and can derive) the
same symmetric-key security material used in the OSCORE group.  In
fact, source authentication is always ensured for exchanged CoAP
messages, as verifiable to be originated by the alleged,
identifiable sender in the OSCORE group.  This relies on including
a signature computed with a node's individual private key (in the
group mode), or on protecting messages with a pairwise symmetric
key, which is in turn derived from the asymmetric keys of the
sender and recipient CoAP endpoints (in the pairwise mode).
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 B):
Section 3 of I-D.mattsson-core-coap-attacks further discusses this
attack, and notes how the amplification factor would become even
higher when group communication is combined with resource observation
RFC7641.  That is, a single group request may result in multiple
notification responses from each of the responding servers,
throughout the observation lifetime.
Paragraph (version B):
Consistently with Section 11.3 of RFC7252, a CoAP server in a CoAP
group SHOULD limit the support for CoAP group requests only to the
group resources of the application group(s) using that CoAP group.
Paragraph (version B):
It is especially easy to perform an amplification attack when NoSec
mode is used.  Therefore, in order to prevent an easy proliferation
of high-volume amplification attacks, it is generally NOT RECOMMENDED
to use CoAP group communication in NoSec mode.
Paragraph (version B):
Exceptions should be carefully limited to use cases and accesses to a
group resource that have a specific, narrow and well understood
scope, and where only a few CoAP servers (or ideally only one) would
possibly respond to a group request.
Paragraph (version B):
A relevant example is a CoAP client performing the discovery of hosts
such as a group manager or a Resource Directory I-D.ietf-core-
resource-directory, by probing for them through a group request sent
to the CoAP group.  This early, unprotected step is relevant for a
CoAP client that does not know the address of such hosts in advance,
and that does not have yet configured a mutual security relation with
them.  In this kind of deployments, such a discovery procedure does
not result in a considerable and harmful amplification, since only
the few CoAP servers object of discovery are going to respond to the
group request targeting that specific resource.  In particular, those
hosts can be the only CoAP servers in that specific CoAP group (hence
listening for group requests sent to that group), and/or the only
CoAP servers explicitly configured to respond to group requests
targeting specific group resources.
Paragraph (version B):
In any other case, group communications MUST be secured using Group
OSCORE I-D.ietf-core-oscore-groupcomm, see chap-oscore.  As discussed
in chap-security-considerations-sec-mode-attacks, this limits the
feasibility and impact of amplification attacks.
Paragraph (version A):
This requires a server to have a synchronized, up to date view of the
sequence number used by the client.  If such synchronization is lost,
e.g. due to a reboot, or suspected so, the server should use one of
the methods described in Appendix E of I-D.ietf-core-oscore-
groupcomm, such as the one based on the Echo Option for CoAP
described in I-D.ietf-core-echo-request-tag, in order to
(re-)synchronize with the client's sequence number.
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.
Paragraph (version B):
This requires a server to have a synchronized, up to date view of the
sequence number used by the client.  If such synchronization is lost,
e.g., due to a reboot, or suspected so, the server should use the
challenge-response synchronization method described in Appendix E of
I-D.ietf-core-oscore-groupcomm and based on the Echo Option for CoAP
defined in I-D.ietf-core-echo-request-tag, in order to
(re-)synchronize with the client's sequence number.
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 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 B):
For these reasons, a fragmented IPv6 multicast packet is a possible
attack vector in a Denial of Service (DoS) amplification attack.  See
ssec-amplification of this document and 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 (MPL) multicast forwarder SHOULD
deprioritize forwarding for multi-fragment 6LoWPAN multicast packets.
6LoWPAN Border Routers are typical ingress points where multicast
traffic enters into a 6LoWPAN network.  Specific MPL Forwarders
(whether located on a 6LBR or not) may also be configured as ingress
points.  Any such ingress point 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 packets 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.  As part of multicast packet filtering, the ingress point
SHOULD implement a filtering criterium based on the size of the
multicast packet.  Ingress multicast packets above a defined size may
then be dropped or deprioritized.
Paragraph (version A):
CoAP group communication can be used to control a set of related
devices: for example, simultaneously turn on all the lights in a
room.  This intrinsically exposes the group to some unique monitoring
risks that devices not in a group are not as vulnerable to.  For
example, assume an attacker is able to physically see a set of lights
turn on in a room.  Then the attacker can correlate an observed CoAP
group communication message to the observed coordinated group action
-- even if the CoAP message is (partly) encrypted.
This will give the attacker side-channel information to plan further
attacks (e.g., by determining the members of the group some network
topology information may be deduced).
Paragraph (version B):
CoAP group communication can be used to control a set of related
devices: for example, simultaneously turn on all the lights in a
room.  This intrinsically exposes the group to some unique monitoring
risks that devices not in a group are not as vulnerable to.  For
example, assume an attacker is able to physically see a set of lights
turn on in a room.  Then the attacker can correlate an observed CoAP
group communication message to the observed coordinated group action
- even if the CoAP message is (partly) encrypted.
This will give the attacker side-channel information to plan further
attacks (e.g., by determining the members of the group some network
topology information may be deduced).
Paragraph (version A):
This document has the following actions for IANA.