Draft: draft-ietf-core-groupcomm-bis

Commentary: Changelog : Section 1.2 - " Group URI " in the main terminology . Section 2.1 - Revision of group type definitions . Section 2.2.1 - Revision of methods for group naming ; examples . Section 2.2.3 - Revision of methods for group discovery ; examples . Sections 3.1.4 , 3.1.5 and 3.5.1 - Editorial fixes and rephrasing .     , with examples of message exchanges . 
 Current draft says : I do n't quite understand how that 'd happen ; I see two possible interpretations : Use .wk / c to discover content of application groups , eg . by requesting , picking really only one response , and hoping that it 's just the content of the group resources and not everything on the host ( cf . -- was requested , but what comes back is coap://[fe80::f00]/.well - known / core actually ) . Send out a broad multicast and wait for links that describe groups . However , other than the RD Appendix A methods ( which are n't really applicable here ) , I do n't know of any description format to be used . Is " The description of the group may be provided in an application specific or a yet to be defined generic format . " meant here ? 
 Above PR expands the text with discovery use cases and examples . We may still expand this later on with discovery examples or the link format attribute(s ) defined by draft - tiloca - core - oscore - discovery ; but that is not done yet . ( I would need some more time still to read that draft first ) 
 Reading the paragraph after " An application group can be named in many ways " , I was left a bit confused : Why should it be encoded in the Uri - Query ? That 'd need coordination among all applications running on that host ( for it is interfering with the query argument space that 's usually left for the application to use ) . The common partitioning of applications inside a host is left - to - right in the URI , and that puts it in the very last spot . I think I do see what is meant by the discouragement of using the Uri - Host , but doubt that it 'd be immediately obvious to general readers . How I understand Uri - Host to be impractical here is that while the request is sent to a well - defined and named URI , the response is a representation of the same URI with the individual server 's IP replaced into the authority component , and if two application groups on the same CoAP group use the same path , then there may be clashes , not on the request - response layer ( where the responses are bound to request for a particular host name ) but in the client 's cache of the responses . ( And once one is at the point where application groups in the same CoAP group have a disjunct path set , one can do away with identification altogether and just address the unique path ) . I do n't quite follow how this is not " as intended in  " : It is an identifier for who is being addressed , and as such just part of the URI . ( For example , if I define my lights group to be named and name the resource , then the host name is exactly the group name , and already needs to be put into the request unless there is known URI aliasing ) . See also on " send a Uri - Host " option , with the caveat that I 'm a strong proponent of answer A2 . Furthermore , the text seems to imply that virtual hosting is something a server would need to go out of its way to implement . It is n't : The Uri - Host option is critical , and a host needs to make the conscious decision to ignore that option ; otherwise it 's just as much part of finding the addressed resource as all the other Uri- * options are . The best practice is something I can get behind , although I suggest using no identifier on the wire ( and just the disjunct set of resources ) as a byte saving alternative when the administrative effort of ensuring path uniqueness can be afforded . 
 Thanks ; we do need to improve the current text on these aspects . On Uri - Host and your example " " where authority component includes the application group : in this group communication example the sending client would normally DNS - resolve " " to a particular multicast IP address , then send the CoAP request to this multicast IP address destination , without including any Uri - Host Option . This works as long as you have a unique 1:1 association between application - group and CoAP - group . In case multiple application - groups map to a single CoAP - group , this does n't work anymore : a client could be e.g. configured to always include the " Uri - Host " Option to indicate the hostname . Still not the preferred approach I would think . Btw I ca n't follow answer A2 on the CoAP - Faq , unfortunately : formulation is too complex . In some ( common ? ) constrained use cases , the DNS name would not even be configured in the client and the client would just be configured directly with the IPv6 multicast address of the CoAP group to send it to . Then , the application - group would need to be encoded in some way still , e.g. using the Uri - Path Option . Now what our original text tried to suggest is to " misuse " a Uri - Host Option for that . So instead of using an option like :    = group123 You would instead use an option :    = group123 So this is not a " real " URI hostname but rather a low - level hack to let the client 's CoAP stack insert by force an additional option just before sending out the CoAP request . The receiver 's CoAP stack would just parse it as the ID of the application - group and not really as a URI - host . Because this gets confusing and potentially messy ( proven by the present discussion ! ) we do n't recommend it . So , trying to reiterate if one has configured Group URIs of the form coap://[mcast - ip - address]/resource on the client then by default the Uri - Host Option would get elided . The above mentioned " hack " is to put it back to encode application - group . This has the issue that the application - group name is n't present in the Group URI . if one has configured Group URIs of the form on the client then normally by default the authority gets resolved to some IP multicast address before sending it out , and thus while sending it the Uri - Host Option is NOT included in the CoAP encoding but elided . So the receiving server does n't see the application - group ID because it 's not encoded in the request data . ( We assume here that multiple application - groups use the same CoAP - group . ) Maybe we should discuss this further ; what 's the effort here / who ensures it / unique between what and what ? 
 Initial text proposed in above PR ! We 'll merge it in by tomorrow evening , as an improvement ( hopefully ) . What is not included yet is a statement saying that we do n't recommend using the non - Group - URI methods of encoding application group name . To do so we would need to clearly state why that is not recommended ; still not clear at this moment what the disadvantages of these are . 
 Suggestions committed in this PR .
Paragraph (version A):
Furthermore, "Security material" refers to any security keys,
counters or parameters stored in a device that are required to
participate in secure group communication with other devices.
Paragraph (version B):
In addition, the following terms are extensively used.
Paragraph (version B):
Group URI - This is defined as a CoAP URI that has the "coap"
scheme and includes in the authority component either an IP
multicast address or a group hostname (e.g., a Group Fully
Qualified Domain Name (FQDN)) that can be resolved to an IP
multicast address.  A group URI also contains an optional UDP port
number in the authority component.  Group URIs follow the regular
CoAP URI syntax (see Section 6 of RFC7252).
Paragraph (version B):
Security material - This refers to any security keys, counters or
parameters stored in a device that are required to participate in
secure group communication with other devices.
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 name is
optionally encoded explicitly in the CoAP request, for example 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):
For secure group communication, a security group is required.  A
security group is a group of endpoints that each store group security
material, such that they can mutually exchange secured messages and
verify secured messages.  So, a client endpoint needs to be a member
of a security group in order to send a valid secured group
communication message to this group.  An endpoint may be a member of
multiple security groups.  There can be a many-to-many relation
between security groups and CoAP groups, but often it is one-to-one.
Also, there can be a many-to-many relation between security groups
and application groups, but often it is one-to-one.  A special
security group named "NoSec" identifies group communication without
any security at the transport layer nor at the CoAP layer.
Paragraph (version B):
A CoAP group is defined as a set of CoAP endpoints, where each
endpoint is configured to receive CoAP group messages that are sent
to the group's associated IP multicast address and UDP port.  That
is, CoAP groups have relevance at the level of IP networks and CoAP
endpoints.
Paragraph (version B):
An endpoint may be a member of multiple CoAP groups, by subscribing
to multiple IP multicast addresses.  A node may be a member of
multiple CoAP groups, by hosting multiple CoAP server endpoints on
different UDP ports.  Group membership(s) of an endpoint or node may
dynamically change over time.  A node or endpoint sending a CoAP
group message to a CoAP group is not necessarily itself a member of
this CoAP group: it is a member only if it also has a CoAP endpoint
listening on the group's associated IP multicast address and UDP
port.
Paragraph (version B):
A CoAP group is identified by information encoded within a group URI.
Further details on identifying a CoAP group are provided in sec-
groupnaming-coap.
Paragraph (version B):
An application group is a set of CoAP server endpoints (hosted on
different nodes) that share a common set of CoAP resources.  That is,
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.
Paragraph (version B):
An endpoint may be a member of multiple application groups.  A client
endpoint that sends a group communication message to an application
group is not necessarily itself a member of this application group.
Paragraph (version B):
There can be a one-to-one or a one-to-many relation between a CoAP
group and application group(s).  Such relations are discussed in more
detail in sec-groupdef-grouprelations.
Paragraph (version B):
An application group name may be explicitly encoded in the group URI
of a CoAP request, for example in the URI path component.  If this is
not the case, the application group is implicitly derived by the
receiver, e.g., based on information in the CoAP request or other
contextual information.  Further details on identifying an
application group are provided in sec-groupnaming-app.
Paragraph (version B):
For secure group communication, a security group is required.  A
security group comprises endpoints storing shared group security
material, such that they can use it to protect and verify mutually
exchanged messages.
Paragraph (version B):
That is, a client endpoint needs to be a member of a security group
in order to send a valid secured group communication message to that
group.  A server endpoint needs to be a member of a security group in
order to receive and correctly verify a secured group communication
message sent to that group.  An endpoint may be a member of multiple
security groups.
Paragraph (version B):
There can be a many-to-many relation between security groups and CoAP
groups, but often it is one-to-one.  Also, there can be a many-to-
many relation between security groups and application groups, but
often it is one-to-one.  Such relations are discussed in more detail
in sec-groupdef-grouprelations.
Paragraph (version B):
A special security group named "NoSec" identifies group communication
without any security at the transport layer nor at the CoAP layer.
Further details on identifying a security group are provided in sec-
groupnaming-sec.
Paragraph (version A):
A CoAP group is identified and named by the authority component in
the Group URI, which includes host (possibly an IP multicast address
literal) and an optional UDP port number.  It is recommended to
configure an endpoint with an IP multicast address literal, instead
of a hostname, when configuring a CoAP group membership.  This is
because DNS infrastructure may not be deployed in many constrained
networks.  In case a group hostname is configured, it can be uniquely
mapped to an IP multicast address via DNS resolution - if DNS client
functionality is available in the endpoint being configured and the
DNS service is supported in the network.  Some examples of
hierarchical CoAP group FQDN naming (and scoping) for a building
control application were shown in Section 2.2 of RFC7390.
Paragraph (version A):
URI path component: this is the most common and RECOMMENDED method
to encode the application group name.  A best practice for
encoding application group into a Group URI is to use one URI path
component to identify the application group and use the following
URI paths component(s) to identify the resource within this
application group.  For example, /<groupname>/res1 or
/base/<groupname>/res1/res2 conform to this practice.  An
application group name (like <groupname>) should be as short as
possible when used in constrained networks.
Paragraph (version A):
URI query component: using this method, the query may consist of
the group name (?<groupname>) or it may be one parameter of the
query (?g=<groupname> or ?param1=value1&gn=<groupname>).
Paragraph (version A):
URI host subcomponent: using this method, the application group
becomes equal to the CoAP group.  This can only be used if there
is a one-to-one mapping between CoAP groups and application
groups.
Paragraph (version A):
URI port subcomponent: using this method, the application group is
identified by a number that is encoded in some way in the
destination port.
Paragraph (version A):
encode in a new (custom/application-specific) CoAP Option which is
added to the CoAP request by the client before sending it out.
Each CoAP server that is part of the CoAP group, receiving this
request, would by design understand this Option, would decode it,
and treat it as an application group name.
Paragraph (version A):
Finally, it is possible to not encode the application group name at
all within the CoAP request.  This yields the most compact
representation on the wire.  In this case, each CoAP server needs to
determine the application group based on contextual information, such
as client identity and/or target resource.  For example, each
application group on a server could have a unique set of resources
that does not overlap with any resources of other application groups.
Paragraph (version A):
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 name
"lights" is encoded in the "ep" (endpoint) attribute of the RD
registration entry.  The CoAP group is ff35:30:2001:db8:f1::8000:1
and the "NoSec" security group is used.
Paragraph (version A):
A security group is identified by a stable and invariant string used
as group name, which is generally not related with other kinds of
group identifiers, specific to the chosen security solution.  The
"NoSec" security group name MUST be only used to represent the case
of group communication without any security.  It is typically
characterized by the absence of any security group name, identifier,
or security-related data structures in the CoAP message.
Paragraph (version B):
Different types of group are named as specified below, separately for
CoAP groups, application groups and security groups.
Paragraph (version B):
A CoAP group is identified and named by the authority component in
the group URI (see sec-groupdef-coapgroup), which includes the host
subcomponent (possibly an IP multicast address literal) and an
optional UDP port number.  Note that the two authority components
<HOST> and <HOST>:5683 both identify the same CoAP group, whose
members listen to the CoAP default port number 5683.
Paragraph (version B):
When configuring a CoAP group membership, it is recommended to
configure an endpoint with an IP multicast address literal, instead
of a group hostname.  This is because DNS infrastructure may not be
deployed in many constrained networks.  In case a group hostname is
configured, it can be uniquely mapped to an IP multicast address via
DNS resolution, if DNS client functionality is available in the
endpoint being configured and the DNS service is supported in the
network.
Paragraph (version B):
Examples of hierarchical CoAP group FQDN naming (and scoping) for a
building control application were shown in Section 2.2 of RFC7390.
Paragraph (version B):
An application group can be named in many ways through different
types of identifiers, such as name string, (integer) number, URI or
other types of string.  The decision of whether and how exactly an
application group name is encoded and transported is application
specific.
Paragraph (version B):
The following defines a number of possible methods to use.  The shown
examples consider a CoAP group identified by the group hostname
grp.example.org.  Its members are CoAP servers listening to the
associated IP multicast address ff35:30:2001:db8:f1::8000:1 and port
number 5685.  Note that a group hostname is used here to have better-
readable examples: in practice, an implementation would likely use an
IP address literal as the host component of the Group URI in order to
reduce the size of the CoAP request.  In particular, the Uri-Host
Option can be fully elided in this case.  Also note that the Uri-Port
Option does not appear in the examples, since the port number 5685 is
already included in the CoAP request's UDP header (which is not shown
in the examples).
Paragraph (version B):
An application group name can be explicitly encoded in a group URI.
In such a case, it can be encoded within one of the following URI
components.
Paragraph (version B):
URI path component - This is the most common and RECOMMENDED
method to encode the application group name.  When using this
method in constrained networks, an application group name
GROUPNAME should be as short as possible.
Paragraph (version B):
A best practice for doing so is to use a URI path component such
that: i) it includes a path segment as delimiter with a designated
value, e.g., "gp", followed by ii) a path segment with value the
name of the application group, followed by iii) the path
segment(s) that identify the targeted resource within the
application group.  For example, both /gp/GROUPNAME/res1 and
/base/gp/GROUPNAME/res1/res2 conform to this practice.  Just like
application group names, the path segment used as delimiter should
be as short as possible in constrained networks.
Paragraph (version B):
A full-fledged example is provided in fig-gname-path-example.
Another example of a compact CoAP request is provided in fig-
gname-path-example-2, in which an IPv6 literal address and the
default CoAP port 5683 are used in the authority component.  Also
the resource structure is different in this example.
Paragraph (version B):
URI query component - This method can use the following formats.
In either case, when using this method in constrained networks, an
application group name GROUPNAME should be as short as possible.
Paragraph (version B):
As a first alternative, the URI query component consists of
only one parameter, which has no value and has the name of the
application group as its own idenfier.  That is, the query
component ?GROUPNAME conforms to this format.
Paragraph (version B):
A full-fledged example is provided in fig-gname-query1-example.
Paragraph (version B):
As a second alternative, the URI query component includes a
query parameter as designated indicator, e.g., "gp", with value
the name of the application group.  That is, assuming "gp" to
be used as designated indicator, both the query components
?gp=GROUPNAME and ?par1=v1&gp=GROUPNAME conform to this format.
Paragraph (version B):
A full-fledged example is provided in fig-gname-query2-example.
Paragraph (version B):
URI authority component - If this method is used, the application
group is identified by the authority component as a whole.
Paragraph (version B):
In particular, the application group has the same name of the CoAP
group expressed by the group URI (see sec-groupnaming-coap).
Thus, this method can only be used if there is a one-to-one
mapping between CoAP groups and application groups (see sec-
groupdef-grouprelations).
Paragraph (version B):
A full-fledged example is provided in fig-gname-auth-example.
Paragraph (version B):
URI host subcomponent - If this method is used, the application
group is identified solely by the host subcomponent of the
authority component.
Paragraph (version B):
Since an application group can be associated with only one CoAP
group (see sec-groupdef-grouprelations), using this method implies
that any two CoAP groups cannot differ only by the port
subcomponent of the URI authority component.
Paragraph (version B):
A full-fledged example is provided in fig-gname-host-example.
Paragraph (version B):
URI port subcomponent - By using this method, the application
group is uniquely identified by the destination port number
encoded in the port subcomponent of the authority component.
Paragraph (version B):
Since an application group can be associated with only one CoAP
group (see sec-groupdef-grouprelations), using this method implies
that any two CoAP groups cannot differ only by their host
subcomponent of the URI authority component.
Paragraph (version B):
A full-fledged example is provided in fig-gname-post-example.
Paragraph (version B):
Alternatively, there are also methods to encode the application group
name within the CoAP request, even though it is not encoded within
the group URI.  An example of such method is summarized below.
Paragraph (version B):
The application group name can be encoded in a new (e.g. custom,
application-specific) CoAP Option, which the client adds to the
CoAP request before sending it out.
Paragraph (version B):
Upon receiving the request as a member of the targeted CoAP group,
each CoAP server would, by design, understand this Option, decode
it and treat the result as an application group name.
Paragraph (version B):
A full-fledged example is provided in fig-gname-custom-option-
example.
Paragraph (version B):
Furthermore, it is possible to encode the application group name
neither in the group URI nor within a CoAP request, thus yielding the
most compact representation on the wire.  In this case, each CoAP
server needs to determine the right application group based on
contextual information, such as the client identity and/or the target
resource.  For example, each application group on a server could
support a unique set of resources, such that it does not overlap with
the set of resources of any other application group.
Paragraph (version B):
Finally, Appendix A of I-D.ietf-core-resource-directory provides an
example of application group registered to a Resource Directory (RD),
along with the CoAP group it uses and the resources it supports.  In
that example, an application group name "lights" is encoded in the
"ep" (endpoint) attribute of the RD registration entry.  At the same
time, the CoAP group is ff35:30:2001:db8:f1::8000:1 and the "NoSec"
security group is used.
Paragraph (version B):
A security group is identified by a stable and invariant string used
as group name.  This is generally not related with other kinds of
group identifiers that may be specific of the used security solution.
Paragraph (version B):
The "NoSec" security group name MUST be only used to represent the
case of group communication without any security.  This typically
results in CoAP messages that do not include any security group name,
identifier, or security-related data structures.
Paragraph (version A):
One way to configure a client is to supply it with a CoAP Group URI.
The IETF does not define a mandatory protocol to accomplish CoAP
group creation.  RFC7390 defined an experimental protocol for
configuration of group membership for unsecured group communication,
based on JSON-formatted configuration resources.  For IPv6 CoAP
groups, common multicast address ranges that are used to configure
group addresses from are ff1x::/16 and ff3x::/16.
Paragraph (version A):
To create an application group, a configuring entity may configure a
resource (name) or set of resources on CoAP endpoints, such that a
CoAP request with Group URI sent by a configured CoAP client will be
processed by one or more CoAP servers that have the matching URI path
configured.  These servers are the application group members.
Paragraph (version B):
One way to configure a client is to supply it with a group URI.  The
IETF does not define a mandatory protocol to accomplish CoAP group
creation.  RFC7390 defined an experimental protocol for configuration
of group membership for unsecured group communication, based on JSON-
formatted configuration resources.  For IPv6 CoAP groups, common
multicast address ranges that are used to configure group addresses
from are ff1x::/16 and ff3x::/16.
Paragraph (version B):
To create an application group, a configuring entity may configure a
resource (name) or a set of resources on CoAP endpoints, such that a
CoAP request sent to a group URI by a configured CoAP client will be
processed by one or more CoAP servers that have the matching URI path
configured.  These servers are the members of the application group.
Paragraph (version A):
It is possible for CoAP endpoints to discover application groups as
well as CoAP groups, by using the RD-Groups usage pattern of the CoRE
Resource Directory (RD), as defined in Appendix A of I-D.ietf-core-
resource-directory.  In particular, an application group can be
registered to the RD, specifying the reference IP multicast address
of its associated CoAP group.  The registration of groups is
typically performed by a Commissioning Tool.  Later on, CoAP
endpoints can discover the registered application groups and related
CoAP group(s), by using the lookup interface of the RD.
Paragraph (version A):
Discovery of all application groups that are part of a CoAP group.
For example, in case the application group name is encoded in the
URI path as "/grp/<groupname>" then the discovery query may use
URI "/.well-known/core?href=/grp/*" and it is sent to the IP
multicast address of the CoAP group.  The query matches any
application group name.  The result of this query is a list of
resources at CoAP servers that are a member of at least one
application group associated to the CoAP group.  Each resource
represents an application group membership at one CoAP server.
Paragraph (version A):
Discovery of a particular application group with a known name.
For example, in case the known application group name is
"mygroup1" and is encoded in the URI path as "/grp/<groupname>"
then the discovery query may use URI "/.well-known/core?href=/grp/
mygroup1" and it is sent to the IPv6 All CoAP Nodes multicast
address of a particular chosen scope (e.g. site-local, or realm-
local).  The result of this query is a list of resources at CoAP
servers that are a member of "mygroup1".  Each resource represents
the membership of the responding server to the application group
"mygroup1".
Paragraph (version A):
Discovery of all application groups of a particular type.  For
example, in case the application group type is "mytype1" and is
encoded as a resource type (rt) attribute of the application group
resource, and the application group resource is "/grp/<groupname>"
then the discovery query may use URI "/.well-known/
core?rt=mytype1" and it is sent to the All CoAP Nodes multicast
address.  The query result is a list of resources at CoAP servers
that have at least one application group of type "mytype1"; each
server response identifies the membership to one or more
application group(s) of type "mytype1" for that server.  Each
resource in the list represents one membership of a server to one
application group of type "mytype1".
Paragraph (version A):
Discovery of all application groups that are configured on the
client's 6LoWPAN wireless mesh network.  In the following example
a request without query is used.  So, the URI "/.well-known/core"
is used and the request is sent to the IPv6 All CoAP Nodes
multicast address of realm-local scope.  Each CoAP server
(including any application group members) will return a list of
its resources, which in this example includes the resources used
to encode the application group name.  If each application group
resource is known to be "/g/<groupname>" then the client marks
each returned resource under the root resource "/g" as a
discovered application group.  Not using a query has the
disadvantage that potentially a lot of response traffic will be
generated on the mesh network, including responses from servers
that are not a member of any application group.  But it may be
needed in particular use cases, e.g. if some of the CoAP servers
do not support the optional link format query functionality (as
mentioned in Section 4.1 of RFC6690).
Paragraph (version A):
In particular, the responsible OSCORE Group Manager registers its own
security groups to the RD, as links to its own corresponding
resources for joining the security groups I-D.ietf-ace-key-groupcomm-
oscore.  Later on, CoAP endpoints can discover the registered
security groups and related application groups, by using the lookup
interface of the RD, and then join the security group through the
respective Group Manager.
Paragraph (version B):
The following describes how a CoAP endpoint can discover groups by
different means, i.e., by using a Resource Directory or directly from
the CoAP servers that are members of such groups.
Paragraph (version B):
It is possible for CoAP endpoints to discover application groups as
well as CoAP groups, by using the RD-Groups usage pattern of the CoRE
Resource Directory (RD), as defined in Appendix A of I-D.ietf-core-
resource-directory.
Paragraph (version B):
In particular, an application group can be registered to the RD,
specifying the reference IP multicast address of its associated CoAP
group.  The registration of groups to the RD is typically performed
by a Commissioning Tool.  Later on, CoAP endpoints can discover the
registered application groups and related CoAP group(s), by using the
lookup interface of the RD.
Paragraph (version B):
In particular, the responsible OSCORE Group Manager registers its
security groups to the RD, as links to its own corresponding
resources for joining the security groups I-D.ietf-ace-key-groupcomm-
oscore.  Later on, CoAP endpoints can discover the registered
security groups and related application groups, by using the lookup
interface of the RD, and then join the security group through the
respective Group Manager.
Paragraph (version B):
It is possible for CoAP endpoints to discover application groups and
CoAP groups from the CoAP servers that are members of such groups, by
using a GET request targeting the /.well-known/core resource.
Paragraph (version B):
As shown below, such a GET request may be sent to the IP multicast
address of an already known CoAP group associated with one or more
application groups; or to the "All CoAP Nodes" multicast address,
thus targeting all reachable CoAP servers in any CoAP group.  Also,
the GET request may specify a query component, in order to filter the
application groups of interest.
Paragraph (version B):
These particular details concerning the GET request depend on the
specific discovery action intended by the client and on application-
specific means used to encode names of application groups and CoAP
groups, e.g., in group URIs and/or CoRE target attributes used with
resource links.
Paragraph (version B):
The following provides examples of methods to discover application
groups and CoAP groups, building on the following assumptions.
First, application group names are encoded in the path component of
Group URIs (see sec-groupnaming-app), using the path segment "gp" as
designated delimiter.  Second, the type of an application group is
encoded in the CoRE Link Format attribute "rt" of a group resource
with a value "g.<GROUPTYPE>".  Third, a CoAP group is used and is
identified by the URI authority grp.example.org:5685.
Paragraph (version B):
A CoAP client can discover all the application groups associated
with a specific CoAP group.
Paragraph (version B):
This is achieved by sending the GET request above to the IP
multicast address of the CoAP group, and specifying a wildcarded
group type "g._" as resource type in the URI query parameter "rt".
For example, the request can use a Group URI with path and query
components "/.well-known/core?rt=g._", so that the query matches
any application group resource type.  Alternatively, the request
can use a Group URI with path and query components "/.well-known/
core?href=/gp/*", so that the query matches any application group
resources and also matches any sub-resources of those.
Paragraph (version B):
Through the corresponding responses, the query result is a list of
resources at CoAP servers that are members of the specified CoAP
group and have at least one application group associated with the
CoAP group.  That is, the client gains knowledge of: i) the set of
servers that are members of the specified CoAP group and member of
any of the associated application groups; ii) for each of those
servers, the name of the application groups where the server is a
member and that are associated with the CoAP group.
Paragraph (version B):
A full-fledged example is provided in fig-app-gp-discovery-
example1.
Paragraph (version B):
Each of the servers S1 and S2 is identified by the IP source
address of the CoAP response.  If the client wishes to discover
resources that a particular server hosts within a particular
application group, it may use unicast discovery request(s) to this
server i.e. to its respective unicast IP address.  Alternatively
the client may use the discovered group resource type (e.g.
rt=g.light) to infer which resources are present below the group
resource.
Paragraph (version B):
A CoAP client can discover the CoAP servers that are members of a
specific application group, the CoAP group associated with the
application group, and optionally the resources that those servers
host for each application group.
Paragraph (version B):
This is achieved by sending the GET request above to the "All CoAP
Nodes" IP multicast address (see Section 12.8 of RFC7252), with a
particular chosen scope (e.g., site-local or realm-local) if IPv6
is used.  Also, the request specifies the application group name
of interest in the URI query component, as defined in sec-
groupnaming-app.  For example, the request can use a Group URI
with path and query components "/.well-known/core?href=/gp/gp1" to
specify the application group with name "gp1".
Paragraph (version B):
Through the corresponding responses, the query result is a list of
resources at CoAP servers that are members of the specified
application group and for each application group the associated
CoAP group.  That is, the client gains knowledge of: i) the set of
servers that are members of the specified application group and of
the associated CoAP group; ii) for each of those servers,
optionally the resources it hosts within the application group.
Paragraph (version B):
A full-fledged example is provided in fig-app-gp-discovery-
example2.  Note that the servers need to respond now with an
absolute URI and not a relative URI like in the previous example,
because the group resource "gp1" is hosted at the authority
indicated by the CoAP group (grp.example.org:5685) and not by the
authority that is serving the Link Format document (which is
[ff03::fd]:5683).
Paragraph (version B):
A CoAP client can discover the CoAP servers that are members of
any application group of a specific type, the CoAP group
associated with those application groups, and optionally the
resources that those servers host as members of those application
groups.
Paragraph (version B):
This is achieved by sending the GET request above to the "All CoAP
Nodes" IP multicast address (see Section 12.8 of RFC7252), with a
particular chosen scope (e.g., site-local or realm-local) if IPv6
is used.  Also, the request can specify the application group type
of interest in the URI query component as value of a query
parameter "rt".  For example, the request can use a Group URI with
path and query components "/.well-known/core?rt=TypeA" to specify
the application group type "TypeA".
Paragraph (version B):
Through the corresponding responses, the query result is a list of
resources at CoAP servers that are members of any application
group of the specified type and of the CoAP group associated with
each of those application groups.  That is, the client gains
knowledge of: i) the set of servers that are members of the
application groups of the specified type and of the associated
CoAP group; ii) optionally for each of those servers, the
resources it hosts within each of those application groups.
Paragraph (version B):
A full-fledged example is provided in fig-app-gp-discovery-
example3.
Paragraph (version B):
A CoAP client can discover the CoAP servers that are members of
any application group configured in the 6LoWPAN wireless mesh
network of the client, the CoAP group associated with each
application group, and optionally the resources that those servers
host as members of the application group.
Paragraph (version B):
This is achieved by sending the GET request above with a query
specifying a wildcarded group type in the URI query parameter for
"rt".  For example, a Group URI with path and query components
"/.well-known/core?rt=g.*", so that the query matches any
application group type.  The request is sent to the "All CoAP
Nodes" IP multicast address (see Section 12.8 of RFC7252), with a
particular chosen scope if IPv6 is used.  In this example the
scope is realm-local to address all servers in the current 6LoWPAN
wireless mesh network of the client.
Paragraph (version B):
Through the corresponding responses, the query result is a list of
group resources hosted by any server in the mesh network.  Each
group resource denotes one application group membership of a
server.  The CoAP group per application group is obtained as the
authority of each returned link.
Paragraph (version B):
A full-fledged example is provided in fig-app-gp-discovery-
example4.
Paragraph (version B):
Note that all the above examples are application-specific.  That is,
there is currently no standard way of encoding names of application
groups and CoAP groups in group URIs and/or CoRE target attributes
used with resource links.  In particular, the discovery of groups
through the RD mentioned in sssec-discovery-from-rd is only defined
for use with an RD, i.e., not directly with CoAP servers as group
members.
Paragraph (version B):
For example, some applications may use the "rt" attribute on a parent
resource to denote support for a particular REST API to access child
resources, as detailed in the example in fig-app-gp-discovery-
example5.  In this example a custom Link Format attribute "gpt" is
used to denote the group type within the scope of the application/
system.  An alternative, shorter encoding (not shown in the figure)
is to use only the value "1" for each "gpt" attribute, to denote that
the resource is of type application group.  In that case information
about the semantics/API of the group resource is disclosed only via
the "rt" attribute as shown in the figure.
Paragraph (version A):
All CoAP requests that are sent via IP multicast MUST be Non-
confirmable; see Section 8.1 of RFC7252.  The Message ID in an IP
multicast CoAP message is used for optional message deduplication by
both clients and servers, as detailed in Section 4.5 of RFC7252.  A
server sends back a unicast response to a CoAP group request.  The
unicast responses received by the CoAP client may 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 CoAP client can distinguish the origin of multiple server responses
by the source IP address of the message containing the CoAP response
and/or any other available application-specific source identifiers
contained in the CoAP response payload or CoAP response options, such
as an application-level unique ID associated with the server.  If
secure communication is provided with Group OSCORE (see chap-oscore),
additional security-related identifiers in the CoAP response enable
the client to retrieve the right security material for decrypting
each response and authenticating its source.
Paragraph (version A):
While processing a response on the client, the source endpoint of the
response is not matched to the destination endpoint of the request,
since for a 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):
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.
Paragraph (version B):
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.
Paragraph (version B):
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):
For CoAP group requests, there are additional constraints on the
reuse of Token values at the client, compared to the unicast case
defined in RFC7252 and updated by RFC9175.  Since for CoAP group
requests the number of responses is not bound a priori, the client
cannot use the reception of a response as a trigger to "free up" a
Token value for reuse.
Paragraph (version B):
where NON_LIFETIME and MAX_LATENCY are defined in Section 4.8 of
RFC7252.  This specification defines MAX_SERVER_RESPONSE_DELAY as was
done in RFC7390, that is: the expected maximum response delay over
all servers that the client can send a CoAP group request to.  This
delay includes the maximum Leisure time period as defined in
Section 8.2 of RFC7252.  However, CoAP does not define a time limit
for the server response delay.  Using the default CoAP parameters,
the Token reuse time MUST be greater than 250 seconds plus
MAX_SERVER_RESPONSE_DELAY.
Paragraph (version B):
A preferred solution to meet this requirement is to generate a new
unique Token for every new group request, such that a Token value is
never reused.  If a client has to reuse Token values for some reason,
and also MAX_SERVER_RESPONSE_DELAY is unknown, then using
MAX_SERVER_RESPONSE_DELAY = 250 seconds is a reasonable guideline.
The time between Token reuses is in that case set to a value greater
than MIN_TOKEN_REUSE_TIME = 500 seconds.
Paragraph (version B):
When securing CoAP group communication with Group OSCORE I-D.ietf-
core-oscore-groupcomm, secure binding between requests and responses
is ensured (see chap-oscore).  Thus, a client may reuse a Token value
after it has been freed up, as discussed above and considering a
reuse time greater than MIN_TOKEN_REUSE_TIME.  If an alternative
security protocol for CoAP group communication is used which does not
ensure secure binding between requests and responses, a client MUST
follow the Token processing requirements as defined in RFC9175.
Paragraph (version B):
A client sending a GET or FETCH group request MAY use a response
received from a server, to satisfy a subsequent sent request
intended to that server on the related unicast request URI.  In
particular, the unicast request URI is obtained by replacing the
authority component of the request URI with the transport-layer
source address of the cached response message.
Paragraph (version A):
CoAP enables a client to request a forward-proxy to process a CoAP
request on its behalf, as described in Sections 5.7.2 and 8.2.2 of
RFC7252.  For this purpose, the client specifies either the request
group URI as a string in the Proxy-URI Option or it uses the Proxy-
Scheme Option with the group URI constructed from the usual Uri-*
Options.  The forward-proxy then resolves the group URI to a
destination CoAP group, 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 CoAP client component that sent a unicast CoAP request to the
proxy may be expecting only one (unicast) response, as usual for a
CoAP unicast request.  Instead, it receives multiple (unicast)
responses, potentially leading to fault conditions in the
component or to discarding any received responses following the
first one.  This issue may occur even if the application calling
the CoAP client component is aware that the forward-proxy is going
to execute a CoAP group URI request.
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.
Paragraph (version B):
When intending to reach a CoAP group through a proxy, the client
sends a unicast CoAP group request to the proxy.  This request
specifies the group URI where the request has to be forwarded to,
either as a string in the Proxy-URI Option, or through the Proxy-
Scheme Option with the group URI constructed from the usual Uri-*
Options.  Then, the forward-proxy resolves the group URI to a
destination CoAP group, i.e., it sends (e.g., multicasts) the CoAP
group request to the group URI, receives the responses and forwards
all the individual (unicast) responses back to the client.
Paragraph (version B):
The CoAP client component that has sent the unicast CoAP group
request to the proxy may be expecting only one (unicast) response,
as usual for a CoAP unicast request.  Instead, it receives
multiple (unicast) responses, potentially leading to fault
conditions in the component or to discarding any received
responses following the first one.  This issue may occur even if
the application calling the CoAP client component is aware that
the forward-proxy is going to forward the CoAP group request to
the group URI.
Paragraph (version A):
Due to the above issues, it is RECOMMENDED that a CoAP Proxy only
processes a group URI request if it is explicitly enabled to do so.
The default response (if the function is not explicitly enabled) to a
group URI request is 5.01 Not Implemented.  Furthermore, a proxy
SHOULD be explicitly configured (e.g., by allow-listing and/or client
authentication) to allow proxied CoAP group requests only from
specific client(s).
Paragraph (version B):
Due to the above issues, it is RECOMMENDED that a CoAP Proxy
processes a request to be forwarded to a group URI only if it is
explicitly enabled to do so.  If such functionality is not explicitly
enabled, the default response returned to the client 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 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 with multiple MPL Domains
at the same time.  Non-Forwarders will receive IPv6 multicast packets
from one or more of their neighboring Forwarders.  Therefore, MPL can
be used to propagate a CoAP multicast group request to all group
members.
Paragraph (version A):
OSCORE makes it possible to selectively protect different parts of a
CoAP message in different ways, while still allowing intermediaries
(e.g., CoAP proxies) to perform their intended funtionalities.  That
is, some message parts are encrypted and integrity protected; other
parts are only integrity protected to be accessible to, but not
modifiable by, proxies; and some parts are kept as plain content to
be both accessible to and modifiable by proxies.  Such differences
especially concern the CoAP options included in the unprotected
message.
Paragraph (version B):
OSCORE makes it possible to selectively protect different parts of a
CoAP message in different ways, while still allowing intermediaries
(e.g., CoAP proxies) to perform their intended functionalities.  That
is, some message parts are encrypted and integrity protected; other
parts are only integrity protected to be accessible to, but not
modifiable by, proxies; and some parts are kept as plain content to
be both accessible to and modifiable by proxies.  Such differences
especially concern the CoAP options included in the unprotected
message.
Paragraph (version A):
A Group Manager is responsible for managing one or multiple OSCORE
groups.  In particular, the Group Manager acts as repository of
public keys of group members; manages, renews and provides security
material in the group; and handles the join process of new group
members.
Paragraph (version B):
A Group Manager is responsible for managing one or multiple OSCORE
groups.  In particular, the Group Manager acts as repository of the
group members' authentication credentials including the corresponding
public keys; manages, renews and provides security material in the
group; and handles the join process of new group members.
Paragraph (version A):
CoAP group communication, if not protected, is vulnerable to all the
attacks mentioned in Section 11 of RFC7252 for IP multicast.
Moreover, if the NoSec mode is used, amplification attacks are
especially feasible to perform and greatly effective in their impact
I-D.mattsson-core-coap-attacks.
Paragraph (version B):
CoAP group communication, if not protected, is vulnerable to all the
attacks mentioned in Section 11 of RFC7252 for IP multicast.
Moreover, as also discussed in I-D.mattsson-t2trg-amplification-
attacks, the NoSec mode is susceptible to source IP address spoofing,
hence amplification attacks are especially feasible to perform and
greatly effective in their impact, since a single request can result
in multiple responses from multiple servers (see ssec-amplification).
Paragraph (version A):
Furthermore, the adversary needs to consider a group request that
specifically targets a resource for which the CoAP servers are
configured to respond.  While this can be often correctly assumed
or 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):
As a further mitigation against amplification attacks, a server
can also rely on the Echo Option for CoAP defined in I-D.ietf-
core-echo-request-tag and include it in a response to a group
request.  By doing so, the server can assert that the alleged
sender of the group request (i.e., the CoAP client associated 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 still 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 inferable from the application context, it is not explicit from
the group request itself, since Group OSCORE protects the Uri-Path
and Uri-Query CoAP Options conveying the respective components of
the target URI.
Paragraph (version B):
As a further mitigation against amplification attacks, a server
can also rely on the Echo Option for CoAP defined in RFC9175 and
include it in a response to a group request.  By doing so, the
server can assert that the alleged sender of the group request
(i.e., the CoAP client associated with a certain authentication
credential including the corresponding public key) is indeed
reachable at the claimed source address, especially if this
differs from the one used in previous group requests from the same
CoAP client.  Although responses including the Echo Option do
still result in amplification, this is limited in volume compared
to when all servers reply with a full-fledged response.
Paragraph (version A):
As noted above, the server may additionally rely on the Echo
Option for CoAP defined in I-D.ietf-core-echo-request-tag, in
order to verify the aliveness and reachability of the client
sending a request from a particular IP address.
Paragraph (version B):
As noted above, the server may additionally rely on the Echo
Option for CoAP defined in RFC9175, in order to verify the
aliveness and reachability of the client sending a request from a
particular IP address.
Paragraph (version A):
Section 3.1 of I-D.mattsson-core-coap-attacks further discusses
amplification attacks, and also notes how the amplification factor
would become even higher when CoAP 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 A):
Thus, consistently with Section 7 of RFC7641, a server in a CoAP
group MUST strictly limit the number of notifications it sends
between receiving acknowledgements that confirm the actual interest
of the client in continuing the observation.
Paragraph (version B):
Amplifications attacks using CoAP are further discussed in I-
D.mattsson-t2trg-amplification-attacks, which also highlights how the
amplification factor would become even higher when CoAP 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):
Thus, consistently with Section 7 of RFC7641, a server in a CoAP
group MUST strictly limit the number of notifications it sends
between receiving acknowledgments that confirm the actual interest of
the client in continuing the observation.
Paragraph (version A):
If Group OSCORE is used, such a replay attack on the servers is
prevented, since a client protects every different request with a
different Sequence Number value, which is in turn included as Partial
IV in the protected message and takes part in the construction of the
AEAD cipher nonce.  Thus, a server would be able to detect the
replayed request, by checking the conveyed Partial IV against its own
replay window in the OSCORE Recipient Context associated to the
client.
Paragraph (version B):
If Group OSCORE is used, such a replay attack on the servers is
prevented, since a client protects every different request with a
different Sequence Number value, which is in turn included as Partial
IV in the protected message and takes part in the construction of the
AEAD cipher nonce.  Thus, a server would be able to detect the
replayed request, by checking the conveyed Partial IV against its own
replay window in the OSCORE Recipient Context associated with the
client.
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 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 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 RFC9175, in order to (re-)synchronize with the client's
sequence number.
Paragraph (version B):
When CoAP group communication is used in CoAP NoSec (No Security)
mode (see chap-unsecured-groupcomm), the CoAP No-Response Option
RFC7967 could be misused by a malicious client to evoke as much
responses from servers to a group request as possible, by using the
value '0' - Interested in all responses.  This even overrides the
default behavior of a CoAP server to suppress the response in case
there is nothing of interest to respond with.  Therefore, this option
can be used to perform an amplification attack (see ssec-
amplification).