Skip to content

Commit

Permalink
Script updating gh-pages from cc477f7. [ci skip]
Browse files Browse the repository at this point in the history
  • Loading branch information
ID Bot committed Oct 19, 2023
1 parent 89b8d14 commit 11d8f3c
Show file tree
Hide file tree
Showing 2 changed files with 53 additions and 23 deletions.
13 changes: 9 additions & 4 deletions john-comments/draft-ietf-core-groupcomm-bis.html
View file
Original file line number Diff line number Diff line change
Expand Up @@ -2622,12 +2622,13 @@ <h3 id="name-coap-nosec-mode">
<a href="#section-6.1" class="section-number selfRef">6.1. </a><a href="#name-coap-nosec-mode" class="section-name selfRef">CoAP NoSec Mode</a>
</h3>
<p id="section-6.1-1">CoAP group communication, if not protected, is vulnerable to all the attacks mentioned in <span><a href="https://rfc-editor.org/rfc/rfc7252#section-11" class="relref">Section 11</a> of [<a href="#RFC7252" class="cite xref">RFC7252</a>]</span> for IP multicast. Moreover, as also discussed in <span>[<a href="#I-D.irtf-t2trg-amplification-attacks" class="cite xref">I-D.irtf-t2trg-amplification-attacks</a>]</span>, 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 <a href="#ssec-amplification" class="auto internal xref">Section 6.3</a>).<a href="#section-6.1-1" class="pilcrow"></a></p>
<p id="section-6.1-2">Therefore, it is generally NOT RECOMMENDED to use CoAP group communication in NoSec mode, also in order to prevent an easy proliferation of high-volume amplification attacks as further discussed in <a href="#ssec-amplification" class="auto internal xref">Section 6.3</a>.
<p id="section-6.1-2">Therefore, it is NOT RECOMMENDED to use CoAP group communication in NoSec mode, also in order to prevent proliferation of high-volume amplification attacks as further discussed in <a href="#ssec-amplification" class="auto internal xref">Section 6.3</a>.
The requirement in <a href="#chap-unsecured-groupcomm" class="auto internal xref">Section 4</a> on publically accessible CoAP servers also aims to prevent amplification attacks.<a href="#section-6.1-2" class="pilcrow"></a></p>
<p id="section-6.1-3">Exceptionally, and only after the security implications have been very well considered and understood, some applications may rely on a limited use of the NoSec mode, when performing specific, well-defined steps that are proven to not require security or to not be able to attain it.<a href="#section-6.1-3" class="pilcrow"></a></p>
<p id="section-6.1-4">For example, early discovery of devices and resources is a typical use case where the NoSec mode is relevant to use. In such a situation, the querying devices do not have yet configured any mutual security relations at the time they perform the discovery. Also, high-volume and harmful amplifications can be prevented through appropriate and conservative configurations, since only a few CoAP servers are expected to be configured for responding to the group requests sent for discovery (see <a href="#ssec-amplification" class="auto internal xref">Section 6.3</a>).<a href="#section-6.1-4" class="pilcrow"></a></p>
<p id="section-6.1-5">As a further example, the NoSec mode may be relevant to use in simple applications that neither involve nor may have an impact on sensitive data and personal sphere. These include, e.g., read-only temperature sensors deployed in non-sensitive environments, where the client reads out the values but does not use the data to control actuators or to base important decisions on.<a href="#section-6.1-5" class="pilcrow"></a></p>
<p id="section-6.1-6">Except for the class of applications discussed above, and all the more so in applications that obviously have hard security requirements (e.g., health monitoring systems and alarm monitoring systems), CoAP group communication MUST NOT be used in NoSec mode.<a href="#section-6.1-6" class="pilcrow"></a></p>
<p id="section-6.1-4">For example, early link-local discovery of devices and resources as part of an onboarding protocol is a typical use case where the NoSec mode or equivalent unsecured mode is used. In such a discovery step, there may be a querying device that needs to discover nearby devices capable of helping it with the network onboarding process. But there are no mutual security relations configured on the querying device and its neighbor devices at the time it performs the early discovery. These relations are configured later in the process based on secure device identities. Alternatively, a new device to be onboarded may wait for advertisements of nearby devices able to help it do the network onboarding process. Also in this case, these messages cannot be secured initially because the new device does not yet have any security relation configured with devices that are already a member of the network. See <span>[<a href="#I-D.ietf-anima-constrained-voucher" class="cite xref">I-D.ietf-anima-constrained-voucher</a>]</span> for an example of an onboarding protocol that can use CoAP multicast for early link-local discovery.<a href="#section-6.1-4" class="pilcrow"></a></p>
<p id="section-6.1-5">As a further example, the NoSec mode may be useful in simple applications that neither involve nor may have an impact on sensitive data and personal information. These include, e.g., read-only temperature sensors deployed in an environment where a client reads temperature values but does not use this data to control actuators or to perform other automated actions.<a href="#section-6.1-5" class="pilcrow"></a></p>
<p id="section-6.1-6">In the exception cases where NoSec mode is used, high-volume and harmful amplifications need to be prevented through appropriate and conservative device configurations: taking the early discovery query as an example, only a few CoAP servers are expected to be configured for responding to multicast group requests that are sent for discovery. And the time window during which such unsecured requests are accepted, can be limited as well. Furthermore the scope is also limited: only link-local requests are accepted.<a href="#section-6.1-6" class="pilcrow"></a></p>
<p id="section-6.1-7">Except for the class of applications discussed above, and all the more so in applications that obviously have hard security requirements (e.g., health monitoring systems and alarm monitoring systems), CoAP group communication MUST NOT be used in NoSec mode.<a href="#section-6.1-7" class="pilcrow"></a></p>
</section>
</div>
<div id="chap-security-considerations-sec-mode">
Expand Down Expand Up @@ -2952,6 +2953,10 @@ <h3 id="name-informative-references">
<dd>
<span class="refAuthor">Tiloca, M.</span>, <span class="refAuthor">Höglund, R.</span>, <span class="refAuthor">Van der Stok, P.</span>, and <span class="refAuthor">F. Palombini</span>, <span class="refTitle">"Admin Interface for the OSCORE Group Manager"</span>, <span class="refContent">Work in Progress</span>, <span class="seriesInfo">Internet-Draft, draft-ietf-ace-oscore-gm-admin-09</span>, <time datetime="2023-07-01" class="refDate">1 July 2023</time>, <span>&lt;<a href="https://datatracker.ietf.org/doc/html/draft-ietf-ace-oscore-gm-admin-09">https://datatracker.ietf.org/doc/html/draft-ietf-ace-oscore-gm-admin-09</a>&gt;</span>. </dd>
<dd class="break"></dd>
<dt id="I-D.ietf-anima-constrained-voucher">[I-D.ietf-anima-constrained-voucher]</dt>
<dd>
<span class="refAuthor">Richardson, M.</span>, <span class="refAuthor">Van der Stok, P.</span>, <span class="refAuthor">Kampanakis, P.</span>, and <span class="refAuthor">E. Dijk</span>, <span class="refTitle">"Constrained Bootstrapping Remote Secure Key Infrastructure (BRSKI)"</span>, <span class="refContent">Work in Progress</span>, <span class="seriesInfo">Internet-Draft, draft-ietf-anima-constrained-voucher-21</span>, <time datetime="2023-07-07" class="refDate">7 July 2023</time>, <span>&lt;<a href="https://datatracker.ietf.org/doc/html/draft-ietf-anima-constrained-voucher-21">https://datatracker.ietf.org/doc/html/draft-ietf-anima-constrained-voucher-21</a>&gt;</span>. </dd>
<dd class="break"></dd>
<dt id="I-D.ietf-core-coap-pubsub">[I-D.ietf-core-coap-pubsub]</dt>
<dd>
<span class="refAuthor">Koster, M.</span>, <span class="refAuthor">Keränen, A.</span>, and <span class="refAuthor">J. Jimenez</span>, <span class="refTitle">"A publish-subscribe architecture for the Constrained Application Protocol (CoAP)"</span>, <span class="refContent">Work in Progress</span>, <span class="seriesInfo">Internet-Draft, draft-ietf-core-coap-pubsub-12</span>, <time datetime="2023-03-13" class="refDate">13 March 2023</time>, <span>&lt;<a href="https://datatracker.ietf.org/doc/html/draft-ietf-core-coap-pubsub-12">https://datatracker.ietf.org/doc/html/draft-ietf-core-coap-pubsub-12</a>&gt;</span>. </dd>
Expand Down
63 changes: 44 additions & 19 deletions john-comments/draft-ietf-core-groupcomm-bis.txt
View file
Original file line number Diff line number Diff line change
Expand Up @@ -2271,33 +2271,50 @@ Table of Contents
especially feasible and greatly effective, since a single request can
result in multiple responses from multiple servers (see Section 6.3).

Therefore, it is generally NOT RECOMMENDED to use CoAP group
communication in NoSec mode, also in order to prevent an easy
proliferation of high-volume amplification attacks as further
discussed in Section 6.3. The requirement in Section 4 on publically
accessible CoAP servers also aims to prevent amplification attacks.
Therefore, it is NOT RECOMMENDED to use CoAP group communication in
NoSec mode, also in order to prevent proliferation of high-volume
amplification attacks as further discussed in Section 6.3. The
requirement in Section 4 on publically accessible CoAP servers also
aims to prevent amplification attacks.

Exceptionally, and only after the security implications have been
very well considered and understood, some applications may rely on a
limited use of the NoSec mode, when performing specific, well-defined
steps that are proven to not require security or to not be able to
attain it.

For example, early discovery of devices and resources is a typical
use case where the NoSec mode is relevant to use. In such a
situation, the querying devices do not have yet configured any mutual
security relations at the time they perform the discovery. Also,
high-volume and harmful amplifications can be prevented through
appropriate and conservative configurations, since only a few CoAP
servers are expected to be configured for responding to the group
requests sent for discovery (see Section 6.3).

As a further example, the NoSec mode may be relevant to use in simple
For example, early link-local discovery of devices and resources as
part of an onboarding protocol is a typical use case where the NoSec
mode or equivalent unsecured mode is used. In such a discovery step,
there may be a querying device that needs to discover nearby devices
capable of helping it with the network onboarding process. But there
are no mutual security relations configured on the querying device
and its neighbor devices at the time it performs the early discovery.
These relations are configured later in the process based on secure
device identities. Alternatively, a new device to be onboarded may
wait for advertisements of nearby devices able to help it do the
network onboarding process. Also in this case, these messages cannot
be secured initially because the new device does not yet have any
security relation configured with devices that are already a member
of the network. See [I-D.ietf-anima-constrained-voucher] for an
example of an onboarding protocol that can use CoAP multicast for
early link-local discovery.

As a further example, the NoSec mode may be useful in simple
applications that neither involve nor may have an impact on sensitive
data and personal sphere. These include, e.g., read-only temperature
sensors deployed in non-sensitive environments, where the client
reads out the values but does not use the data to control actuators
or to base important decisions on.
data and personal information. These include, e.g., read-only
temperature sensors deployed in an environment where a client reads
temperature values but does not use this data to control actuators or
to perform other automated actions.

In the exception cases where NoSec mode is used, high-volume and
harmful amplifications need to be prevented through appropriate and
conservative device configurations: taking the early discovery query
as an example, only a few CoAP servers are expected to be configured
for responding to multicast group requests that are sent for
discovery. And the time window during which such unsecured requests
are accepted, can be limited as well. Furthermore the scope is also
limited: only link-local requests are accepted.

Except for the class of applications discussed above, and all the
more so in applications that obviously have hard security
Expand Down Expand Up @@ -2902,6 +2919,14 @@ Table of Contents
<https://datatracker.ietf.org/doc/html/draft-ietf-ace-
oscore-gm-admin-09>.

[I-D.ietf-anima-constrained-voucher]
Richardson, M., Van der Stok, P., Kampanakis, P., and E.
Dijk, "Constrained Bootstrapping Remote Secure Key
Infrastructure (BRSKI)", Work in Progress, Internet-Draft,
draft-ietf-anima-constrained-voucher-21, 7 July 2023,
<https://datatracker.ietf.org/doc/html/draft-ietf-anima-
constrained-voucher-21>.

[I-D.ietf-core-coap-pubsub]
Koster, M., Keränen, A., and J. Jimenez, "A publish-
subscribe architecture for the Constrained Application
Expand Down

0 comments on commit 11d8f3c

Please sign in to comment.