From f37864e31a18e4a9527b304083222db961e1f636 Mon Sep 17 00:00:00 2001 From: ID Bot Date: Tue, 10 Oct 2023 11:48:41 +0000 Subject: [PATCH] Script updating gh-pages from 2d324bd. [ci skip] --- .../draft-ietf-core-groupcomm-bis.html | 938 +++++++++++++----- .../draft-ietf-core-groupcomm-bis.txt | 40 +- 2 files changed, 700 insertions(+), 278 deletions(-) diff --git a/john-comments/draft-ietf-core-groupcomm-bis.html b/john-comments/draft-ietf-core-groupcomm-bis.html index 518bded..24aeee3 100644 --- a/john-comments/draft-ietf-core-groupcomm-bis.html +++ b/john-comments/draft-ietf-core-groupcomm-bis.html @@ -9,7 +9,7 @@ @@ -1031,7 +1031,7 @@ Dijk, et al. -Expires 10 April 2024 +Expires 12 April 2024 [Page] @@ -1050,12 +1050,12 @@ 7252, 7641 (if approved)
Published:
- +
Intended Status:
Standards Track
Expires:
-
+
Authors:
@@ -1076,7 +1076,7 @@

Group Communication for the Constrained Application Protocol (CoAP)

Abstract

-

This document specifies the use of the Constrained Application Protocol (CoAP) for group communication, including the use of UDP/IP multicast as the default underlying data transport. Both unsecured and secured CoAP group communication are specified. Security is achieved by use of the Group Object Security for Constrained RESTful Environments (Group OSCORE) protocol. The target application area of this specification is any group communication use cases that involve resource-constrained devices or networks that support CoAP. This document replaces RFC 7390, while it updates RFC 7252 and RFC 7641.

+

This document specifies the use of the Constrained Application Protocol (CoAP) for group communication, including the use of UDP/IP multicast as the default underlying data transport. Both unsecured and secured CoAP group communication are specified. Security is achieved by use of the Group Object Security for Constrained RESTful Environments (Group OSCORE) protocol. The target application area of this specification is any group communication use cases that involve resource-constrained devices or networks that support CoAP. This document replaces and obsoletes RFC 7390, while it updates RFC 7252 and RFC 7641.

@@ -1108,7 +1108,7 @@

time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as "work in progress."

- This Internet-Draft will expire on 10 April 2024.

+ This Internet-Draft will expire on 12 April 2024.

@@ -2526,7 +2529,8 @@

CoAP group communication can operate in CoAP NoSec (No Security) mode, without using application-layer and transport-layer security mechanisms. The NoSec mode uses the "coap" scheme, and is defined in Section 9 of [RFC7252].

The NoSec mode does not require and does not make use of a security group. Indications that endpoints can use the NoSec mode MUST NOT rely on setting up and advertising a pseudo security group with name "NoSec" or any of its lowercase/uppercase combinations.

-

It is NOT RECOMMENDED to use CoAP group communication in NoSec mode.

+

A CoAP server in NoSec mode MUST NOT be accessible through the public Internet. +It is NOT RECOMMENDED to use CoAP group communication in NoSec mode.

The possible, exceptional use of the NoSec mode ought to be limited to: applications that are proven to be neither sensitive nor critical; and specific, well-defined steps where security is not viable or is intrinsically unattainable, e.g., early discovery of devices and resources (see Section 6.1).

Before possibly and exceptionally using the NoSec mode in such circumstances, the security implications in Section 6.1 must be very well considered and understood, especially as to the risk and impact of amplification attacks (see Section 6.3). Consistently with such security implications, the use of the NoSec mode should still be avoided whenever possible.

@@ -2617,7 +2621,8 @@

6.1. CoAP NoSec Mode

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.irtf-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 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.

+

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.

Exceptionally, and only after the security implications have been very well considered and understood, some non-sensitive and non-critical applications may rely on a limited and well-defined use of the NoSec mode.

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 non-critical 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.

@@ -3580,39 +3585,104 @@

In Figure 16, the client sends a Non-confirmable GET request to the CoAP group, targeting the resource "temperature" in the application group "gp1". All servers reply with a 2.05 (Content) response, although the response from server B is lost. As source port number of their response, servers A and B use the destination port number of the request, i.e., PORT_GRP. Instead, server C uses its own port number PORT_C.

-
-
-Client              A  B  C
-   |                |  |  |
-   |  GET           |  |  |
-   +-------+------->|  |  | Source: ADDR_CLIENT:PORT_CLIENT
-   |        \       |  |  | Destination: ADDR_GRP:PORT_GRP
-   |         `.------->|  | Header: GET (T=NON, Code=0.01, MID=0x7d41)
-   |           `.   |  |  | Token: 0x86
-   |             `------->| Uri-Path: "gp"
-   |                |  |  | Uri-Path: "gp1"
-   |                |  |  | Uri-Path: "temperature"
-   |                |  |  |
-   |<---------------+  |  | Source: ADDR_A:PORT_GRP
-   |      2.05      |  |  | Destination: ADDR_CLIENT:PORT_CLIENT
-   |                |  |  | Header: 2.05 (T=NON, Code=2.05, MID=0x60b1)
-   |                |  |  | Token: 0x86
-   |                |  |  | Payload: "22.3 C"
-   |                |  |  |
-   |   X---------------+  | Source: ADDR_B:PORT_GRP
-   |      2.05      |  |  | Destination: ADDR_CLIENT:PORT_CLIENT
-   |                |  |  | Header: 2.05 (T=NON, Code=2.05, MID=0x01a0)
-   |                |  |  | Token: 0x86
-   |                |  |  | Payload: "20.9 C"
-   |                |  |  |
-   |                |  |  |
-   |<---------------------+ Source: ADDR_C:PORT_C
-   |      2.05      |  |  | Destination: ADDR_CLIENT:PORT_CLIENT
-   |                |  |  | Header: 2.05 (T=NON, Code=2.05, MID=0x952a)
-   |                |  |  | Token: 0x86
-   |                |  |  | Payload: "21.0 C"
-   |                |  |  |
-
+
+
+ + + + + + + + + + + + + + + + + + + + + + + + Client + A + B + C + GET + Source: + ADDR_CLIENT:PORT_CLIENT + Destination: + ADDR_GRP:PORT_GRP + Header: + GET + (T=NON, + Code=0.01, + MID=0x7d41) + `. + | + Token: + 0x86 + Uri-Path: + "gp" + Uri-Path: + "gp1" + Uri-Path: + "temperature" + Source: + ADDR_A:PORT_GRP + 2.05 + Destination: + ADDR_CLIENT:PORT_CLIENT + Header: + 2.05 + (T=NON, + Code=2.05, + MID=0x60b1) + Token: + 0x86 + Payload: + "22.3 + C" + X + Source: + ADDR_B:PORT_GRP + 2.05 + Destination: + ADDR_CLIENT:PORT_CLIENT + Header: + 2.05 + (T=NON, + Code=2.05, + MID=0x01a0) + Token: + 0x86 + Payload: + "20.9 + C" + Source: + ADDR_C:PORT_C + 2.05 + Destination: + ADDR_CLIENT:PORT_CLIENT + Header: + 2.05 + (T=NON, + Code=2.05, + MID=0x952a) + Token: + 0x86 + Payload: + "21.0 + C" + + +
Figure 16: Example of Non-confirmable group request, followed by Non-confirmable Responses @@ -3621,67 +3691,182 @@

In Figure 17, the client sends a Non-confirmable GET request to the CoAP group, targeting and requesting to observe the resource "temperature" in the application group "gp1". All servers reply with a 2.05 (Content) notification response. As source port number of their response, servers A and B use the destination port number of the request, i.e., PORT_GRP. Instead, server C uses its own port number PORT_C. Some time later, all servers send a 2.05 (Content) notification response, with the new representation of the "temperature" resource as payload.

-
-
-Client              A  B  C
-   |                |  |  |
-   |  GET           |  |  |
-   +-------+------->|  |  | Source: ADDR_CLIENT:PORT_CLIENT
-   |        \       |  |  | Destination: ADDR_GRP:PORT_GRP
-   |         `.------->|  | Header: GET (T=NON, Code=0.01, MID=0x7d41)
-   |           `.   |  |  | Token: 0x86
-   |             `------->| Observe: 0 (register)
-   |                |  |  | Uri-Path: "gp"
-   |                |  |  | Uri-Path: "gp1"
-   |                |  |  | Uri-Path: "temperature"
-   |                |  |  |
-   |<---------------+  |  | Source: ADDR_A:PORT_GRP
-   |      2.05      |  |  | Destination: ADDR_CLIENT:PORT_CLIENT
-   |                |  |  | Header: 2.05 (T=NON, Code=2.05, MID=0x60b1)
-   |                |  |  | Token: 0x86
-   |                |  |  | Observe: 3
-   |                |  |  | Payload: "22.3 C"
-   |                |  |  |
-   |<------------------+  | Source: ADDR_B:PORT_GRP
-   |      2.05      |  |  | Destination: ADDR_CLIENT:PORT_CLIENT
-   |                |  |  | Header: 2.05 (T=NON, Code=2.05, MID=0x01a0)
-   |                |  |  | Token: 0x86
-   |                |  |  | Observe: 13
-   |                |  |  | Payload: "20.9 C"
-   |                |  |  |
-   |<---------------------+ Source: ADDR_C:PORT_C
-   |      2.05      |  |  | Destination: ADDR_CLIENT:PORT_CLIENT
-   |                |  |  | Header: 2.05 (T=NON, Code=2.05, MID=0x952a)
-   |                |  |  | Token: 0x86
-   |                |  |  | Observe: 23
-   |                |  |  | Payload: "21.0 C"
-   |                |  |  |
-
-   // The temperature changes ...
-
-   |                |  |  |
-   |<---------------+  |  | Source: ADDR_A:PORT_GRP
-   |      2.05      |  |  | Destination: ADDR_CLIENT:PORT_CLIENT
-   |                |  |  | Header: 2.05 (T=NON, Code=2.05, MID=0x60b2)
-   |                |  |  | Token: 0x86
-   |                |  |  | Observe: 7
-   |                |  |  | Payload: "32.3 C"
-   |                |  |  |
-   |<------------------+  | Source: ADDR_B:PORT_GRP
-   |      2.05      |  |  | Destination: ADDR_CLIENT:PORT_CLIENT
-   |                |  |  | Header: 2.05 (T=NON, Code=2.05, MID=0x01a1)
-   |                |  |  | Token: 0x86
-   |                |  |  | Observe: 18
-   |                |  |  | Payload: "30.9 C"
-   |                |  |  |
-   |<---------------------+ Source: ADDR_C:PORT_C
-   |      2.05      |  |  | Destination: ADDR_CLIENT:PORT_CLIENT
-   |                |  |  | Header: 2.05 (T=NON, Code=2.05, MID=0x952b)
-   |                |  |  | Token: 0x86
-   |                |  |  | Observe: 29
-   |                |  |  | Payload: "31.0 C"
-   |                |  |  |
-
+
+
+ + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + Client + A + B + C + GET + Source: + ADDR_CLIENT:PORT_CLIENT + Destination: + ADDR_GRP:PORT_GRP + Header: + GET + (T=NON, + Code=0.01, + MID=0x7d41) + `. + | + Token: + 0x86 + Observe: + 0 + (register) + Uri-Path: + "gp" + Uri-Path: + "gp1" + Uri-Path: + "temperature" + Source: + ADDR_A:PORT_GRP + 2.05 + Destination: + ADDR_CLIENT:PORT_CLIENT + Header: + 2.05 + (T=NON, + Code=2.05, + MID=0x60b1) + Token: + 0x86 + Observe: + 3 + Payload: + "22.3 + C" + Source: + ADDR_B:PORT_GRP + 2.05 + Destination: + ADDR_CLIENT:PORT_CLIENT + Header: + 2.05 + (T=NON, + Code=2.05, + MID=0x01a0) + Token: + 0x86 + Observe: + 13 + Payload: + "20.9 + C" + Source: + ADDR_C:PORT_C + 2.05 + Destination: + ADDR_CLIENT:PORT_CLIENT + Header: + 2.05 + (T=NON, + Code=2.05, + MID=0x952a) + Token: + 0x86 + Observe: + 23 + Payload: + "21.0 + C" + // + The + temperature + changes + ... + Source: + ADDR_A:PORT_GRP + 2.05 + Destination: + ADDR_CLIENT:PORT_CLIENT + Header: + 2.05 + (T=NON, + Code=2.05, + MID=0x60b2) + Token: + 0x86 + Observe: + 7 + Payload: + "32.3 + C" + Source: + ADDR_B:PORT_GRP + 2.05 + Destination: + ADDR_CLIENT:PORT_CLIENT + Header: + 2.05 + (T=NON, + Code=2.05, + MID=0x01a1) + Token: + 0x86 + Observe: + 18 + Payload: + "30.9 + C" + Source: + ADDR_C:PORT_C + 2.05 + Destination: + ADDR_CLIENT:PORT_CLIENT + Header: + 2.05 + (T=NON, + Code=2.05, + MID=0x952b) + Token: + 0x86 + Observe: + 29 + Payload: + "31.0 + C" + + +
Figure 17: Example of Non-confirmable Observe group request, followed by Non-confirmable Responses as Observe notifications @@ -3690,145 +3875,370 @@

In Figure 18, the client sends a Non-confirmable GET request to the CoAP group, targeting the resource "log" in the application group "gp1", and requesting a blockwise transfer. All servers reply with a 2.05 (Content) response including the first block. As source port number of its response, each server uses its own port number. After obtaining the first block, the client requests the following blocks separately from each server, by means of unicast exchanges.

-
-
-Client              A  B  C
-   |                |  |  |
-   |  GET           |  |  |
-   +-------+------->|  |  | Source: ADDR_CLIENT:PORT_CLIENT
-   |        \       |  |  | Destination: ADDR_GRP:PORT_GRP
-   |         `.------->|  | Header: GET (T=NON, Code=0.01, MID=0x7d41)
-   |           `.   |  |  | Token: 0x86
-   |             `------->| Uri-Path: "gp"
-   |                |  |  | Uri-Path: "gp1"
-   |                |  |  | Uri-Path: "log"
-   |                |  |  | Block2: 0/0/64
-   |                |  |  |
-   |<---------------+  |  | Source: ADDR_A:PORT_A
-   |      2.05      |  |  | Destination: ADDR_CLIENT:PORT_CLIENT
-   |                |  |  | Header: 2.05 (T=NON, Code=2.05, MID=0x60b1)
-   |                |  |  | Token: 0x86
-   |                |  |  | Block2: 0/1/64
-   |                |  |  | Payload: 0x0a00 ...
-   |                |  |  |
-   |<------------------+  | Source: ADDR_B:PORT_B
-   |      2.05      |  |  | Destination: ADDR_CLIENT:PORT_CLIENT
-   |                |  |  | Header: 2.05 (T=NON, Code=2.05, MID=0x01a0)
-   |                |  |  | Token: 0x86
-   |                |  |  | Block2: 0/1/64
-   |                |  |  | Payload: 0x0b00 ...
-   |                |  |  |
-   |<---------------------+ Source: ADDR_C:PORT_C
-   |      2.05      |  |  | Destination: ADDR_CLIENT:PORT_CLIENT
-   |                |  |  | Header: 2.05 (T=NON, Code=4.04, MID=0x952a)
-   |                |  |  | Token: 0x86
-   |                |  |  | Block2: 0/1/64
-   |                |  |  | Payload: 0x0c00 ...
-   |                |  |  |
-   |      GET       |  |  |
-   +--------------->|  |  | Source: ADDR_CLIENT:PORT_CLIENT
-   |                |  |  | Destination: ADDR_A:PORT_A
-   |                |  |  | Header: GET (T=CON, Code=0.01, MID=0x7d42)
-   |                |  |  | Token: 0xa6
-   |                |  |  | Uri-Path: "gp"
-   |                |  |  | Uri-Path: "gp1"
-   |                |  |  | Uri-Path: "log"
-   |                |  |  | Block2: 1/0/64
-   |                |  |  |
-   |<---------------+  |  | Source: ADDR_A:PORT_A
-   |      2.05      |  |  | Destination: ADDR_CLIENT:PORT_CLIENT
-   |                |  |  | Header: 2.05 (T=ACK, Code=2.05, MID=0x7d42)
-   |                |  |  | Token: 0xa6
-   |                |  |  | Block2: 1/1/64
-   |                |  |  | Payload: 0x0a01 ...
-   |                |  |  |
-   |      GET       |  |  |
-   +--------------->|  |  | Source: ADDR_CLIENT:PORT_CLIENT
-   |                |  |  | Destination: ADDR_A:PORT_A
-   |                |  |  | Header: GET (T=CON, Code=0.01, MID=0x7d43)
-   |                |  |  | Token: 0xa7
-   |                |  |  | Uri-Path: "gp"
-   |                |  |  | Uri-Path: "gp1"
-   |                |  |  | Uri-Path: "log"
-   |                |  |  | Block2: 2/0/64
-   |                |  |  |
-   |<---------------+  |  | Source: ADDR_A:PORT_A
-   |      2.05      |  |  | Destination: ADDR_CLIENT:PORT_CLIENT
-   |                |  |  | Header: 2.05 (T=ACK, Code=2.05, MID=0x7d43)
-   |                |  |  | Token: 0xa7
-   |                |  |  | Block2: 2/0/64
-   |                |  |  | Payload: 0x0a02 ...
-   |                |  |  |
-   |      GET       |  |  |
-   +------------------>|  | Source: ADDR_CLIENT:PORT_CLIENT
-   |                |  |  | Destination: ADDR_B:PORT_B
-   |                |  |  | Header: GET (T=CON, Code=0.01, MID=0x7d44)
-   |                |  |  | Token: 0xb6
-   |                |  |  | Uri-Path: "gp"
-   |                |  |  | Uri-Path: "gp1"
-   |                |  |  | Uri-Path: "log"
-   |                |  |  | Block2: 1/0/64
-   |                |  |  |
-   |<------------------+  | Source: ADDR_B:PORT_B
-   |      2.05      |  |  | Destination: ADDR_CLIENT:PORT_CLIENT
-   |                |  |  | Header: 2.05 (T=ACK, Code=2.05, MID=0x7d44)
-   |                |  |  | Token: 0xb6
-   |                |  |  | Block2: 1/1/64
-   |                |  |  | Payload: 0x0b01 ...
-   |                |  |  |
-   |      GET       |  |  |
-   +------------------>|  | Source: ADDR_CLIENT:PORT_CLIENT
-   |                |  |  | Destination: ADDR_C:PORT_B
-   |                |  |  | Header: GET (T=CON, Code=0.01, MID=0x7d45)
-   |                |  |  | Token: 0xb7
-   |                |  |  | Uri-Path: "gp"
-   |                |  |  | Uri-Path: "gp1"
-   |                |  |  | Uri-Path: "log"
-   |                |  |  | Block2: 2/0/64
-   |                |  |  |
-   |<------------------+  | Source: ADDR_B:PORT_B
-   |      2.05      |  |  | Destination: ADDR_CLIENT:PORT_CLIENT
-   |                |  |  | Header: 2.05 (T=ACK, Code=2.05, MID=0x7d45)
-   |                |  |  | Token: 0xb7
-   |                |  |  | Block2: 2/0/64
-   |                |  |  | Payload: 0x0b02 ...
-   |                |  |  |
-   |      GET       |  |  |
-   +--------------------->| Source: ADDR_CLIENT:PORT_CLIENT
-   |                |  |  | Destination: ADDR_C:PORT_C
-   |                |  |  | Header: GET (T=CON, Code=0.01, MID=0x7d46)
-   |                |  |  | Token: 0xc6
-   |                |  |  | Uri-Path: "gp"
-   |                |  |  | Uri-Path: "gp1"
-   |                |  |  | Uri-Path: "log"
-   |                |  |  | Block2: 1/0/64
-   |                |  |  |
-   |<---------------------+ Source: ADDR_C:PORT_C
-   |      2.05      |  |  | Destination: ADDR_CLIENT:PORT_CLIENT
-   |                |  |  | Header: 2.05 (T=ACK, Code=2.05, MID=0x7d46)
-   |                |  |  | Token: 0xc6
-   |                |  |  | Block2: 1/1/64
-   |                |  |  | Payload: 0x0c01 ...
-   |                |  |  |
-   |      GET       |  |  |
-   +--------------------->| Source: ADDR_CLIENT:PORT_CLIENT
-   |                |  |  | Destination: ADDR_C:PORT_C
-   |                |  |  | Header: GET (T=CON, Code=0.01, MID=0x7d47)
-   |                |  |  | Token: 0xc7
-   |                |  |  | Uri-Path: "gp"
-   |                |  |  | Uri-Path: "gp1"
-   |                |  |  | Uri-Path: "log"
-   |                |  |  | Block2: 2/0/64
-   |                |  |  |
-   |<---------------------+ Source: ADDR_C:PORT_C
-   |      2.05      |  |  | Destination: ADDR_CLIENT:PORT_CLIENT
-   |                |  |  | Header: 2.05 (T=ACK, Code=2.05, MID=0x7d47)
-   |                |  |  | Token: 0xc7
-   |                |  |  | Block2: 2/0/64
-   |                |  |  | Payload: 0x0c02 ...
-   |                |  |  |
-
-
+
+
+ + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + Client + A + B + C + GET + Source: + ADDR_CLIENT:PORT_CLIENT + Destination: + ADDR_GRP:PORT_GRP + Header: + GET + (T=NON, + Code=0.01, + MID=0x7d41) + `. + | + Token: + 0x86 + Uri-Path: + "gp" + Uri-Path: + "gp1" + Uri-Path: + "log" + Block2: + 0/0/64 + Source: + ADDR_A:PORT_A + 2.05 + Destination: + ADDR_CLIENT:PORT_CLIENT + Header: + 2.05 + (T=NON, + Code=2.05, + MID=0x60b1) + Token: + 0x86 + Block2: + 0/1/64 + Payload: + 0x0a00 + ... + Source: + ADDR_B:PORT_B + 2.05 + Destination: + ADDR_CLIENT:PORT_CLIENT + Header: + 2.05 + (T=NON, + Code=2.05, + MID=0x01a0) + Token: + 0x86 + Block2: + 0/1/64 + Payload: + 0x0b00 + ... + Source: + ADDR_C:PORT_C + 2.05 + Destination: + ADDR_CLIENT:PORT_CLIENT + Header: + 2.05 + (T=NON, + Code=4.04, + MID=0x952a) + Token: + 0x86 + Block2: + 0/1/64 + Payload: + 0x0c00 + ... + GET + Source: + ADDR_CLIENT:PORT_CLIENT + Destination: + ADDR_A:PORT_A + Header: + GET + (T=CON, + Code=0.01, + MID=0x7d42) + Token: + 0xa6 + Uri-Path: + "gp" + Uri-Path: + "gp1" + Uri-Path: + "log" + Block2: + 1/0/64 + Source: + ADDR_A:PORT_A + 2.05 + Destination: + ADDR_CLIENT:PORT_CLIENT + Header: + 2.05 + (T=ACK, + Code=2.05, + MID=0x7d42) + Token: + 0xa6 + Block2: + 1/1/64 + Payload: + 0x0a01 + ... + GET + Source: + ADDR_CLIENT:PORT_CLIENT + Destination: + ADDR_A:PORT_A + Header: + GET + (T=CON, + Code=0.01, + MID=0x7d43) + Token: + 0xa7 + Uri-Path: + "gp" + Uri-Path: + "gp1" + Uri-Path: + "log" + Block2: + 2/0/64 + Source: + ADDR_A:PORT_A + 2.05 + Destination: + ADDR_CLIENT:PORT_CLIENT + Header: + 2.05 + (T=ACK, + Code=2.05, + MID=0x7d43) + Token: + 0xa7 + Block2: + 2/0/64 + Payload: + 0x0a02 + ... + GET + Source: + ADDR_CLIENT:PORT_CLIENT + Destination: + ADDR_B:PORT_B + Header: + GET + (T=CON, + Code=0.01, + MID=0x7d44) + Token: + 0xb6 + Uri-Path: + "gp" + Uri-Path: + "gp1" + Uri-Path: + "log" + Block2: + 1/0/64 + Source: + ADDR_B:PORT_B + 2.05 + Destination: + ADDR_CLIENT:PORT_CLIENT + Header: + 2.05 + (T=ACK, + Code=2.05, + MID=0x7d44) + Token: + 0xb6 + Block2: + 1/1/64 + Payload: + 0x0b01 + ... + GET + Source: + ADDR_CLIENT:PORT_CLIENT + Destination: + ADDR_C:PORT_B + Header: + GET + (T=CON, + Code=0.01, + MID=0x7d45) + Token: + 0xb7 + Uri-Path: + "gp" + Uri-Path: + "gp1" + Uri-Path: + "log" + Block2: + 2/0/64 + Source: + ADDR_B:PORT_B + 2.05 + Destination: + ADDR_CLIENT:PORT_CLIENT + Header: + 2.05 + (T=ACK, + Code=2.05, + MID=0x7d45) + Token: + 0xb7 + Block2: + 2/0/64 + Payload: + 0x0b02 + ... + GET + Source: + ADDR_CLIENT:PORT_CLIENT + Destination: + ADDR_C:PORT_C + Header: + GET + (T=CON, + Code=0.01, + MID=0x7d46) + Token: + 0xc6 + Uri-Path: + "gp" + Uri-Path: + "gp1" + Uri-Path: + "log" + Block2: + 1/0/64 + Source: + ADDR_C:PORT_C + 2.05 + Destination: + ADDR_CLIENT:PORT_CLIENT + Header: + 2.05 + (T=ACK, + Code=2.05, + MID=0x7d46) + Token: + 0xc6 + Block2: + 1/1/64 + Payload: + 0x0c01 + ... + GET + Source: + ADDR_CLIENT:PORT_CLIENT + Destination: + ADDR_C:PORT_C + Header: + GET + (T=CON, + Code=0.01, + MID=0x7d47) + Token: + 0xc7 + Uri-Path: + "gp" + Uri-Path: + "gp1" + Uri-Path: + "log" + Block2: + 2/0/64 + Source: + ADDR_C:PORT_C + 2.05 + Destination: + ADDR_CLIENT:PORT_CLIENT + Header: + 2.05 + (T=ACK, + Code=2.05, + MID=0x7d47) + Token: + 0xc7 + Block2: + 2/0/64 + Payload: + 0x0c02 + ... + + +
Figure 18: Example of Non-confirmable group request starting a blockwise transfer, followed by Non-confirmable Responses with the first block. The transfer continues over confirmable unicast exchanges diff --git a/john-comments/draft-ietf-core-groupcomm-bis.txt b/john-comments/draft-ietf-core-groupcomm-bis.txt index 9e63dff..2383857 100644 --- a/john-comments/draft-ietf-core-groupcomm-bis.txt +++ b/john-comments/draft-ietf-core-groupcomm-bis.txt @@ -7,8 +7,8 @@ Internet-Draft IoTconsultancy.nl Obsoletes: 7390 (if approved) C. Wang Updates: 7252, 7641 (if approved) InterDigital Intended status: Standards Track M. Tiloca -Expires: 10 April 2024 RISE AB - 8 October 2023 +Expires: 12 April 2024 RISE AB + 10 October 2023 Group Communication for the Constrained Application Protocol (CoAP) @@ -24,7 +24,8 @@ Abstract Environments (Group OSCORE) protocol. The target application area of this specification is any group communication use cases that involve resource-constrained devices or networks that support CoAP. This - document replaces RFC 7390, while it updates RFC 7252 and RFC 7641. + document replaces and obsoletes RFC 7390, while it updates RFC 7252 + and RFC 7641. Discussion Venues @@ -54,7 +55,7 @@ Status of This Memo time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as "work in progress." - This Internet-Draft will expire on 10 April 2024. + This Internet-Draft will expire on 12 April 2024. Copyright Notice @@ -547,16 +548,24 @@ Table of Contents 2.2.1.1. CoAP Groups - A CoAP group is identified and named by the authority component in - the group URI (see Section 2.1.1), which includes the host - subcomponent (possibly an IP multicast address literal) and an - optional UDP port number. + A CoAP group is always defined by the two properties of IP multicast + address and UDP port number (see Section 2.1.1). + + However, a CoAP group is for practical purposes identified and named + by the authority component in the group URI. This component includes + the host subcomponent and an optional UDP port number. The host + subcomponent directly defines the IP multicast address of the CoAP + group, in case the host consists of an IP literal. The host + subcomponent indirectly defines the IP multicast address of the CoAP + group, in case the host consists of a hostname: resolving the + hostname to an IP address in this case produces the IP multicast + address. It follows that the same CoAP group might have multiple names, which - are possible to simultaneously and interchangeably use. For example, - if the two hostnames group1.example and group1.alias.example both - resolve to the IP multicast address [ff15::1234], then the following - authority components are all names for the same CoAP group. + can be simultaneously and interchangeably used. For example, if the + two hostnames group1.com and group1.alias.com both resolve to the IP + multicast address [ff15::1234], then the following authority + components are all names for the same CoAP group. * group1.example:7700 @@ -2039,7 +2048,9 @@ Table of Contents rely on setting up and advertising a pseudo security group with name "NoSec" or any of its lowercase/uppercase combinations. - It is NOT RECOMMENDED to use CoAP group communication in NoSec mode. + A CoAP server in NoSec mode MUST NOT be accessible through the public + Internet. It is NOT RECOMMENDED to use CoAP group communication in + NoSec mode. The possible, exceptional use of the NoSec mode ought to be limited to: applications that are proven to be neither sensitive nor @@ -2265,7 +2276,8 @@ Table of Contents 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. + 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 non-sensitive and non-