Draft: draft-ietf-core-groupcomm-bis

Commentary: Asking this for another I - D : is putting the names of contributors in brackets like " { { { Christian Amsüss } } } , { { {   } } } , " etc . sufficient to make these persons as contributors to the document , and so that IETF can keep statistics on this ? I heard from another source that the names need to be in a " Contributors " section for the IETF to count this and not in an " Acknowledgements " section . But that may be wrong . 
 Right — you need to install aasvg , e.g. ,    -g aasvg More at ( And the links from there . )  ,  
 { { { … } } } is a shorthand for using the < contact element of RFCXMLv3 . This element ... marks the text as a human name makes sure that Umlauts etc . survive . See … for more details ( including how to handle non - Latin contact names . ) It depends on the tool used for mining the RFCs whether contact names in acknowledgment sections are handled in a specific way . A stronger way to acknowledge someone as a contributor is to include them in the contributor section , which also makes it possible to include email addresses , affiliation etc . , if desired . The and YAML header entries look the same , so someone can be shuttled between authorship and mere contributorship by just moving over the YAML . Please see ... more detail and an example . BTW , 1.6.6 indeed is the current version of kramdown - rfc ( released this Sunday ) .  ,    with all the improvements , thanks for this Carsten ! One issue I had with the compilation for the " aasvg " option on two figures - on my Windows MSYS2 setup the most recent kramdown - rfc2629 version seems to be 1.6.6.Thanks for reviewing and for the proposed changes !
Paragraph (version A):
This documents replaces and obsoletes RFC7390, while it updates both
RFC7252 and RFC7641.  A summary of the changes and additions to these
documents is provided in changes.
Paragraph (version B):
This document replaces and obsoletes RFC7390, while it updates both
RFC7252 and RFC7641.  A summary of the changes and additions to these
documents is provided in changes.
Paragraph (version A):
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):
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 can contain a UDP port number
in the authority component.  Group URIs follow the regular CoAP
URI syntax (see Section 6 of RFC7252).
Paragraph (version A):
It defines separate definitions for CoAP groups, application
groups and security groups, together with high-level guidelines on
their configuration (see chap-general-groupcomm).
Paragraph (version B):
It provides separate definitions for CoAP groups, application
groups and security groups, together with high-level guidelines on
their configuration (see chap-general-groupcomm).
Paragraph (version A):
On one hand, multiple application groups may use the same security
group.  Thus, the same group security material is used to protect the
messages targeting any of those application groups.  This has the
benefit that typically less storage, configuration and updating are
required for security material.  In this case, a CoAP endpoint is
supposed to know the exact application group to refer to for each
message that is sent or received, based on, e.g., the used server
port number, the targeted resource, or the content and structure of
the message payload.
Paragraph (version B):
On one hand, multiple application groups may use the same security
group.  Thus, the same group security material is used to protect the
messages targeting any of those application groups.  This has the
benefit that typically less storage, configuration and updating are
required for security material.  In this case, a CoAP endpoint is
supposed to know the exact application group to refer to for each
message that is sent or received, based on, e.g., the server port
number used, the targeted resource, or the content and structure of
the message payload.
Paragraph (version A):
Beyond this particular case, applications should be careful in
associating a same application group to multiple security groups.  In
particular, it is NOT RECOMMENDED to use different security groups to
reflect different access policies for resources in a same application
group.  That is, being a member of a security group actually grants
access only to exchange secured messages and enables authentication
of group members, while access control (authorization) to use
resources in the application group belongs to a separate security
domain.  It has to be separately enforced by leveraging the resource
properties or through dedicated access control credentials assessed
by separate means.
Paragraph (version B):
Beyond this particular case, applications should be careful in
associating a single application group to multiple security groups.
In particular, it is NOT RECOMMENDED to use different security groups
to reflect different access policies for resources in the same
application group.  That is, being a member of a security group
actually grants access only to exchange secured messages and enables
authentication of group members, while access control (authorization)
to use resources in the application group belongs to a separate
security domain.  It has to be separately enforced by leveraging the
resource properties or through dedicated access control credentials
assessed by separate means.
Paragraph (version A):
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 number 5683 are used in the authority component.
Also the resource structure is different in this example.
Paragraph (version B):
A full 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 number 5683 are used in the authority component.  Also the
resource structure is different in this example.
Paragraph (version A):
As a first alternative, the URI query component consists of
only one parameter, which has no value and has the name of the
application group as its own idenfier.  That is, the query
component ?GROUPNAME conforms to this format.
Paragraph (version A):
A full-fledged example is provided in fig-gname-query1-example.
Paragraph (version B):
As a first alternative, the URI query component consists of
only one parameter, which has no value and has the name of the
application group as its own identifier.  That is, the query
component ?GROUPNAME conforms to this format.
Paragraph (version B):
A full example is provided in fig-gname-query1-example.
Paragraph (version A):
A full-fledged example is provided in fig-gname-query2-example.
Paragraph (version B):
A full example is provided in fig-gname-query2-example.
Paragraph (version A):
A full-fledged example is provided in fig-gname-auth-example.
Paragraph (version B):
A full example is provided in fig-gname-auth-example.
Paragraph (version A):
A full-fledged example is provided in fig-gname-host-example.
Paragraph (version B):
A full example is provided in fig-gname-host-example.
Paragraph (version A):
A full-fledged example is provided in fig-gname-post-example.
Paragraph (version A):
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):
A full 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 a method is summarized below.
Paragraph (version A):
A full-fledged example is provided in fig-gname-custom-option-
example.
Paragraph (version B):
A full example is provided in fig-gname-custom-option-example.
Paragraph (version A):
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):
Finally, Appendix A of I-D.ietf-core-resource-directory provides an
example of an application group registered to a Resource Directory
(RD), along with the CoAP group it uses and the resources it
supports.  In that example, an application group name "lights" is
encoded in the "ep" (endpoint) attribute of the RD registration
entry.  At the same time, the CoAP group is
ff35:30:2001:db8:f1::8000:1 and the "NoSec" security group is used.
Paragraph (version A):
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):
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 A):
A full-fledged example is provided in fig-app-gp-discovery-
example1.
Paragraph (version B):
A full example is provided in fig-app-gp-discovery-example1.
Paragraph (version A):
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 full example is provided in fig-app-gp-discovery-example2.  Note
that the servers need to respond now with an absolute URI and not
a relative URI like in the previous example, because the group
resource "gp1" is hosted at the authority indicated by the CoAP
group (grp.example.org:5685) and not by the authority that is
serving the Link Format document (which is [ff03::fd]:5683).
Paragraph (version A):
A full-fledged example is provided in fig-app-gp-discovery-
example3.
Paragraph (version B):
A full example is provided in fig-app-gp-discovery-example3.
Paragraph (version A):
A full-fledged example is provided in fig-app-gp-discovery-
example4.
Paragraph (version B):
A full example is provided in fig-app-gp-discovery-example4.
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.  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 carry a mixture of
success (e.g., 2.05 Content) and failure (e.g., 4.04 Not Found)
response codes, depending on the individual server processing
results.
Paragraph (version B):
The URI Path used in a group request is preferably a path that is
known to be supported across all group members.  However, there are
valid use cases where a group request is known to be successful only
for a subset of the CoAP group, for example only members of a
specific application group, while those group members for which the
request is unsuccessful (for example because they are outside the
application group) either ignore the group request or respond with an
error status code.
Paragraph (version A):
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 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 may still be able to
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 B):
Furthermore, the reverse-proxy can actually stand in for (and thus
prevent directly reaching) only the whole set of servers in the
group, or also for each of those individual servers (e.g., if acting
as firewall).
Paragraph (version B):
The CoAP Observe Option RFC7641 is a protocol extension of CoAP,
which allows a CoAP client to retrieve a representation of a resource
and automatically keep this representation up-to-date over a longer
period of time.  The client gets notified when the representation has
changed.  RFC7641 does not mention whether the Observe Option can be
combined with CoAP (multicast) group communication.
Paragraph (version B):
To retrieve any further blocks of the resource from a responding
server, the client then has to use unicast requests, separately
addressing each different server.  Also, a server (member of a
targeted CoAP group) that needs to respond to a group request with a
particularly large resource can use block-wise transfer (Block2
Option) at its own initiative, to limit the size of the initial
response.  Again, a client would have to use unicast for any further
requests to retrieve more blocks of the resource.
Paragraph (version A):
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):
RFC9177 specifies a specialized alternative method for CoAP block-
wise transfer.  It specifies that "servers MUST ignore multicast
requests that contain the Q-Block2 Option".
Paragraph (version A):
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 members of the CoAP group, i.e., the CoAP endpoints that are
configured to receive CoAP group messages sent to the particular
group and - in case of IP multicast transport - that are listening
to the group's multicast IP address on the group's UDP port.
Paragraph (version A):
This ensures forward security in the OSCORE group.  That is, it
ensures that only the members intended to remain in the OSCORE
group are able to continue participating in the secure
communications within that group, while the evicted ones are not
able to after the distribution and installation of the new
security material.
Paragraph (version B):
This ensures forward security in the OSCORE group.  That is, it
ensures that only the members intended to remain in the OSCORE
group are able to continue participating in the secure
communications within that group, while the evicted ones are not
able to participate after the distribution and installation of the
new security material.
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, 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 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 and greatly
effective, since a single request can result in multiple responses
from multiple servers (see ssec-amplification).
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):
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):
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 frequently joining and leaving,
and at the same time a single group rekeying instance taking a non-
negligible time to complete.
Paragraph (version A):
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):
At the same time, the security implications of delaying the rekeying
process have to be carefully considered and understood before
employing such group policies.
Paragraph (version A):
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 joining, 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):
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 joining, 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 retain access to group
communications protected with the existing security material.
Paragraph (version A):
to when all servers reply with a full-fledged response.
Paragraph (version B):
to when all servers reply with a full response.
Paragraph (version A):
SHOULD NOT provide large amplification factors through its
responses to a non-authenticated group request, and can possibly
rely on CoAP block-wise transfers RFC7959 to reduce the amount of
amplification.
Paragraph (version A):
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):
SHOULD NOT provide large amplification factors through its
responses to a non-authenticated group request, possibly employing
CoAP block-wise transfers RFC7959 to reduce the amount of
amplification.
Paragraph (version B):
Amplification 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 A):
A relevant exceptional example is a CoAP client performing the
discovery of hosts such as a group manager or a Resource Directory I-
D.ietf-core-resource-directory, by probing for them through a group
request sent to the CoAP group.  This early, unprotected step is
relevant for a CoAP client that does not know the address of such
hosts in advance, and that does not have yet configured a mutual
security relation with them.  In this kind of deployments, such a
discovery procedure does not result in a considerable and harmful
amplification, since only the few CoAP servers object of discovery
are going to respond to the group request targeting that specific
resource.  In particular, those hosts can be the only CoAP servers in
that specific CoAP group (hence listening for group requests sent to
that group), and/or the only CoAP servers explicitly configured to
respond to group requests targeting specific group resources.
Paragraph (version B):
A relevant exceptional example is a CoAP client performing the
discovery of hosts such as a group manager or a Resource Directory I-
D.ietf-core-resource-directory, by probing for them through a group
request sent to the CoAP group.  This early, unprotected step is
relevant for a CoAP client that does not know the address of such
hosts in advance, and that does not have yet configured a mutual
security relation with them.  In this kind of deployments, such a
discovery procedure does not result in a considerable and harmful
amplification, since only the few CoAP servers that are the object of
discovery are going to respond to the group request targeting that
specific resource.  In particular, those hosts can be the only CoAP
servers in that specific CoAP group (hence listening for group
requests sent to that group), and/or the only CoAP servers explicitly
configured to respond to group requests targeting specific group
resources.
Paragraph (version A):
Since all requests sent over IP multicast are Non-confirmable, a
client might not be able to know if an adversary has actually
captured one of its transmitted requests and later re-injected it in
the group as a replay to the server nodes.  In fact, even if the
servers sent back responses to the replayed request, the client would
typically not have a valid matching request active anymore so this
attack would not accomplish anything in the client.
Paragraph (version A):
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 B):
Since all requests sent over IP multicast are Non-confirmable, a
client might not be able to know if an adversary has actually
captured one of its transmitted requests and later re-injected it in
the group as a replay to the server nodes.  In fact, even if the
servers sent back responses to the replayed request, the client would
typically not have a valid matching request active anymore, so this
attack would not accomplish anything in the client.
Paragraph (version B):
If Group OSCORE is used, such a replay attack on the servers is
prevented, since a client protects each 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 RFC9175, 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 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).
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 based on the Echo Option
for CoAP defined in RFC9175 as described in Appendix E of I-D.ietf-
core-oscore-groupcomm, 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 many
responses from servers to a group request as possible, by using the
value '0' - Interested in all responses.  This might even override
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).
Paragraph (version A):
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 B):
SHOULD implement a filtering criterion 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).