draft-tiloca-core-observe-multicast-notifications-04.txt   draft-tiloca-core-observe-multicast-notifications-05.txt 
CoRE Working Group M. Tiloca CoRE Working Group M. Tiloca
Internet-Draft R. Hoeglund Internet-Draft R. Hoeglund
Updates: 7252, 7641 (if approved) RISE AB Updates: 7252, 7641 (if approved) RISE AB
Intended status: Standards Track C. Amsuess Intended status: Standards Track C. Amsuess
Expires: May 6, 2021 Expires: August 26, 2021
F. Palombini F. Palombini
Ericsson AB Ericsson AB
November 02, 2020 February 22, 2021
Observe Notifications as CoAP Multicast Responses Observe Notifications as CoAP Multicast Responses
draft-tiloca-core-observe-multicast-notifications-04 draft-tiloca-core-observe-multicast-notifications-05
Abstract Abstract
The Constrained Application Protocol (CoAP) allows clients to The Constrained Application Protocol (CoAP) allows clients to
"observe" resources at a server, and receive notifications as unicast "observe" resources at a server, and receive notifications as unicast
responses upon changes of the resource state. In some use cases, responses upon changes of the resource state. In some use cases,
such as based on publish-subscribe, it would be convenient for the such as based on publish-subscribe, it would be convenient for the
server to send a single notification to all the clients observing a server to send a single notification addressed to all the clients
same target resource. This document defines how a CoAP server sends observing a same target resource. This document updates RFC7252 and
observe notifications as response messages over multicast, by RFC7641, and defines how a server sends observe notifications as
synchronizing all the observers of a same resource on a same shared response messages over multicast, synchronizing all the observers of
Token value. Besides, this document defines how Group OSCORE can be a same resource on a same shared Token value. Besides, this document
used to protect multicast notifications end-to-end from the CoAP defines how Group OSCORE can be used to protect multicast
server to the multiple observer clients. notifications end-to-end between the server and the observer clients.
Status of This Memo Status of This Memo
This Internet-Draft is submitted in full conformance with the This Internet-Draft is submitted in full conformance with the
provisions of BCP 78 and BCP 79. provisions of BCP 78 and BCP 79.
Internet-Drafts are working documents of the Internet Engineering Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF). Note that other groups may also distribute Task Force (IETF). Note that other groups may also distribute
working documents as Internet-Drafts. The list of current Internet- working documents as Internet-Drafts. The list of current Internet-
Drafts is at https://datatracker.ietf.org/drafts/current/. Drafts is at https://datatracker.ietf.org/drafts/current/.
Internet-Drafts are draft documents valid for a maximum of six months Internet-Drafts are draft documents valid for a maximum of six months
and may be updated, replaced, or obsoleted by other documents at any and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress." material or to cite them other than as "work in progress."
This Internet-Draft will expire on May 6, 2021. This Internet-Draft will expire on August 26, 2021.
Copyright Notice Copyright Notice
Copyright (c) 2020 IETF Trust and the persons identified as the Copyright (c) 2021 IETF Trust and the persons identified as the
document authors. All rights reserved. document authors. All rights reserved.
This document is subject to BCP 78 and the IETF Trust's Legal This document is subject to BCP 78 and the IETF Trust's Legal
Provisions Relating to IETF Documents Provisions Relating to IETF Documents
(https://trustee.ietf.org/license-info) in effect on the date of (https://trustee.ietf.org/license-info) in effect on the date of
publication of this document. Please review these documents publication of this document. Please review these documents
carefully, as they describe your rights and restrictions with respect carefully, as they describe your rights and restrictions with respect
to this document. Code Components extracted from this document must to this document. Code Components extracted from this document must
include Simplified BSD License text as described in Section 4.e of include Simplified BSD License text as described in Section 4.e of
the Trust Legal Provisions and are provided without warranty as the Trust Legal Provisions and are provided without warranty as
described in the Simplified BSD License. described in the Simplified BSD License.
Table of Contents Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3
1.1. Terminology . . . . . . . . . . . . . . . . . . . . . . . 5 1.1. Terminology . . . . . . . . . . . . . . . . . . . . . . . 5
2. Server-Side Requirements . . . . . . . . . . . . . . . . . . 5 2. Server-Side Requirements . . . . . . . . . . . . . . . . . . 5
2.1. Request . . . . . . . . . . . . . . . . . . . . . . . . . 6 2.1. Request . . . . . . . . . . . . . . . . . . . . . . . . . 6
2.2. Informative Response . . . . . . . . . . . . . . . . . . 7 2.2. Informative Response . . . . . . . . . . . . . . . . . . 7
2.2.1. Encoding of Transport-Independent Message Information 8 2.2.1. Encoding of Transport-Specific Message Information . 8
2.2.2. Encoding of Transport-Specific Message Information . 9 2.2.2. Encoding of Transport-Independent Message Information 11
2.3. Notifications . . . . . . . . . . . . . . . . . . . . . . 10 2.3. Notifications . . . . . . . . . . . . . . . . . . . . . . 12
2.4. Congestion Control . . . . . . . . . . . . . . . . . . . 11 2.4. Congestion Control . . . . . . . . . . . . . . . . . . . 13
2.5. Cancellation . . . . . . . . . . . . . . . . . . . . . . 12 2.5. Cancellation . . . . . . . . . . . . . . . . . . . . . . 13
3. Client-Side Requirements . . . . . . . . . . . . . . . . . . 13 3. Client-Side Requirements . . . . . . . . . . . . . . . . . . 14
3.1. Request . . . . . . . . . . . . . . . . . . . . . . . . . 13 3.1. Request . . . . . . . . . . . . . . . . . . . . . . . . . 14
3.2. Informative Response . . . . . . . . . . . . . . . . . . 13 3.2. Informative Response . . . . . . . . . . . . . . . . . . 14
3.3. Notifications . . . . . . . . . . . . . . . . . . . . . . 14 3.3. Notifications . . . . . . . . . . . . . . . . . . . . . . 16
3.4. Cancellation . . . . . . . . . . . . . . . . . . . . . . 14 3.4. Cancellation . . . . . . . . . . . . . . . . . . . . . . 16
4. Example . . . . . . . . . . . . . . . . . . . . . . . . . . . 15 4. Web Linking . . . . . . . . . . . . . . . . . . . . . . . . . 16
5. Rough Counting of Clients in the Group Observation . . . . . 17 5. Example . . . . . . . . . . . . . . . . . . . . . . . . . . . 17
5.1. Processing on the Client Side . . . . . . . . . . . . . . 17 6. Rough Counting of Clients in the Group Observation . . . . . 19
5.2. Processing on the Server Side . . . . . . . . . . . . . . 18 6.1. Processing on the Client Side . . . . . . . . . . . . . . 20
5.2.1. Request for Feedback . . . . . . . . . . . . . . . . 19 6.2. Processing on the Server Side . . . . . . . . . . . . . . 21
5.2.2. Collection of Feedback . . . . . . . . . . . . . . . 19 6.2.1. Request for Feedback . . . . . . . . . . . . . . . . 21
5.2.3. Processing of Feedback . . . . . . . . . . . . . . . 20 6.2.2. Collection of Feedback . . . . . . . . . . . . . . . 22
6. Protection of Multicast Notifications with Group OSCORE . . . 21 6.2.3. Processing of Feedback . . . . . . . . . . . . . . . 22
6.1. Signaling the OSCORE Group in the Informative Response . 22 7. Protection of Multicast Notifications with Group OSCORE . . . 24
6.2. Server-Side Requirements . . . . . . . . . . . . . . . . 24 7.1. Signaling the OSCORE Group in the Informative Response . 24
6.2.1. Registration . . . . . . . . . . . . . . . . . . . . 24 7.2. Server-Side Requirements . . . . . . . . . . . . . . . . 26
6.2.2. Informative Response . . . . . . . . . . . . . . . . 24 7.2.1. Registration . . . . . . . . . . . . . . . . . . . . 27
6.2.3. Notifications . . . . . . . . . . . . . . . . . . . . 25 7.2.2. Informative Response . . . . . . . . . . . . . . . . 27
6.2.4. Cancellation . . . . . . . . . . . . . . . . . . . . 25 7.2.3. Notifications . . . . . . . . . . . . . . . . . . . . 27
6.3. Client-Side Requirements . . . . . . . . . . . . . . . . 26 7.2.4. Cancellation . . . . . . . . . . . . . . . . . . . . 28
6.3.1. Informative Response . . . . . . . . . . . . . . . . 26 7.3. Client-Side Requirements . . . . . . . . . . . . . . . . 28
6.3.2. Notifications . . . . . . . . . . . . . . . . . . . . 27 7.3.1. Informative Response . . . . . . . . . . . . . . . . 29
7. Example with Group OSCORE . . . . . . . . . . . . . . . . . . 27 7.3.2. Notifications . . . . . . . . . . . . . . . . . . . . 30
8. Intermediaries . . . . . . . . . . . . . . . . . . . . . . . 31 8. Example with Group OSCORE . . . . . . . . . . . . . . . . . . 30
9. Intermediaries Together with End-to-End Security . . . . . . 33 9. Intermediaries . . . . . . . . . . . . . . . . . . . . . . . 34
9.1. The Listen-To-Multicast-Responses Option . . . . . . . . 34 10. Intermediaries Together with End-to-End Security . . . . . . 36
9.2. Message Processing . . . . . . . . . . . . . . . . . . . 35 10.1. The Listen-To-Multicast-Responses Option . . . . . . . . 36
10. Informative Response Parameters . . . . . . . . . . . . . . . 36 10.2. Message Processing . . . . . . . . . . . . . . . . . . . 37
11. Transport Protocol Identifiers . . . . . . . . . . . . . . . 37 11. Informative Response Parameters . . . . . . . . . . . . . . . 39
12. Security Considerations . . . . . . . . . . . . . . . . . . . 38 12. Transport Protocol Information . . . . . . . . . . . . . . . 40
12.1. Listen-To-Multicast-Responses Option . . . . . . . . . . 38 13. Security Considerations . . . . . . . . . . . . . . . . . . . 41
13. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 39 13.1. Listen-To-Multicast-Responses Option . . . . . . . . . . 41
13.1. Media Type Registrations . . . . . . . . . . . . . . . . 39 14. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 42
13.2. CoAP Content-Formats Registry . . . . . . . . . . . . . 40 14.1. Media Type Registrations . . . . . . . . . . . . . . . . 42
13.3. Informative Response Parameters Registry . . . . . . . . 40 14.2. CoAP Content-Formats Registry . . . . . . . . . . . . . 43
13.4. Transport Protocol Identifiers Registry . . . . . . . . 41 14.3. Informative Response Parameters Registry . . . . . . . . 43
13.5. CoAP Option Numbers Registry . . . . . . . . . . . . . . 42 14.4. CoAP Transport Information Registry . . . . . . . . . . 44
13.6. Expert Review Instructions . . . . . . . . . . . . . . . 42 14.5. CoAP Option Numbers Registry . . . . . . . . . . . . . . 45
14. References . . . . . . . . . . . . . . . . . . . . . . . . . 43 14.6. Expert Review Instructions . . . . . . . . . . . . . . . 45
14.1. Normative References . . . . . . . . . . . . . . . . . . 43 15. References . . . . . . . . . . . . . . . . . . . . . . . . . 46
14.2. Informative References . . . . . . . . . . . . . . . . . 45 15.1. Normative References . . . . . . . . . . . . . . . . . . 46
14.3. URIs . . . . . . . . . . . . . . . . . . . . . . . . . . 46 15.2. Informative References . . . . . . . . . . . . . . . . . 48
Appendix A. Different Sources for Group Observation Data . . . . 46 15.3. URIs . . . . . . . . . . . . . . . . . . . . . . . . . . 50
A.1. Topic Discovery in Publish-Subscribe Settings . . . . . . 46 Appendix A. Different Sources for Group Observation Data . . . . 50
A.2. Introspection at the Multicast Notification Sender . . . 47 A.1. Topic Discovery in Publish-Subscribe Settings . . . . . . 50
Appendix B. Pseudo-Code for Rough Counting of Clients . . . . . 48 A.2. Introspection at the Multicast Notification Sender . . . 51
B.1. Client Side . . . . . . . . . . . . . . . . . . . . . . . 48 Appendix B. Pseudo-Code for Rough Counting of Clients . . . . . 52
B.2. Client Side - Optimized Version . . . . . . . . . . . . . 49 B.1. Client Side . . . . . . . . . . . . . . . . . . . . . . . 52
B.3. Server Side . . . . . . . . . . . . . . . . . . . . . . . 50 B.2. Client Side - Optimized Version . . . . . . . . . . . . . 53
Appendix C. Example with a Proxy . . . . . . . . . . . . . . . . 52 B.3. Server Side . . . . . . . . . . . . . . . . . . . . . . . 53
Appendix D. Example with a Proxy and Group OSCORE . . . . . . . 55 Appendix C. OSCORE Group Self-Managed by the Server . . . . . . 55
Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . . . 61 Appendix D. Phantom Request as Deterministic Request . . . . . . 57
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 61 Appendix E. Example with a Proxy . . . . . . . . . . . . . . . . 58
Appendix F. Example with a Proxy and Group OSCORE . . . . . . . 60
Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . . . 66
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 67
1. Introduction 1. Introduction
The Constrained Application Protocol (CoAP) [RFC7252] has been The Constrained Application Protocol (CoAP) [RFC7252] has been
extended with a number of mechanisms, including resource Observation extended with a number of mechanisms, including resource Observation
[RFC7641]. This enables CoAP clients to register at a CoAP server as [RFC7641]. This enables CoAP clients to register at a CoAP server as
"observers" of a resource, and hence being automatically notified "observers" of a resource, and hence being automatically notified
with an unsolicited response upon changes of the resource state. with an unsolicited response upon changes of the resource state.
CoAP supports group communication over IP multicast CoAP supports group communication over IP multicast
skipping to change at page 4, line 33 skipping to change at page 4, line 35
through the respective Group Manager through the respective Group Manager
[I-D.tiloca-core-oscore-discovery]. [I-D.tiloca-core-oscore-discovery].
More in general, multicast notifications would be beneficial whenever More in general, multicast notifications would be beneficial whenever
several CoAP clients observe a same target resource at a CoAP server, several CoAP clients observe a same target resource at a CoAP server,
and can be all notified at once by means of a single response and can be all notified at once by means of a single response
message. However, CoAP does not currently define response messages message. However, CoAP does not currently define response messages
over IP multicast. This specification fills this gap and provides over IP multicast. This specification fills this gap and provides
the following twofold contribution. the following twofold contribution.
First, it defines a method to deliver Observe notifications as CoAP First, it updates [RFC7252] and [RFC7641], by defining a method to
responses over IP multicast. In the proposed method, the group of deliver Observe notifications as CoAP responses addressed to multiple
potential observers entrusts the server to manage the Token space for clients, e.g. over IP multicast. In the proposed method, the group
multicast notifications. By doing so, the server provides all the of potential observers entrusts the server to manage the Token space
observers of a target resource with the same Token value to bind to for multicast notifications. By doing so, the server provides all
their own observation. That Token value is then used in every the observers of a target resource with the same Token value to bind
to their own observation. That Token value is then used in every
multicast notification for the target resource. This is achieved by multicast notification for the target resource. This is achieved by
means of an informative unicast response sent by the server to each means of an informative unicast response sent by the server to each
observer client. observer client.
Second, this specification defines how to use Group OSCORE Second, this specification defines how to use Group OSCORE
[I-D.ietf-core-oscore-groupcomm] to protect multicast notifications [I-D.ietf-core-oscore-groupcomm] to protect multicast notifications
end-to-end between the server and the observer clients. This is also end-to-end between the server and the observer clients. This is also
achieved by means of the informative unicast response mentioned achieved by means of the informative unicast response mentioned
above, which additionally includes parameter values used by the above, which additionally includes parameter values used by the
server to protect every multicast notification for the target server to protect every multicast notification for the target
skipping to change at page 5, line 15 skipping to change at page 5, line 18
1.1. Terminology 1.1. Terminology
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and
"OPTIONAL" in this document are to be interpreted as described in BCP "OPTIONAL" in this document are to be interpreted as described in BCP
14 [RFC2119] [RFC8174] when, and only when, they appear in all 14 [RFC2119] [RFC8174] when, and only when, they appear in all
capitals, as shown here. capitals, as shown here.
Readers are expected to be familiar with terms and concepts described Readers are expected to be familiar with terms and concepts described
in CoAP [RFC7252], group communication for CoAP in CoAP [RFC7252], group communication for CoAP
[I-D.ietf-core-groupcomm-bis], Observe [RFC7641], CBOR [I-D.ietf-core-groupcomm-bis], Observe [RFC7641], CBOR [RFC8949],
[I-D.ietf-cbor-7049bis], OSCORE [RFC8613], and Group OSCORE OSCORE [RFC8613], and Group OSCORE [I-D.ietf-core-oscore-groupcomm].
[I-D.ietf-core-oscore-groupcomm].
This specification additionally defines the following terminology. This specification additionally defines the following terminology.
o Traditional observation. A resource observation associated to a o Traditional observation. A resource observation associated to a
single observer client, as defined in [RFC7641]. single observer client, as defined in [RFC7641].
o Group observation. A resource observation associated to a group o Group observation. A resource observation associated to a group
of clients. The server sends notifications for the group-observed of clients. The server sends notifications for the group-observed
resource over IP multicast to all the observer clients. resource over IP multicast to all the observer clients.
skipping to change at page 6, line 13 skipping to change at page 6, line 13
those clients part of a group observation on that resource. those clients part of a group observation on that resource.
The server maintains an observer counter for each group observation The server maintains an observer counter for each group observation
to a target resource, as a rough estimation of the observers actively to a target resource, as a rough estimation of the observers actively
taking part in the group observation. taking part in the group observation.
The server initializes the counter to 0 when starting the group The server initializes the counter to 0 when starting the group
observation, and increments it after a new client starts taking part observation, and increments it after a new client starts taking part
in that group observation. Also, the server should keep the counter in that group observation. Also, the server should keep the counter
up-to-date over time, for instance by using the method described in up-to-date over time, for instance by using the method described in
Section 5. Section 6.
This document does not describe a way for the client to influence the
server's decision to start group observations. That is done on
purpose: the specified mechanism is expected to be used in situations
where sending individual notifications is not feasible, or not
preferred beyond a certain number of clients observing a target
resource. If applications arise where negotiation does make sense,
they are welcome to specify additional means to opt in to multicast
notifications.
2.1. Request 2.1. Request
Assuming it is reachable at the address SRV_ADDR and port number Assuming it is reachable at the address SRV_ADDR and port number
SRV_PORT, the server starts a group observation on one of its SRV_PORT, the server starts a group observation on one of its
resources as defined below. The server intends to send multicast resources as defined below. The server intends to send multicast
notifications for the target resource to the multicast IP address notifications for the target resource to the multicast IP address
GRP_ADDR and port number GRP_PORT. GRP_ADDR and port number GRP_PORT.
1. The server builds a phantom observation request, i.e. a GET 1. The server builds a phantom observation request, i.e. a GET
skipping to change at page 7, line 36 skipping to change at page 7, line 46
for which it increases the corresponding observer counter for which it increases the corresponding observer counter
accordingly. accordingly.
The server sends to each of such clients an informative response The server sends to each of such clients an informative response
message, encoded as a unicast response with response code 5.03 message, encoded as a unicast response with response code 5.03
(Service Unavailable). As per [RFC7641], such a response does not (Service Unavailable). As per [RFC7641], such a response does not
include an Observe option. The response MUST be Confirmable and MUST include an Observe option. The response MUST be Confirmable and MUST
NOT encode link-local addresses. NOT encode link-local addresses.
The Content-Format of the informative response is set to application/ The Content-Format of the informative response is set to application/
informative-response+cbor, as defined in Section 13.2. The payload informative-response+cbor, defined in Section 14.2. The payload of
of the informative response is a CBOR map which MUST include all the the informative response is a CBOR map including the following
following parameters, whose CBOR labels are defined in Section 10. parameters, whose CBOR labels are defined in Section 11.
o 'tp_info', with value a CBOR array. This includes the transport-
specific information required to correctly receive multicast
notifications bound to the phantom observation request. The CBOR
array is formatted as defined in Section 2.2.1. This parameter
MUST be included.
o 'ph_req', with value the byte serialization of the transport- o 'ph_req', with value the byte serialization of the transport-
independent information of the phantom observation request (see independent information of the phantom observation request (see
Section 2.1), encoded as a CBOR byte string. The value of the Section 2.1), encoded as a CBOR byte string. The value of the
CBOR byte string is formatted as defined in Section 2.2.1. CBOR byte string is formatted as defined in Section 2.2.2. This
parameter MUST be included.
o 'last_notif', with value the byte serialization of the transport- o 'last_notif', with value the byte serialization of the transport-
independent information of the latest multicast notification for independent information of the latest multicast notification for
the target resource, encoded as a CBOR byte string. The value of the target resource, encoded as a CBOR byte string. The value of
the CBOR byte string is formatted as defined in Section 2.2.1. the CBOR byte string is formatted as defined in Section 2.2.2.
This parameter MAY be included.
o 'tp_info', with value a CBOR array. This includes the transport-
specific information required to correctly receive multicast
notifications bound to the phantom observation request. The CBOR
array is formatted as defined in Section 2.2.2.
The CDDL notation [RFC8610] provided below describes the payload of The CDDL notation [RFC8610] provided below describes the payload of
the informative response. the informative response.
informative_response_payload = { informative_response_payload = {
1 => bstr, ; phantom request (transport-independent information) 1 => array, ; 'tp_info', i.e. transport-specific information
2 => bstr, ; latest notification (transport-independent information) 2 => bstr, ; 'ph_req' (transport-independent information)
3 => array ; transport-specific information ? 3 => bstr ; 'last_notif' (transport-independent information)
} }
Figure 1: Format of the informative response payload
Upon receiving a registration request to observe the target resource, Upon receiving a registration request to observe the target resource,
the server does not create a corresponding individual observation for the server does not create a corresponding individual observation for
the requesting client. Instead, the server considers that client as the requesting client. Instead, the server considers that client as
now taking part in the group observation of the target resource, of now taking part in the group observation of the target resource, of
which it increments the observer counter by 1. Then, the server which it increments the observer counter by 1. Then, the server
replies to the client with the same informative response message replies to the client with the same informative response message
defined above, which MUST be Confirmable. defined above, which MUST be Confirmable.
Note that this also applies when, with no ongoing traditional Note that this also applies when, with no ongoing traditional
observations on the target resource, the server receives a observations on the target resource, the server receives a
registration request from a first client and decides to start a group registration request from a first client and decides to start a group
observation on the target resource. observation on the target resource.
2.2.1. Encoding of Transport-Independent Message Information 2.2.1. Encoding of Transport-Specific Message Information
For both the parameters 'ph_req' and 'last_notif' in the informative
response, the value of the byte string is the concatenation of the
following components, in the order specified below.
When defining the value of each component, "CoAP message" refers to The CBOR array specified in the 'tp_info' parameter is formatted
the phantom observation request for the 'ph_req' parameter, and to according to the following CDDL notation.
the corresponding latest multicast notification for the 'last_notif'
parameter.
o A single byte, with value the content of the Code field in the tp_info = [
CoAP message. srv_addr ; Addressing information of the server
? req_info ; Request data extension
]
o The byte serialization of the complete sequence of CoAP options in srv_addr = (
the CoAP message. tp_id : int, ; Identifier of the used transport protocol
+ elements ; Number, format and encoding
; based on the value of 'tp_id'
)
o If the CoAP message includes a non-zero length payload, the one- req_info = (
byte Payload Marker (0xff) followed by the payload. + elements ; Number, format and encoding based on
; the value of 'tp_id' in 'srv_addr'
)
2.2.2. Encoding of Transport-Specific Message Information Figure 2: General format of 'tp_info'
The CBOR array specified in the 'tp_info' parameter includes at least The 'srv_addr' element of 'tp_info' specifies the addressing
one element and is formatted as follows. information of the server, and includes at least one element 'tp_id'
which is formatted as follows.
o 'tp_id' : this element is a CBOR integer, which specifies the o 'tp_id' : this element is a CBOR integer, which specifies the
transport protocol used to transport the CoAP multicast transport protocol used to transport the CoAP response from the
notifications from the server. This element takes value from the server, i.e. a multicast notification in this specification.
"Transport Protocol Identifiers" sub-registry defined in
Section 13.4 of this specification. This element MUST be present. This element takes value from the "Value" column of the "CoAP
The value of this element determines how many elements are Transport Information" registry defined in Section 14.4 of this
required to follow in the CBOR array, as well as what information specification. This element MUST be present. The value of this
they convey, their encoding and their semantics. element determines:
* How many elements are required to follow in 'srv_addr', as well
as what information they convey, their encoding and their
semantics.
* How many elements are required in the 'req_info' element of the
'tp_info' array, as well as what information they convey, their
encoding and their semantics.
This specification registers the integer value 1 ("UDP") to be This specification registers the integer value 1 ("UDP") to be
used as value for the 'tp_id' element, when CoAP multicast used as value for the 'tp_id' element, when CoAP responses are
notifications are transported over UDP as per [RFC7252] and transported over UDP. In such a case, the full encoding of the
[I-D.ietf-core-groupcomm-bis]. In such a case, the full encoding 'tp_info' CBOR array is as defined in Section 2.2.1.1.
of the 'tp_info' CBOR array is as defined in Section 2.2.2.1.
Future specifications that consider CoAP multicast notifications Future specifications that consider CoAP multicast notifications
transported over different transport protocols MUST: transported over different transport protocols MUST:
* Register an integer value to be used as value for the 'tp_id' * Register an entry with an integer value to be used for 'tp_id',
array element, in the "Transport Protocol Identifiers" sub- in the "CoAP Transport Information" registry defined in
registry defined in Section 13.4 of this specification. Section 14.4 of this specification.
* Accordingly, define the elements of the 'tp_info' CBOR array * Accordingly, define the elements of the 'tp_info' CBOR array,
following the 'tp_id' element, as to what information they i.e. the elements following 'tp_id' in 'srv_addr' as well as
convey, their encoding and their semantics. the elements in 'req_info', as to what information they convey,
their encoding and their semantics.
2.2.2.1. UDP Transport-Specific Information The 'req_info' element of 'tp_info' specifies transport-specific
information related to a pertinent request message, i.e. the phantom
observation request in this specification. The exact format of
'req_info' depends on the value of 'tp_id'.
Given a specific value of 'tp_id', the complete set of elements
composing 'srv_addr' and 'req_info' in the 'tp_info' CBOR array is
indicated by the two columns "Srv Addr" and "Req Info" of the "CoAP
Transport Information" registry defined in Section 14.4,
respectively.
2.2.1.1. UDP Transport-Specific Information
When CoAP multicast notifications are transported over UDP as per When CoAP multicast notifications are transported over UDP as per
[RFC7252] and [I-D.ietf-core-groupcomm-bis], the server specifies the [RFC7252] and [I-D.ietf-core-groupcomm-bis], the server specifies the
integer value 1 ("UDP") as value of the 'tp_id' element of the integer value 1 ("UDP") as value of 'tp_id' in the 'srv_addr' element
'tp_info' CBOR array in the error informative response. of the 'tp_info' CBOR array in the error informative response. Then,
the rest of the 'tp_info' CBOR array is defined as follows.
Then, following the 'tp_id' element, the rest of the 'tp_info' CBOR o 'srv_addr' includes two more elements following 'tp_id':
array is defined as follows.
o 'token': this element is a CBOR byte string, with value the Token * 'srv_host': this element is a CBOR byte string, with value the
value of the phantom observation request generated by the server destination IP address of the phantom observation request.
(see Section 2.1). Note that the same Token value is used for the This parameter is tagged and identified by the CBOR tag 260
multicast notifications bound to that phantom observation request "Network Address (IPv4 or IPv6 or MAC Address)". That is, the
(see Section 2.3). This element MUST be present. value of the CBOR byte string is the IP address SRV_ADDR of the
server hosting the target resource, from where the server will
send multicast notifications for the target resource. This
element MUST be present.
o 'srv_addr': this element is a CBOR byte string, with value the * 'srv_port': this element is a CBOR unsigned integer, with value
destination IP address of the phantom observation request. This the destination port number of the phantom observation request.
parameter is tagged and identified by the CBOR tag 260 "Network That is, the specified value is the port number SRV_PORT, from
Address (IPv4 or IPv6 or MAC Address)". That is, the value of the where the server will send multicast notifications for the
CBOR byte string is the IP address SRV_ADDR of the server hosting target resource. This element MUST be present.
the target resource, from where the server will send multicast
notifications for the target resource. This element MUST be
present.
o 'srv_port': this element is a CBOR unsigned integer, with value o 'req_info' includes the following elements:
the destination port number of the phantom observation request.
That is, the specified value is the port number SRV_PORT, from
where the server will send multicast notifications for the target
resource. This element MUST be present.
o 'cli_addr': this element is a CBOR byte string, with value the * 'token': this element is a CBOR byte string, with value the
source IP address of the phantom observation request. This Token value of the phantom observation request generated by the
parameter is tagged and identified by the CBOR tag 260 "Network server (see Section 2.1). Note that the same Token value is
Address (IPv4 or IPv6 or MAC Address)". That is, the value of the used for the multicast notifications bound to that phantom
CBOR byte string is the IP multicast address GRP_ADDR, where the observation request (see Section 2.3). This element MUST be
server will send multicast notifications for the target resource. present.
This element MUST be present.
o 'cli_port': this element is a CBOR unsigned integer, with value * 'cli_addr': this element is a CBOR byte string, with value the
the source port number of the phantom observation request. That source IP address of the phantom observation request. This
is, the specified value is the port number GRP_PORT, where the parameter is tagged and identified by the CBOR tag 260 "Network
server will send multicast notifications for the target resource. Address (IPv4 or IPv6 or MAC Address)". That is, the value of
This element is OPTIONAL. If not included, the default port the CBOR byte string is the IP multicast address GRP_ADDR,
number 5683 is assumed. where the server will send multicast notifications for the
target resource. This element MUST be present.
The CDDL notation [RFC8610] provided below describes the full * 'cli_port': this element is a CBOR unsigned integer, with value
'tp_info' CBOR array using the format above. the source port number of the phantom observation request.
That is, the specified value is the port number GRP_PORT, where
the server will send multicast notifications for the target
resource. This element is OPTIONAL. If not included, the
default port number 5683 is assumed.
The CDDL notation provided below describes the full 'tp_info' CBOR
array using the format above.
tp_info = [ tp_info = [
tp_id : 1, ; UDP as transport protocol tp_id : 1, ; UDP as transport protocol
token : bstr, ; Token of phantom request and multicast notifications srv_host : #6.260(bstr), ; Src. address of multicast notifications
srv_addr : #6.260(bstr), ; Src. address of multicast notifications srv_port : uint, ; Src. port of multicast notifications
srv_port : uint, ; Src. port of multicast notifications token : bstr, ; Token of the phantom request and
cli_addr : #6.260(bstr), ; Dst. address of multicast notifications ; associated multicast notifications
? cli_port : uint ; Dst. port of multicast notifications cli_addr : #6.260(bstr), ; Dst. address of multicast notifications
? cli_port : uint ; Dst. port of multicast notifications
] ]
Figure 3: Format of 'tp_info' with UDP as transport protocol
2.2.2. Encoding of Transport-Independent Message Information
For both the parameters 'ph_req' and 'last_notif' in the informative
response, the value of the byte string is the concatenation of the
following components, in the order specified below.
When defining the value of each component, "CoAP message" refers to
the phantom observation request for the 'ph_req' parameter, and to
the corresponding latest multicast notification for the 'last_notif'
parameter.
o A single byte, with value the content of the Code field in the
CoAP message.
o The byte serialization of the complete sequence of CoAP options in
the CoAP message.
o If the CoAP message includes a non-zero length payload, the one-
byte Payload Marker (0xff) followed by the payload.
2.3. Notifications 2.3. Notifications
Upon a change in the status of the target resource under group Upon a change in the status of the target resource under group
observation, the server sends a multicast notification, intended to observation, the server sends a multicast notification, intended to
all the clients taking part in the group observation of that all the clients taking part in the group observation of that
resource. In particular, each of such multicast notifications is resource. In particular, each of such multicast notifications is
formatted as follows. formatted as follows.
o It MUST be Non-confirmable. o It MUST be Non-confirmable.
o It MUST include an Observe option, as per [RFC7641]. o It MUST include an Observe option, as per [RFC7641].
o It MUST have the same Token value T of the phantom registration o It MUST have the same Token value T of the phantom registration
request that started the group observation. This Token value is request that started the group observation. This Token value is
specified in the 'token' element of the 'tp_info' parameter, in specified in the 'token' element of 'req_info' under the 'tp_info'
the informative response message sent to all the observer clients. parameter, in the informative response message sent to all the
observer clients.
That is, every multicast notification for a target resource is not That is, every multicast notification for a target resource is not
bound to the observation requests from the different clients, but bound to the observation requests from the different clients, but
rather to the phantom registration request associated to the whole rather to the phantom registration request associated to the whole
set of clients taking part in the group observation of that set of clients taking part in the group observation of that
resource. resource.
o It MUST be sent from the same IP address SRV_ADDR and port number o It MUST be sent from the same IP address SRV_ADDR and port number
SRV_PORT where: i) the original Observe registration requests are SRV_PORT where: i) the original Observe registration requests are
sent to by the clients; and ii) the corresponding informative sent to by the clients; and ii) the corresponding informative
responses are sent from by the server (see Section 2.2). These responses are sent from by the server (see Section 2.2). These
are indicated to the observer clients as value of the 'srv_addr' are indicated to the observer clients as value of the 'srv_host'
and 'srv_port' elements of the 'tp_info' parameter, in the and 'srv_port' elements of 'srv_addr' under the 'tp_info'
informative response message (see Section 2.2.2.1). That is, parameter, in the informative response message (see
redirection MUST NOT be used. Section 2.2.1.1). That is, redirection MUST NOT be used.
o It MUST be sent to the IP multicast address GRP_ADDR and port o It MUST be sent to the IP multicast address GRP_ADDR and port
number GRP_PORT. These are indicated to the observer clients as number GRP_PORT. These are indicated to the observer clients as
value of the 'cli_addr' and 'cli_port' elements of the 'tp_info' value of the 'cli_addr' and 'cli_port' elements of 'req_info'
parameter, in the informative response message (see under the 'tp_info' parameter, in the informative response message
Section 2.2.2.1). (see Section 2.2.1.1).
For each target resource with an active group observation, the server For each target resource with an active group observation, the server
MUST store the latest multicast notification. MUST store the latest multicast notification.
2.4. Congestion Control 2.4. Congestion Control
In order to not cause congestion, the server should conservatively In order to not cause congestion, the server should conservatively
control the sending of multicast notifications. In particular: control the sending of multicast notifications. In particular:
o The multicast notifications MUST be Non-confirmable. o The multicast notifications MUST be Non-confirmable.
skipping to change at page 12, line 34 skipping to change at page 13, line 50
This prevents a following, considerable increase of the channel This prevents a following, considerable increase of the channel
load, whose origin would be likely attributed to a router rather load, whose origin would be likely attributed to a router rather
than the server. than the server.
2.5. Cancellation 2.5. Cancellation
At any point in time, the server may want to cancel a group At any point in time, the server may want to cancel a group
observation of a target resource. For instance, the server may observation of a target resource. For instance, the server may
realize that no clients or not enough clients are interested in realize that no clients or not enough clients are interested in
taking part in the group observation anymore. A possible approach taking part in the group observation anymore. A possible approach
that the server can use to assess this is defined in Section 5. that the server can use to assess this is defined in Section 6.
In order to cancel the group observation, the server sends to itself In order to cancel the group observation, the server sends to itself
a phantom cancellation request, i.e. a GET request with an Observe a phantom cancellation request, i.e. a GET request with an Observe
option set to 1 (deregister), without transmitting it on the wire. option set to 1 (deregister), without transmitting it on the wire.
As per Section 3.6 of [RFC7641], all other options MUST be identical As per Section 3.6 of [RFC7641], all other options MUST be identical
to those in the phantom registration request, except for the set of to those in the phantom registration request, except for the set of
ETag Options. This request has the same Token value T of the phantom ETag Options. This request has the same Token value T of the phantom
registration request, and is addressed to the resource for which the registration request, and is addressed to the resource for which the
server wants to end the group observation, as if sent by the group of server wants to end the group observation, as if sent by the group of
observers, i.e. with the multicast IP address GRP_ADDR as source observers, i.e. with the multicast IP address GRP_ADDR as source
skipping to change at page 13, line 31 skipping to change at page 14, line 48
3.2. Informative Response 3.2. Informative Response
Upon receiving the informative response defined in Section 2.2, the Upon receiving the informative response defined in Section 2.2, the
client proceeds as follows. client proceeds as follows.
1. The client configures an observation of the target resource. To 1. The client configures an observation of the target resource. To
this end, it relies on a CoAP endpoint used for messages having: this end, it relies on a CoAP endpoint used for messages having:
* As source address and port number, the server address SRV_ADDR * As source address and port number, the server address SRV_ADDR
and port number SRV_PORT intended for accessing the target and port number SRV_PORT intended for accessing the target
resource. These are specified as value of the 'srv_addr' and resource. These are specified as value of the 'srv_host' and
'srv_port' elements of the 'tp_info' parameter, in the 'srv_port' elements of 'srv_addr' under the 'tp_info'
informative response (see Section 2.2.2.1). parameter, in the informative response (see Section 2.2.1.1).
* As destination address and port number, the IP multicast * As destination address and port number, the IP multicast
address GRP_ADDR and port number GRP_PORT. These are address GRP_ADDR and port number GRP_PORT. These are
specified as value of the 'cli_addr' and 'cli_port' elements specified as value of the 'cli_addr' and 'cli_port' elements
of the 'tp_info' parameter, in the informative response (see of 'req_info' under the 'tp_info' parameter, in the
Section 2.2.2.1). If the 'cli_port' element is omitted in the informative response (see Section 2.2.1.1). If the 'cli_port'
'tp_info' parameter, the client MUST assume the default port element is omitted in 'req_info', the client MUST assume the
number 5683 as GRP_PORT. default port number 5683 as GRP_PORT.
2. The client rebuilds the phantom registration request, by using: 2. The client rebuilds the phantom registration request, by using:
* The transport-independent information, specified in the * The transport-independent information, specified in the
'ph_req' parameter of the informative response. 'ph_req' parameter of the informative response.
* The Token value T, specified in the 'token' element of the * The Token value T, specified in the 'token' element of
'tp_info' parameter of the informative response. 'req_info' under the 'tp_info' parameter of the informative
response.
3. The client stores the phantom registration request, as associated 3. The client stores the phantom registration request, as associated
to the observation of the target resource. In particular, the to the observation of the target resource. In particular, the
client MUST use the Token value T of this phantom registration client MUST use the Token value T of this phantom registration
request as its own local Token value associated to that group request as its own local Token value associated to that group
observation, with respect to the server. The particular way to observation, with respect to the server. The particular way to
achieve this is implementation specific. achieve this is implementation specific.
4. The client rebuilds the latest multicast notification, by using: 4. If the informative response includes the parameter 'last_notif',
the client rebuilds the latest multicast notification, by using:
* The transport-independent information, specified in the * The transport-independent information, specified in the
'last_notif' parameter of the informative response. 'last_notif' parameter of the informative response.
* The Token value T, specified in the 'token' element of the * The Token value T, specified in the 'token' element of
'tp_info' parameter of the informative response. 'req_info' under the 'tp_info' parameter of the informative
response.
5. Then, the client processes the latest multicast notification as 5. If the informative response includes the parameter 'last_notif',
defined in Section 3.2 of [RFC7641]. In particular, the value of the client processes the multicast notification rebuilt in step 4
the Observe option is used as initial baseline for notification as defined in Section 3.2 of [RFC7641]. In particular, the value
reordering in this group observation. of the Observe option is used as initial baseline for
notification reordering in this group observation.
6. If a traditional observation to the target resource is ongoing, 6. If a traditional observation to the target resource is ongoing,
the client MAY silently cancel it without notifying the server. the client MAY silently cancel it without notifying the server.
If any of the expected fields in the informative response are not If any of the expected fields in the informative response are not
present or malformed, the client MAY try sending a new registration present or malformed, the client MAY try sending a new registration
request to the server (see Section 3.1). Otherwise, the client request to the server (see Section 3.1). Otherwise, the client
SHOULD explicitly withdraw from the group observation. SHOULD explicitly withdraw from the group observation.
Appendix A describes possible alternative ways for clients to Appendix A describes possible alternative ways for clients to
skipping to change at page 15, line 13 skipping to change at page 16, line 34
When this happens, the client can simply "forget" about being part of When this happens, the client can simply "forget" about being part of
the group observation for that target resource, as per Section 3.6 of the group observation for that target resource, as per Section 3.6 of
[RFC7641]. [RFC7641].
When, later on, the server sends the next multicast notification, the When, later on, the server sends the next multicast notification, the
client will not recognize the Token value T in the message. Since client will not recognize the Token value T in the message. Since
the multicast notification is Non-confirmable, it is OPTIONAL for the the multicast notification is Non-confirmable, it is OPTIONAL for the
client to reject the multicast notification with a Reset message, as client to reject the multicast notification with a Reset message, as
defined in Section 3.5 of [RFC7641]. defined in Section 3.5 of [RFC7641].
In case the server has cancelled a group observation as defined in In case the server has canceled a group observation as defined in
Section 2.5, the client simply forgets about the group observation Section 2.5, the client simply forgets about the group observation
and frees up the used Token value T for that endpoint, upon receiving and frees up the used Token value T for that endpoint, upon receiving
the multicast error response defined in Section 2.5. the multicast error response defined in Section 2.5.
4. Example 4. Web Linking
The possible use of multicast notifications in a group observation
may be indicated by a target "grp_obs" attribute in a web link
[RFC8288] to a resource, e.g. using a link-format document [RFC6690]
if the resource is accessible over CoAP.
The "grp_obs" attribute is a hint, indicating that the server might
send multicast notifications for observations of the resource
targeted by the link. Note that this is simply a hint, i.e. it does
not include any information required to participate in a group
observation, and to receive and process multicast notifications.
A value MUST NOT be given for the "grp_obs" attribute; any present
value MUST be ignored by parsers. The "grp_obs" attribute MUST NOT
appear more than once in a given link-value; occurrences after the
first MUST be ignored by parsers.
The example in Figure 4 shows a use of the "grp_obs" attribute: the
client does resource discovery on a server and gets back a list of
resources, one of which includes the "grp_obs" attribute indicating
that the server might send multicast notifications for observations
of that resource. The link-format notation (see Section 5 of
[RFC6690]) is used.
REQ: GET /.well-known/core
RES: 2.05 Content
</sensors/temp>;grp_obs,
</sensors/light>;if="sensor"
Figure 4: The Web Link
5. Example
The following example refers to two clients C_1 and C_2 that register The following example refers to two clients C_1 and C_2 that register
to observe a resource /r at a Server S, which has address SRV_ADDR to observe a resource /r at a Server S, which has address SRV_ADDR
and listens to the port number SRV_PORT. Before the following and listens to the port number SRV_PORT. Before the following
exchanges occur, no clients are observing the resource /r , which has exchanges occur, no clients are observing the resource /r , which has
value "1234". value "1234".
The server S sends multicast notifications to the IP multicast The server S sends multicast notifications to the IP multicast
address GRP_ADDR and port number GRP_PORT, and starts the group address GRP_ADDR and port number GRP_PORT, and starts the group
observation upon receiving a registration request from a first client observation upon receiving a registration request from a first client
skipping to change at page 16, line 28 skipping to change at page 18, line 36
| | | |
| (S increments the observer counter | | (S increments the observer counter |
| for the group observation of /r .) | | for the group observation of /r .) |
| | | |
C_1 <-------------------- [ Unicast ] --------------------- S C_1 <-------------------- [ Unicast ] --------------------- S
| 5.03 | | 5.03 |
| Token: 0x4a | | Token: 0x4a |
| Content-Format: application/informative-response+cbor | | Content-Format: application/informative-response+cbor |
| <Other options> | | <Other options> |
| Payload: { | | Payload: { |
| tp_info : [1, bstr(SRV_ADDR), SRV_PORT, |
| 0x7b, bstr(GRP_ADDR), GRP_PORT], |
| ph_req : bstr(0x01 | OPT), | | ph_req : bstr(0x01 | OPT), |
| last_notif : bstr(0x25 | OPT | 0xff | PAYLOAD), | | last_notif : bstr(0x45 | OPT | 0xff | PAYLOAD) |
| tp_info : [1, 0x7b, bstr(SRV_ADDR), SRV_PORT, |
| bstr(GRP_ADDR), GRP_PORT] |
| } | | } |
| | | |
C_2 ----------------- [ Unicast ] ------------------------> S /r C_2 ----------------- [ Unicast ] ------------------------> S /r
| GET | | GET |
| Token: 0x01 | | Token: 0x01 |
| Observe: 0 (Register) | | Observe: 0 (Register) |
| <Other options> | | <Other options> |
| | | |
| (S increments the observer counter | | (S increments the observer counter |
| for the group observation of /r .) | | for the group observation of /r .) |
| | | |
| |
C_2 <-------------------- [ Unicast ] --------------------- S C_2 <-------------------- [ Unicast ] --------------------- S
| 5.03 | | 5.03 |
| Token: 0x01 | | Token: 0x01 |
| Content-Format: application/informative-response+cbor | | Content-Format: application/informative-response+cbor |
| <Other options> | | <Other options> |
| Payload: { | | Payload: { |
| tp_info : [1, bstr(SRV_ADDR), SRV_PORT, |
| 0x7b, bstr(GRP_ADDR), GRP_PORT], |
| ph_req : bstr(0x01 | OPT), | | ph_req : bstr(0x01 | OPT), |
| last_notif : bstr(0x25 | OPT | 0xff | PAYLOAD), | | last_notif : bstr(0x45 | OPT | 0xff | PAYLOAD) |
| tp_info : [1, 0x7b, bstr(SRV_ADDR), SRV_PORT, |
| bstr(GRP_ADDR), GRP_PORT] |
| } | | } |
| | | |
| (The value of the resource /r changes to "5678".) | | (The value of the resource /r changes to "5678".) |
| | | |
C_1 | C_1 |
+ <------------------- [ Multicast ] -------------------- S + <------------------- [ Multicast ] -------------------- S
C_2 (Destination address/port: GRP_ADDR/GRP_PORT) | C_2 (Destination address/port: GRP_ADDR/GRP_PORT) |
| 2.05 | | 2.05 |
| Token: 0x7b | | Token: 0x7b |
| Observe: 11 | | Observe: 11 |
| Content-Format: application/cbor | | Content-Format: application/cbor |
| <Other options> | | <Other options> |
| Payload: : "5678" | | Payload: : "5678" |
| | | |
5. Rough Counting of Clients in the Group Observation Figure 5: Example of group observation
6. Rough Counting of Clients in the Group Observation
To allow the server to keep an estimate of interested clients without To allow the server to keep an estimate of interested clients without
creating undue traffic on the network, a new CoAP option is creating undue traffic on the network, a new CoAP option is
introduced, which SHOULD be supported by clients that listen to introduced, which SHOULD be supported by clients that listen to
multicast responses. multicast responses.
The option is called Multicast-Response-Feedback-Divider. As The option is called Multicast-Response-Feedback-Divider. As
summarized in Figure 1, the option is not critical but proxy-unsafe, summarized in Figure 6, the option is not critical but proxy-unsafe,
and integer valued. and integer valued.
+-----+---+---+---+---+---------------------+--------+------+---------+ +-----+---+---+---+---+---------------------+--------+------+---------+
| No. | C | U | N | R | Name | Format | Len. | Default | | No. | C | U | N | R | Name | Format | Len. | Default |
+-----+---+---+---+---+---------------------+--------+------+---------+ +-----+---+---+---+---+---------------------+--------+------+---------+
| TBD | | x | | | Multicast-Response- | uint | 0-1 | (none) | | TBD | | x | | | Multicast-Response- | uint | 0-1 | (none) |
| | | | | | Feedback-Divider | | | | | | | | | | Feedback-Divider | | | |
+-----+---+---+---+---+---------------------+--------+------+---------+ +-----+---+---+---+---+---------------------+--------+------+---------+
C = Critical, U = Unsafe, N = NoCacheKey, R = Repeatable C = Critical, U = Unsafe, N = NoCacheKey, R = Repeatable
Figure 1: Multicast-Response-Feedback-Divider Figure 6: Multicast-Response-Feedback-Divider
The Multicast-Response-Feedback-Divider option is of class E for The Multicast-Response-Feedback-Divider option is of class E for
OSCORE [RFC8613][I-D.ietf-core-oscore-groupcomm]. OSCORE [RFC8613][I-D.ietf-core-oscore-groupcomm].
5.1. Processing on the Client Side 6.1. Processing on the Client Side
Upon receiving a response with a Multicast-Response-Feedback-Divider Upon receiving a response with a Multicast-Response-Feedback-Divider
option, a client SHOULD acknowledge its interest in continuing option, a client SHOULD acknowledge its interest in continuing
receiving multicast notifications for the target resource, as receiving multicast notifications for the target resource, as
described below. described below.
The client picks an integer random number I, from 0 inclusive to the The client picks an integer random number I, from 0 inclusive to the
number Z = (2 ** Q) exclusive, where Q is the value specified in the number Z = (2 ** Q) exclusive, where Q is the value specified in the
option and "**" is the exponentiation operator. If I is different option and "**" is the exponentiation operator. If I is different
than 0, the client takes no further action. Otherwise, the client than 0, the client takes no further action. Otherwise, the client
skipping to change at page 18, line 45 skipping to change at page 21, line 19
in a re-registration request triggered by the server as described in a re-registration request triggered by the server as described
above, and MUST NOT include it in any other request. above, and MUST NOT include it in any other request.
As the Multicast-Response-Feedback-Divider option is unsafe to As the Multicast-Response-Feedback-Divider option is unsafe to
forward, a proxy needs to answer it on its own, and is later counted forward, a proxy needs to answer it on its own, and is later counted
as a single client. as a single client.
Appendix B.1 provides a description in pseudo-code of the operations Appendix B.1 provides a description in pseudo-code of the operations
above performed by the client. above performed by the client.
5.2. Processing on the Server Side 6.2. Processing on the Server Side
In order to avoid needless use of network resources, a server SHOULD In order to avoid needless use of network resources, a server SHOULD
keep a rough, updated count of the number of clients taking part in keep a rough, updated count of the number of clients taking part in
the group observation of a target resource. To this end, the server the group observation of a target resource. To this end, the server
updates the value COUNT of the associated observer counter (see updates the value COUNT of the associated observer counter (see
Section 2), for instance by using the method described below. Section 2), for instance by using the method described below.
5.2.1. Request for Feedback 6.2.1. Request for Feedback
When it wants to obtain a new estimated count, the server considers a When it wants to obtain a new estimated count, the server considers a
number M of confirmations it would like to receive from the clients. number M of confirmations it would like to receive from the clients.
It is up to applications to define policies about how the server It is up to applications to define policies about how the server
determines and possibly adjusts the value of M. determines and possibly adjusts the value of M.
Then, the server computes the value Q = max(L, 0), where: Then, the server computes the value Q = max(L, 0), where:
o L is computed as L = ceil(log2(N / M)). o L is computed as L = ceil(log2(N / M)).
skipping to change at page 19, line 27 skipping to change at page 22, line 5
up to 1, i.e. N = max(COUNT, 1). up to 1, i.e. N = max(COUNT, 1).
Finally, the server sets Q as the value of the Multicast-Response- Finally, the server sets Q as the value of the Multicast-Response-
Feedback-Divider option, which is sent within a successful multicast Feedback-Divider option, which is sent within a successful multicast
notification. notification.
If several multicast notifications are sent in a burst fashion, it is If several multicast notifications are sent in a burst fashion, it is
RECOMMENDED for the server to include the Multicast-Response- RECOMMENDED for the server to include the Multicast-Response-
Feedback-Divider option only in the first one of those notifications. Feedback-Divider option only in the first one of those notifications.
5.2.2. Collection of Feedback 6.2.2. Collection of Feedback
The server collects unicast observation requests from the clients, The server collects unicast observation requests from the clients,
for an amount of time of MAX_CONFIRMATION_WAIT seconds. During this for an amount of time of MAX_CONFIRMATION_WAIT seconds. During this
time, the server regularly increments the observer counter when time, the server regularly increments the observer counter when
adding a new client to the group observation (see Section 2.2). adding a new client to the group observation (see Section 2.2).
It is up to applications to define the value of It is up to applications to define the value of
MAX_CONFIRMATION_WAIT, which has to take into account the MAX_CONFIRMATION_WAIT, which has to take into account the
transmission time of the multicast notification and of unicast transmission time of the multicast notification and of unicast
observation requests, as well as the leisure time of the clients, observation requests, as well as the leisure time of the clients,
skipping to change at page 20, line 12 skipping to change at page 22, line 37
the absence of more specific information, the server can thus the absence of more specific information, the server can thus
consider a conservative MAX_CONFIRMATION_WAIT of 452 seconds. consider a conservative MAX_CONFIRMATION_WAIT of 452 seconds.
If more information is available in deployments, a much shorter If more information is available in deployments, a much shorter
MAX_CONFIRMATION_WAIT can be set. This can be based on a realistic MAX_CONFIRMATION_WAIT can be set. This can be based on a realistic
round trip time (replacing MAX_RTT) and on the largest leisure time round trip time (replacing MAX_RTT) and on the largest leisure time
configured on the clients (replacing MAX_CLIENT_REQUEST_DELAY), e.g. configured on the clients (replacing MAX_CLIENT_REQUEST_DELAY), e.g.
DEFAULT_LEISURE = 5 seconds, thus shortening MAX_CONFIRMATION_WAIT to DEFAULT_LEISURE = 5 seconds, thus shortening MAX_CONFIRMATION_WAIT to
a few seconds. a few seconds.
5.2.3. Processing of Feedback 6.2.3. Processing of Feedback
Once MAX_CONFIRMATION_WAIT seconds have passed, the server counts the Once MAX_CONFIRMATION_WAIT seconds have passed, the server counts the
R confirmations arrived as unicast observation requests to the target R confirmations arrived as unicast observation requests to the target
resource, since the multicast notification with the Multicast- resource, since the multicast notification with the Multicast-
Response-Feedback-Divider option has been sent. In particular, the Response-Feedback-Divider option has been sent. In particular, the
server considers a unicast observation request as a confirmation from server considers a unicast observation request as a confirmation from
a client only if it includes a Multicast-Response-Feedback-Divider a client only if it includes a Multicast-Response-Feedback-Divider
option with an empty value (Option Length = 0). option with an empty value (Option Length = 0).
Then, the server computes a feedback indicator as F = R * (2 ** Q), Then, the server computes a feedback indicator as E = R * (2 ** Q),
where "**" is the exponentiation operator. According to what defined where "**" is the exponentiation operator. According to what defined
by application policies, the server determines the next time when to by application policies, the server determines the next time when to
ask clients for their confirmation, e.g. after a certain number of ask clients for their confirmation, e.g. after a certain number of
multicast notifications has been sent. For example, the decision can multicast notifications has been sent. For example, the decision can
be influenced by the reception of no confirmations from the clients, be influenced by the reception of no confirmations from the clients,
i.e. R = 0, or by the value of the ratios (F/N) and (N/F). i.e. R = 0, or by the value of the ratios (E/N) and (N/E).
Finally, the server computes a new estimated count of the observers. Finally, the server computes a new estimated count of the observers.
To this end the server first consider COUNT' as the current value of To this end the server first consider COUNT' as the current value of
the observer counter at this point in time. Note that COUNT' may be the observer counter at this point in time. Note that COUNT' may be
greater than the value COUNT used at the beginning of this process, greater than the value COUNT used at the beginning of this process,
if the server has incremented the observer counter upon adding new if the server has incremented the observer counter upon adding new
clients to the group observation (see Section 2.2). clients to the group observation (see Section 2.2).
In particular, the server computes the new estimated count value as In particular, the server computes the new estimated count value as
COUNT' + ((E - N) / D), where D > 0 is an integer value used as COUNT' + ((E - N) / D), where D > 0 is an integer value used as
dampener. This step has to be performed atomically. That is, until dampener. This step has to be performed atomically. That is, until
this step is completed, the server MUST hold the processing of an this step is completed, the server MUST hold the processing of an
observation request for the same target resource from a new client. observation request for the same target resource from a new client.
Finally, the server considers the result as the current observer Finally, the server considers the result as the current observer
counter, and assesses it for possibly cancelling the group counter, and assesses it for possibly canceling the group observation
observation (see Section 2.5). (see Section 2.5).
This estimate is skewed by packet loss, but it gives the server a This estimate is skewed by packet loss, but it gives the server a
sufficiently good estimation for further counts and for deciding when sufficiently good estimation for further counts and for deciding when
to cancel the group observation. It is up to applications to define to cancel the group observation. It is up to applications to define
policies about how the server takes the newly updated estimate into policies about how the server takes the newly updated estimate into
account and determines whether to cancel the group observation. account and determines whether to cancel the group observation.
As an example, if the server currently estimates that N = COUNT = 32 As an example, if the server currently estimates that N = COUNT = 32
observers are active and considers a constant M = 8, it sends out a observers are active and considers a constant M = 8, it sends out a
notification with Multicast-Response-Feedback-Divider: 2. Then, out notification with Multicast-Response-Feedback-Divider: 2. Then, out
skipping to change at page 21, line 29 skipping to change at page 24, line 5
multicast notifications, as if M is equal to N. This will trigger multicast notifications, as if M is equal to N. This will trigger
all the active clients to state their interest in continuing all the active clients to state their interest in continuing
receiving notifications for the target resource. Thus, the amount R receiving notifications for the target resource. Thus, the amount R
of arrived confirmations is affected only by possible packet loss. of arrived confirmations is affected only by possible packet loss.
Appendix B.3 provides a description in pseudo-code of the operations Appendix B.3 provides a description in pseudo-code of the operations
above performed by the server, including example behaviors for above performed by the server, including example behaviors for
scheduling the next count update and deciding whether to cancel the scheduling the next count update and deciding whether to cancel the
group observation. group observation.
6. Protection of Multicast Notifications with Group OSCORE 7. Protection of Multicast Notifications with Group OSCORE
A server can protect multicast notifications by using Group OSCORE A server can protect multicast notifications by using Group OSCORE
[I-D.ietf-core-oscore-groupcomm], thus ensuring they are protected [I-D.ietf-core-oscore-groupcomm], thus ensuring they are protected
end-to-end with the observer clients. This requires that both the end-to-end with the observer clients. This requires that both the
server and the clients interested in receiving multicast server and the clients interested in receiving multicast
notifications from that server are members of the same OSCORE group. notifications from that server are members of the same OSCORE group.
In some settings, the OSCORE group to refer to can be pre-configured In some settings, the OSCORE group to refer to can be pre-configured
on the clients and the server. In such a case, a server which is on the clients and the server. In such a case, a server which is
aware of such pre-configuration can simply assume a client to be aware of such pre-configuration can simply assume a client to be
already member of the correct OSCORE group. already member of the correct OSCORE group.
In any other case, the server MAY communicate to clients what OSCORE In any other case, the server MAY communicate to clients what OSCORE
group they are required to join, by providing additional guidance in group they are required to join, by providing additional guidance in
the informative response as described in Section 6.1. Note that the informative response as described in Section 7.1. Note that
clients can already be members of the right OSCORE group, in case clients can already be members of the right OSCORE group, in case
they have previously joined it to securely communicate with the same they have previously joined it to securely communicate with the same
and/or other servers to access their resources. and/or other servers to access their resources.
Both the clients and the server MAY join the OSCORE group by using Both the clients and the server MAY join the OSCORE group by using
the approach described in [I-D.ietf-ace-key-groupcomm-oscore] and the approach described in [I-D.ietf-ace-key-groupcomm-oscore] and
based on the ACE framework for Authentication and Authorization in based on the ACE framework for Authentication and Authorization in
constrained environments [I-D.ietf-ace-oauth-authz]. Further details constrained environments [I-D.ietf-ace-oauth-authz]. Further details
on how to discover the OSCORE group and join it are out of the scope on how to discover the OSCORE group and join it are out of the scope
of this specification. of this specification.
skipping to change at page 22, line 18 skipping to change at page 24, line 43
original registration requests and related unicast (notification) original registration requests and related unicast (notification)
responses MUST also be secured, including and especially the responses MUST also be secured, including and especially the
informative responses from the server. informative responses from the server.
To this end, alternative security protocols than Group OSCORE, such To this end, alternative security protocols than Group OSCORE, such
as OSCORE [RFC8613] and/or DTLS [RFC6347][I-D.ietf-tls-dtls13], can as OSCORE [RFC8613] and/or DTLS [RFC6347][I-D.ietf-tls-dtls13], can
be used to protect other exchanges via unicast between the server and be used to protect other exchanges via unicast between the server and
each client, including the original client registration (see each client, including the original client registration (see
Section 3). Section 3).
6.1. Signaling the OSCORE Group in the Informative Response 7.1. Signaling the OSCORE Group in the Informative Response
This section describes a mechanism for the server to communicate to This section describes a mechanism for the server to communicate to
the client what OSCORE group to join in order to decrypt and verify the client what OSCORE group to join in order to decrypt and verify
the multicast notifications protected with group OSCORE. The client the multicast notifications protected with group OSCORE. The client
MAY use the information provided by the server to start the ACE MAY use the information provided by the server to start the ACE
joining procedure described in [I-D.ietf-ace-key-groupcomm-oscore]. joining procedure described in [I-D.ietf-ace-key-groupcomm-oscore].
This mechanism is OPTIONAL to support for the client and server. This mechanism is OPTIONAL to support for the client and server.
Additionally to what defined in Section 2, the CBOR map in the Additionally to what defined in Section 2, the CBOR map in the
informative response payload contains the following fields, whose informative response payload contains the following fields, whose
CBOR labels are defined in Section 10. CBOR labels are defined in Section 11.
o 'join_uri', with value the URI for joining the OSCORE group at the o 'join_uri', with value the URI for joining the OSCORE group at the
respective Group Manager, encoded as a CBOR text string. If the respective Group Manager, encoded as a CBOR text string. If the
procedure described in [I-D.ietf-ace-key-groupcomm-oscore] is used procedure described in [I-D.ietf-ace-key-groupcomm-oscore] is used
for joining, this field specifically indicates the URI of the for joining, this field specifically indicates the URI of the
group-membership resource at the Group Manager. group-membership resource at the Group Manager.
o 'sec_gp', with value the name of the OSCORE group, encoded as a o 'sec_gp', with value the name of the OSCORE group, encoded as a
CBOR text string. CBOR text string.
skipping to change at page 24, line 15 skipping to change at page 26, line 40
As mentioned above, since this mechanism is OPTIONAL, all the fields As mentioned above, since this mechanism is OPTIONAL, all the fields
are OPTIONAL in the informative response. However, the 'join_uri' are OPTIONAL in the informative response. However, the 'join_uri'
and 'sec_gp' fields MUST be present if the mechanism is implemented and 'sec_gp' fields MUST be present if the mechanism is implemented
and used. If any of the fields are present without the 'join_uri' and used. If any of the fields are present without the 'join_uri'
and 'sec_gp' fields present, the client MUST ignore these fields, and 'sec_gp' fields present, the client MUST ignore these fields,
since they would not be sufficient to start the (ACE) join procedure. since they would not be sufficient to start the (ACE) join procedure.
When this happens, the client MAY try sending a new registration When this happens, the client MAY try sending a new registration
request to the server (see Section 3.1). Otherwise, the client request to the server (see Section 3.1). Otherwise, the client
SHOULD explicitly withdraw from the group observation. SHOULD explicitly withdraw from the group observation.
6.2. Server-Side Requirements Appendix C describes a possible alternative approach, where the
server self-manages the OSCORE group, and provides the observer
clients with the necessary keying material in the informative
response. The approach in Appendix C MUST NOT be used together with
the mechanism defined in this section for indicating what OSCORE
group to join.
7.2. Server-Side Requirements
When using Group OSCORE to protect multicast notifications, the When using Group OSCORE to protect multicast notifications, the
server performs the operations described in Section 2, with the server performs the operations described in Section 2, with the
following differences. following differences.
6.2.1. Registration 7.2.1. Registration
The phantom registration request MUST be secured, by using Group The phantom registration request MUST be secured, by using Group
OSCORE. In particular, the group mode of Group OSCORE defined in OSCORE. In particular, the group mode of Group OSCORE defined in
Section 8 of [I-D.ietf-core-oscore-groupcomm] MUST be used. Section 8 of [I-D.ietf-core-oscore-groupcomm] MUST be used.
The server protects the phantom registration request as defined in The server protects the phantom registration request as defined in
Section 8.1 of [I-D.ietf-core-oscore-groupcomm], as if it was the Section 8.1 of [I-D.ietf-core-oscore-groupcomm], as if it was the
actual sender, i.e. by using its Sender Context. As a consequence, actual sender, i.e. by using its Sender Context. As a consequence,
the server consumes the current value of its Sender Sequence Number the server consumes the current value of its Sender Sequence Number
SN in the OSCORE group, and hence updates it to SN* = (SN + 1). SN in the OSCORE group, and hence updates it to SN* = (SN + 1).
Consistently, the OSCORE option in the phantom registration request Consistently, the OSCORE option in the phantom registration request
includes: includes:
o As 'kid', the Sender ID of the server in the OSCORE group. o As 'kid', the Sender ID of the server in the OSCORE group.
o As 'piv', the previously consumed Sender Sequence Number value SN o As 'piv', the previously consumed Sender Sequence Number value SN
of the server in the OSCORE group, i.e. (SN* - 1). of the server in the OSCORE group, i.e. (SN* - 1).
6.2.2. Informative Response 7.2.2. Informative Response
The value of the CBOR byte string in the 'ph_req' parameter encodes The value of the CBOR byte string in the 'ph_req' parameter encodes
the phantom observation request as a message protected with Group the phantom observation request as a message protected with Group
OSCORE (see Section 6.2.1). As a consequence: the specified Code is OSCORE (see Section 7.2.1). As a consequence: the specified Code is
always 0.05 (FETCH); the sequence of CoAP options will be limited to always 0.05 (FETCH); the sequence of CoAP options will be limited to
the outer, non encrypted options; a payload is always present, as the the outer, non encrypted options; a payload is always present, as the
authenticated ciphertext followed by the counter signature. authenticated ciphertext followed by the counter signature.
Similarly, the value of the CBOR byte string in the 'last_notif' Similarly, the value of the CBOR byte string in the 'last_notif'
parameter encodes the latest multicast notification as a message parameter encodes the latest multicast notification as a message
protected with Group OSCORE (see Section 6.2.3). This applies also protected with Group OSCORE (see Section 7.2.3). This applies also
to the initial multicast notification INIT_NOTIF built in step 6 of to the initial multicast notification INIT_NOTIF built in step 6 of
Section 2.1. Section 2.1.
Optionally, the informative response includes information on the Optionally, the informative response includes information on the
OSCORE group to join, as additional parameters (see Section 6.1). OSCORE group to join, as additional parameters (see Section 7.1).
6.2.3. Notifications 7.2.3. Notifications
The server MUST protect every multicast notification for the target The server MUST protect every multicast notification for the target
resource with Group OSCORE. In particular, the group mode of Group resource with Group OSCORE. In particular, the group mode of Group
OSCORE defined in Section 8 of [I-D.ietf-core-oscore-groupcomm] MUST OSCORE defined in Section 8 of [I-D.ietf-core-oscore-groupcomm] MUST
be used. be used.
The process described in Section 8.3 of The process described in Section 8.3 of
[I-D.ietf-core-oscore-groupcomm] applies, with the following [I-D.ietf-core-oscore-groupcomm] applies, with the following
additions when building the two OSCORE 'external_aad' to encrypt and additions when building the two OSCORE 'external_aad' to encrypt and
countersign the multicast notification (see Sections 4.3.1 and 4.3.2 countersign the multicast notification (see Sections 4.3.1 and 4.3.2
skipping to change at page 25, line 38 skipping to change at page 28, line 22
Number SN of the server. Number SN of the server.
o The 'request_kid_context' is the 'kid context' value in the OSCORE o The 'request_kid_context' is the 'kid context' value in the OSCORE
option of the phantom registration request, i.e. the Group option of the phantom registration request, i.e. the Group
Identifier value (Gid) of the OSCORE group used as ID Context. Identifier value (Gid) of the OSCORE group used as ID Context.
Note that these same values are used to protect each and every Note that these same values are used to protect each and every
multicast notification sent for the target resource under this group multicast notification sent for the target resource under this group
observation. observation.
6.2.4. Cancellation 7.2.4. Cancellation
When cancelling a group observation (see Section 2.5), the phantom When canceling a group observation (see Section 2.5), the phantom
cancellation request MUST be secured, by using Group OSCORE. In cancellation request MUST be secured, by using Group OSCORE. In
particular, the group mode of Group OSCORE defined in Section 8 of particular, the group mode of Group OSCORE defined in Section 8 of
[I-D.ietf-core-oscore-groupcomm] MUST be used. [I-D.ietf-core-oscore-groupcomm] MUST be used.
Like defined in Section 6.2.1 for the phantom registration request, Like defined in Section 7.2.1 for the phantom registration request,
the server protects the phantom cancellation request as per the server protects the phantom cancellation request as per
Section 8.1 of [I-D.ietf-core-oscore-groupcomm], by using its Sender Section 8.1 of [I-D.ietf-core-oscore-groupcomm], by using its Sender
Context and consuming its current Sender Sequence number in the Context and consuming its current Sender Sequence number in the
OSCORE group, from its Sender Context. The following, corresponding OSCORE group, from its Sender Context. The following, corresponding
multicast error response defined in Section 2.5 is also protected multicast error response defined in Section 2.5 is also protected
with Group OSCORE, as per Section 8.3 of with Group OSCORE, as per Section 8.3 of
[I-D.ietf-core-oscore-groupcomm]. [I-D.ietf-core-oscore-groupcomm].
Note that, differently from the multicast notifications, this Note that, differently from the multicast notifications, this
multicast error response will be the only one securely paired with multicast error response will be the only one securely paired with
the phantom cancellation request. the phantom cancellation request.
6.3. Client-Side Requirements 7.3. Client-Side Requirements
When using Group OSCORE to protect multicast notifications, the When using Group OSCORE to protect multicast notifications, the
client performs as described in Section 3, with the following client performs as described in Section 3, with the following
differences. differences.
6.3.1. Informative Response 7.3.1. Informative Response
Upon receiving the informative response from the server, the client Upon receiving the informative response from the server, the client
performs as described in Section 3.2, with the following additions. performs as described in Section 3.2, with the following additions.
Once completed step 2, the client decrypts and verifies the rebuilt Once completed step 2, the client decrypts and verifies the rebuilt
phantom registration request as defined in Section 8.2 of phantom registration request as defined in Section 8.2 of
[I-D.ietf-core-oscore-groupcomm], with the following differences. [I-D.ietf-core-oscore-groupcomm], with the following differences.
o The client MUST NOT perform any replay check. That is, the client o The client MUST NOT perform any replay check. That is, the client
skips step 3 in Section 8.2 of [RFC8613]. skips step 3 in Section 8.2 of [RFC8613].
skipping to change at page 27, line 5 skipping to change at page 29, line 41
* The client stores the values of the 'kid', 'piv' and 'kid * The client stores the values of the 'kid', 'piv' and 'kid
context' fields from the OSCORE option of the phantom context' fields from the OSCORE option of the phantom
registration request. registration request.
o If decryption and verification of the phantom registration request o If decryption and verification of the phantom registration request
fail, the client MAY try sending a new registration request to the fail, the client MAY try sending a new registration request to the
server (see Section 3.1). Otherwise, the client SHOULD explicitly server (see Section 3.1). Otherwise, the client SHOULD explicitly
withdraw from the group observation. withdraw from the group observation.
Once completed step 4, the client also decrypts and verifies the o If the informative response includes the parameter 'last_notif',
rebuilt latest multicast notification, just like it would for the the client also decrypts and verifies the latest multicast
multicast notifications transmitted as CoAP messages on the wire (see notification rebuilt in step 4, just like it would for the
Section 6.3.2). The client proceeds with step 5 if decryption and multicast notifications transmitted as CoAP messages on the wire
verification of the latest multicast notification succeed, or to step (see Section 7.3.2). The client proceeds with step 5 if
6 otherwise. decryption and verification of the latest multicast notification
succeed, or to step 6 otherwise.
6.3.2. Notifications 7.3.2. Notifications
After having successfully processed the informative response as After having successfully processed the informative response as
defined in Section 6.3.1, the client will decrypt and verify every defined in Section 7.3.1, the client will decrypt and verify every
multicast notification for the target resource as defined in multicast notification for the target resource as defined in
Section 8.4 of [I-D.ietf-core-oscore-groupcomm], with the following Section 8.4 of [I-D.ietf-core-oscore-groupcomm], with the following
difference. difference.
The client MUST set the two 'external_aad' defined in Sections 4.3.1 The client MUST set the two 'external_aad' defined in Sections 4.3.1
and 4.3.2 of [I-D.ietf-core-oscore-groupcomm] as follows. The and 4.3.2 of [I-D.ietf-core-oscore-groupcomm] as follows. The
particular way to achieve this is implementation specific. particular way to achieve this is implementation specific.
o 'request_kid' takes the value of the 'kid' field from the OSCORE o 'request_kid' takes the value of the 'kid' field from the OSCORE
option of the phantom registration request (see Section 6.3.1). option of the phantom registration request (see Section 7.3.1).
o 'request_piv' takes the value of the 'piv' field from the OSCORE o 'request_piv' takes the value of the 'piv' field from the OSCORE
option of the phantom registration request (see Section 6.3.1). option of the phantom registration request (see Section 7.3.1).
o 'request_kid_context' takes the value of the 'kid context' field o 'request_kid_context' takes the value of the 'kid context' field
from the OSCORE option of the phantom registration request (see from the OSCORE option of the phantom registration request (see
Section 6.3.1). Section 7.3.1).
Note that these same values are used to decrypt and verify each and Note that these same values are used to decrypt and verify each and
every multicast notification received for the target resource. every multicast notification received for the target resource.
The replay protection and checking of multicast notifications is The replay protection and checking of multicast notifications is
performed as specified in Section 4.1.3.5.2 of [RFC8613]. performed as specified in Section 4.1.3.5.2 of [RFC8613].
7. Example with Group OSCORE 8. Example with Group OSCORE
The following example refers to two clients C_1 and C_2 that register The following example refers to two clients C_1 and C_2 that register
to observe a resource /r at a Server S, which has address SRV_ADDR to observe a resource /r at a Server S, which has address SRV_ADDR
and listens to the port number SRV_PORT. Before the following and listens to the port number SRV_PORT. Before the following
exchanges occur, no clients are observing the resource /r , which has exchanges occur, no clients are observing the resource /r , which has
value "1234". value "1234".
The server S sends multicast notifications to the IP multicast The server S sends multicast notifications to the IP multicast
address GRP_ADDR and port number GRP_PORT, and starts the group address GRP_ADDR and port number GRP_PORT, and starts the group
observation upon receiving a registration request from a first client observation upon receiving a registration request from a first client
that wishes to start a traditional observation on the resource /r. that wishes to start a traditional observation on the resource /r.
Pairwise communication over unicast are protected with OSCORE, while Pairwise communication over unicast is protected with OSCORE, while S
S protects multicast notifications with Group OSCORE. Specifically: protects multicast notifications with Group OSCORE. Specifically:
o C_1 and S have a pairwise OSCORE Security Context. In particular, o C_1 and S have a pairwise OSCORE Security Context. In particular,
C_1 has 'kid' = 1 as Sender ID, and SN_1 = 101 as Sender Sequence C_1 has 'kid' = 1 as Sender ID, and SN_1 = 101 as Sender Sequence
Number. Also, S has 'kid' = 3 as Sender ID, and SN_3 = 301 as Number. Also, S has 'kid' = 3 as Sender ID, and SN_3 = 301 as
Sender Sequence Number. Sender Sequence Number.
o C_2 and S have a pairwise OSCORE Security Context. In particular, o C_2 and S have a pairwise OSCORE Security Context. In particular,
C_2 has 'kid' = 2 as Sender ID, and SN_2 = 201 as Sender Sequence C_2 has 'kid' = 2 as Sender ID, and SN_2 = 201 as Sender Sequence
Number. Also, S has 'kid' = 4 as Sender ID, and SN_4 = 401 as Number. Also, S has 'kid' = 4 as Sender ID, and SN_4 = 401 as
Sender Sequence Number. Sender Sequence Number.
skipping to change at page 29, line 8 skipping to change at page 32, line 4
| <Other class U/I options> | | <Other class U/I options> |
| 0xff | | 0xff |
| Encrypted_payload { | | Encrypted_payload { |
| 0x01 (GET), | | 0x01 (GET), |
| Observe: 0 (Register), | | Observe: 0 (Register), |
| <Other class E options> | | <Other class E options> |
| } | | } |
| | | |
| (S allocates the available Token value 0x7b .) | | (S allocates the available Token value 0x7b .) |
| | | |
| |
| (S sends to itself a phantom observation request PH_REQ | | (S sends to itself a phantom observation request PH_REQ |
| as coming from the IP multicast address GRP_ADDR .) | | as coming from the IP multicast address GRP_ADDR .) |
| ------------------------------------------------------ | | ------------------------------------------------------ |
| / | | / |
| \-------------------------------------------------------> | /r | \-------------------------------------------------------> | /r
| 0.05 (FETCH) | | 0.05 (FETCH) |
| Token: 0x7b | | Token: 0x7b |
| OSCORE: {kid: 5 ; piv: 501 ; | | OSCORE: {kid: 5 ; piv: 501 ; |
| kid context: 57ab2e; ...} | | kid context: 57ab2e; ...} |
| <Other class U/I options> | | <Other class U/I options> |
skipping to change at page 29, line 47 skipping to change at page 32, line 44
| Token: 0x4a | | Token: 0x4a |
| OSCORE: {piv: 301; ...} | | OSCORE: {piv: 301; ...} |
| <Other class U/I options> | | <Other class U/I options> |
| 0xff | | 0xff |
| Encrypted_payload { | | Encrypted_payload { |
| 5.03 (Service Unavailable), | | 5.03 (Service Unavailable), |
| Content-Format: application/informative-response+cbor, | | Content-Format: application/informative-response+cbor, |
| <Other class E options>, | | <Other class E options>, |
| 0xff, | | 0xff, |
| CBOR_payload { | | CBOR_payload { |
| tp_info : [1, bstr(SRV_ADDR), SRV_PORT, |
| 0x7b, bstr(GRP_ADDR), GRP_PORT], |
| ph_req : bstr(0x05 | OPT | 0xff | PAYLOAD | SIGN), | | ph_req : bstr(0x05 | OPT | 0xff | PAYLOAD | SIGN), |
| last_notif : bstr(0x25 | OPT | 0xff | PAYLOAD | SIGN), | | last_notif : bstr(0x45 | OPT | 0xff | PAYLOAD | SIGN), |
| tp_info : [1, 0x7b, bstr(SRV_ADDR), SRV_PORT, |
| bstr(GRP_ADDR), GRP_PORT], |
| join_uri : "coap://myGM/ace-group/myGroup", | | join_uri : "coap://myGM/ace-group/myGroup", |
| sec_gp : "myGroup" | | sec_gp : "myGroup" |
| } | | } |
| } | | } |
| | | |
| | | |
C_2 ------------ [ Unicast w/ OSCORE ] ------------------> S /r C_2 ------------ [ Unicast w/ OSCORE ] ------------------> S /r
| 0.05 (FETCH) | | 0.05 (FETCH) |
| Token: 0x01 | | Token: 0x01 |
| OSCORE: {kid: 2 ; piv: 201 ; ...} | | OSCORE: {kid: 2 ; piv: 201 ; ...} |
skipping to change at page 30, line 36 skipping to change at page 33, line 33
| Token: 0x01 | | Token: 0x01 |
| OSCORE: {piv: 401; ...} | | OSCORE: {piv: 401; ...} |
| <Other class U/I options> | | <Other class U/I options> |
| 0xff, | | 0xff, |
| Encrypted_payload { | | Encrypted_payload { |
| 5.03 (Service Unavailable), | | 5.03 (Service Unavailable), |
| Content-Format: application/informative-response+cbor, | | Content-Format: application/informative-response+cbor, |
| <Other class E options>, | | <Other class E options>, |
| 0xff, | | 0xff, |
| CBOR_payload { | | CBOR_payload { |
| tp_info : [1, bstr(SRV_ADDR), SRV_PORT, |
| 0x7b, bstr(GRP_ADDR), GRP_PORT], |
| ph_req : bstr(0x05 | OPT | 0xff | PAYLOAD | SIGN), | | ph_req : bstr(0x05 | OPT | 0xff | PAYLOAD | SIGN), |
| last_notif : bstr(0x25 | OPT | 0xff | PAYLOAD | SIGN), | | last_notif : bstr(0x45 | OPT | 0xff | PAYLOAD | SIGN), |
| tp_info : [1, 0x7b, bstr(SRV_ADDR), SRV_PORT, |
| bstr(GRP_ADDR), GRP_PORT], |
| join_uri : "coap://myGM/ace-group/myGroup", | | join_uri : "coap://myGM/ace-group/myGroup", |
| sec_gp : "myGroup" | | sec_gp : "myGroup" |
| } | | } |
| } | | } |
| | | |
| | | |
| (The value of the resource /r changes to "5678".) | | (The value of the resource /r changes to "5678".) |
| | | |
C_1 | C_1 |
+ <----------- [ Multicast w/ Group OSCORE ] ------------ S + <----------- [ Multicast w/ Group OSCORE ] ------------ S
skipping to change at page 31, line 20 skipping to change at page 34, line 17
| 2.05 (Content), | | 2.05 (Content), |
| Observe: 11, | | Observe: 11, |
| Content-Format: application/cbor, | | Content-Format: application/cbor, |
| <Other class E options>, | | <Other class E options>, |
| 0xff, | | 0xff, |
| CBOR_Payload : "5678" | | CBOR_Payload : "5678" |
| } | | } |
| <Counter signature> | | <Counter signature> |
| | | |
Figure 7: Example of group observation with Group OSCORE
The two external_aad used to encrypt and countersign the multicast The two external_aad used to encrypt and countersign the multicast
notification above have 'request_kid' = 5, 'request_piv' = 501 and notification above have 'request_kid' = 5, 'request_piv' = 501 and
'request_kid_context' = 0x57ab2e. These values are specified in the 'request_kid_context' = 0x57ab2e. These values are specified in the
'kid', 'piv' and 'kid context' field of the OSCORE option of the 'kid', 'piv' and 'kid context' field of the OSCORE option of the
phantom observation request, which is encoded in the 'ph_req' phantom observation request, which is encoded in the 'ph_req'
parameter of the unicast informative response to the two clients. parameter of the unicast informative response to the two clients.
Thus, the two clients can build the two same external_aad for Thus, the two clients can build the two same external_aad for
decrypting and verifying this multicast notification and the decrypting and verifying this multicast notification and the
following ones. following ones.
8. Intermediaries 9. Intermediaries
This section specifies how the approach presented in Section 2 and This section specifies how the approach presented in Section 2 and
Section 3 works when a proxy is used between the clients and the Section 3 works when a proxy is used between the clients and the
server. In addition to what specified in Section 5.7 of [RFC7252] server. In addition to what specified in Section 5.7 of [RFC7252]
and Section 5 of [RFC7641], the following applies. and Section 5 of [RFC7641], the following applies.
o A client sends its original observation request to the proxy, A client sends its original observation request to the proxy. If the
which forwards it to the server. The server considers the proxy proxy is not already registered at the server for that target
as taking part in the group observation for that target resource, resource, the proxy forwards the observation request to the server,
or takes it as a confirmation of interest if it is already the hence registering itself as an observer. If the server has an
case from previously forwarded observation requests. Then, the ongoing group observation for the target resource or decides to start
server sends the informative response to the proxy, to be one, the server considers the proxy as taking part in the group
forwarded back to the client. observation, and replies to the proxy with an informative response.
o Upon receiving an informative response, the proxy performs as
specified in Section 3, with the difference that it does not
consider the latest multicast notification encoded in the
'last_notif' field. In particular, by using the information
retrieved from the informative response, the proxy configures an
observation of the target resource at the origin server, acting as
a client directly taking part in the group observation. The proxy
MUST NOT cache the informative response.
As a consequence, the proxy will listen to the IP multicast Upon receiving an informative response, the proxy performs as
address and port number indicated by the server in the informative specified for the client in Section 3, with the peculiarity that
response, as 'cli_addr' and 'cli_port' element of the 'tp_info' "consuming" the last notification (if present) means populating its
parameter, respectively (see Section 2.2.2.1). Furthermore, cache.
multicast notifications will match the phantom request stored at
the proxy, based on the Token value specified in the 'token'
element of the 'tp_info' parameter in the informative response.
Note that the proxy configures the observation of the target In particular, by using the information retrieved from the
resource at the server only once, when receiving the first informative response, the proxy configures an observation of the
informative response associated to a newly started group target resource at the origin server, acting as a client directly
observation. That is, after forwarding observation requests from taking part in the group observation.
a following new client to be added to the same group observation,
the proxy does not take any action other than forwarding the
informative response back to that client.
o When forwarding the informative response back to a client, the As a consequence, the proxy will listen to the IP multicast address
proxy adds that client to the list of its registered observers for and port number indicated by the server in the informative response,
the target resource, consistently with the previously received as 'cli_addr' and 'cli_port' element of 'req_info' under the
observation request. In particular, the Token value associated to 'tp_info' parameter, respectively (see Section 2.2.1.1).
this observation and to use with the client is the same Token Furthermore, multicast notifications will match the phantom request
value used in the original registration request that the client stored at the proxy, based on the Token value specified in the
has sent to the proxy. 'token' element of 'req_info' under the 'tp_info' parameter in the
informative response.
o Upon receiving an informative response from the proxy, a client Then, the proxy performs the following actions.
performs as defined in Section 3, with the following differences.
* In step 1, the client relies on a CoAP endpoint used for o If the 'last_notif' field is not present, the proxy responds to
messages having: the client with an Empty Acknowledgement (if indicated by the
message type, and if it has not already done so).
+ As source address and port number, the IP address and port o If the 'last_notif' field is present, the proxy rebuilds the
number used by the proxy, i.e. the source address and port latest multicast notification, as defined in Section 3. Then, the
number of the informative response received from the proxy. proxy responds to the client, by forwarding back the latest
multicast notification.
+ As destination address and port number, the IP address and When responding to an observation request from a client, the proxy
port number used by the client, i.e. the destination address also adds that client (and its Token) to the list of its registered
and port number of the informative response received from observers for the target resource, next to the older observations.
the proxy.
* In step 2, the Token value used when rebuilding the phantom Upon receiving a multicast notification from the server, the proxy
registration request is the same Token value used in the forwards it back separately to each observer client over unicast.
original registration request sent to the proxy. The client Note that the notification forwarded back to a certain client has the
MUST use that Token value as its own local Token value same Token value of the original observation request sent by that
associated to that group observation, with respect to the client to the proxy.
proxy. The particular way to achieve this is implementation
specific. The client does not consider the transport-specific
information specified in the 'tp_info' parameter of the
informative response.
* In step 4, the Token value used when rebuilding the latest Note that the proxy configures the observation of the target resource
multicast notification is the same Token value used to rebuild at the server only once, when receiving the informative response
the phantom registration request, as explained above. associated to a (newly started) group observation for that target
resource.
o Upon receiving a multicast notification from the server, the proxy After that, when receiving an observation request from a following
forwards it back separately to each observer client over unicast. new client to be added to the same group observation, the proxy does
Note that the notification forwarded back to a certain client has not take any further action with the server. Instead, the proxy
the same Token value of the original observation request sent by responds to the client either with the latest multicast notification
that client to the proxy. if available from its cache, or with an Empty Acknowledgement
otherwise, as defined above.
An example is provided in Appendix C. An example is provided in Appendix E.
In the general case with a chain of two or more proxies, every proxy In the general case with a chain of two or more proxies, every proxy
in the chain takes the role of client with the (next hop towards the) in the chain takes the role of client with the (next hop towards the)
origin server. Note that the proxy adjacent to the origin server is origin server. Note that the proxy adjacent to the origin server is
the only one in the chain that listens to an IP multicast address to the only one in the chain that receives informative responses and
receive notifications for the group observation. Furthermore, every listens to an IP multicast address to receive notifications for the
proxy in the chain takes the role of server with the (previous hop group observation. Furthermore, every proxy in the chain takes the
towards the) origin client. role of server with the (previous hop towards the) origin client.
9. Intermediaries Together with End-to-End Security 10. Intermediaries Together with End-to-End Security
As defined in Section 6, Group OSCORE can be used to protect As defined in Section 7, Group OSCORE can be used to protect
multicast notifications end-to-end between the origin server and the multicast notifications end-to-end between the origin server and the
clients. In such a case, additional actions are required when also clients. In such a case, additional actions are required when also
the informative responses from the origin server are protected the informative responses from the origin server are protected
specifically end-to-end, by using OSCORE or Group OSCORE. specifically end-to-end, by using OSCORE or Group OSCORE.
In fact, the proxy adjacent to the origin server is not able to In fact, the proxy adjacent to the origin server is not able to
access the encrypted payload of such informative responses. Hence, access the encrypted payload of such informative responses. Hence,
the proxy cannot retrieve the 'ph_req' and 'tp_info' parameters the proxy cannot retrieve the 'ph_req' and 'tp_info' parameters
necessary to correctly receive multicast notifications and forward necessary to correctly receive multicast notifications and forward
them back to the clients. them back to the clients.
Then, differently from what defined in Section 8, each proxy Then, differently from what defined in Section 9, each proxy
receiving an informative response simply forwards it back to the receiving an informative response simply forwards it back to the
client that has sent the corresponding observation request. Note client that has sent the corresponding observation request. Note
that the proxy does not even realize the message to be an actual that the proxy does not even realize the message to be an actual
informative response, since the outer Code field is set to 2.05 informative response, since the outer Code field is set to 2.05
(Content). (Content).
Once a client receives the informative response, it not only Upon receiving the informative response, the client does not
configures an observation of the target resource at the origin configure an observation of the target resource. Instead, the client
server. In addition, the client transmits the re-built phantom performs a new observe registration request, by transmitting the re-
request as intended to reach the proxy adjacent to the origin server. built phantom request as intended to reach the proxy adjacent to the
In particular, the client includes the new Listen-To-Multicast- origin server. In particular, the client includes the new Listen-To-
Responses CoAP option defined in Section 9.1, to provide that proxy Multicast-Responses CoAP option defined in Section 10.1, to provide
with the transport-specific information required for receiving that proxy with the transport-specific information required for
multicast notifications for the group observation. receiving multicast notifications for the group observation.
Details on the additional message exchange and processing are defined Details on the additional message exchange and processing are defined
in Section 9.2. in Section 10.2.
9.1. The Listen-To-Multicast-Responses Option 10.1. The Listen-To-Multicast-Responses Option
To allow the proxy to listen to the multicast notifications sent by To allow the proxy to listen to the multicast notifications sent by
the server, a new CoAP option is introduced. This option MUST be the server, a new CoAP option is introduced. This option MUST be
supported by clients interested to take part in group observations supported by clients interested to take part in group observations
through intermediaries, and by proxies that collect multicast through intermediaries, and by proxies that collect multicast
notifications and forward them back to the observer clients. notifications and forward them back to the observer clients.
The option is called Listen-To-Multicast-Responses and is intended The option is called Listen-To-Multicast-Responses and is intended
only for requests. As summarized in Figure 2, the option is critical only for requests. As summarized in Figure 8, the option is critical
and proxy-unsafe. and proxy-unsafe.
+-----+---+---+---+---+-------------------+--------+--------+---------+ +-----+---+---+---+---+-------------------+--------+--------+---------+
| No. | C | U | N | R | Name | Format | Len. | Default | | No. | C | U | N | R | Name | Format | Len. | Default |
+-----+---+---+---+---+-------------------+--------+--------+---------+ +-----+---+---+---+---+-------------------+--------+--------+---------+
| TBD | x | x | | | Listen-To- | (*) | 3-1024 | (none) | | TBD | x | x | - | | Listen-To- | (*) | 3-1024 | (none) |
| | | | | | Multicast- | | | | | | | | | | Multicast- | | | |
| | | | | | Responses | | | | | | | | | | Responses | | | |
+-----+---+---+---+---+-------------------+--------+--------+---------+ +-----+---+---+---+---+-------------------+--------+--------+---------+
C = Critical, U = Unsafe, N = NoCacheKey, R = Repeatable C = Critical, U = Unsafe, N = NoCacheKey, R = Repeatable
(*) See below. (*) See below.
Figure 2: Listen-To-Multicast-Responses Figure 8: Listen-To-Multicast-Responses
The Listen-To-Multicast-Responses option includes the serialization The Listen-To-Multicast-Responses option includes the serialization
of a CBOR array. This specifies transport-specific message of a CBOR array. This specifies transport-specific message
information required for listening to the multicast notifications of information required for listening to the multicast notifications of
a group observation, and intended to the proxy adjacent to the origin a group observation, and intended to the proxy adjacent to the origin
server sending those notifications. In particular, the serialized server sending those notifications. In particular, the serialized
CBOR array has the same format specified in Section 2.2.2 for the CBOR array has the same format specified in Section 2.2.1 for the
'tp_info' parameter of the informative response (see Section 2.2). 'tp_info' parameter of the informative response (see Section 2.2).
The Listen-To-Multicast-Responses option is of class U for OSCORE The Listen-To-Multicast-Responses option is of class U for OSCORE
[RFC8613][I-D.ietf-core-oscore-groupcomm]. [RFC8613][I-D.ietf-core-oscore-groupcomm].
9.2. Message Processing 10.2. Message Processing
Compared to Section 8, the following additions apply when informative Compared to Section 9, the following additions apply when informative
responses are protected end-to-end between the origin server and the responses are protected end-to-end between the origin server and the
clients. clients.
After the origin server sends an informative response, each proxy After the origin server sends an informative response, each proxy
simply forwards it back to the (previous hop towards the) origin simply forwards it back to the (previous hop towards the) origin
client that has sent the observation request. client that has sent the observation request.
Once received the informative response, the origin client rebuilds Once received the informative response, the origin client proceeds in
the phantom request and accordingly configures an observation of the a different way than in Section 7.3.1:
target resource, just as defined in Section 8. Then, before
rebuilding the latest multicast notification from the 'last_notif'
parameter of the informative response, the client performs the
following additional actions.
o The client builds a ticket request (see Section 3 of o The client performs all the additional decryption and verification
steps of Section 7.3.1 on the phantom request specified in the
'ph_req' parameter and on the last notification specified in the
'last_notif' parameter (if present).
o The client builds a ticket request (see Appendix B of
[I-D.amsuess-core-cachable-oscore]), as intended to reach the [I-D.amsuess-core-cachable-oscore]), as intended to reach the
proxy adjacent to the origin server. The ticket request is proxy adjacent to the origin server. The ticket request is
formatted as follows. formatted as follows.
* The Token is chosen as the client sees fit. In fact, there is
no reason for this Token to be the same as the phantom
request's.
* The Code field, the outer CoAP options and the encrypted * The Code field, the outer CoAP options and the encrypted
payload concatenated with the counter signature are the same of payload (containing inner options, AEAD tag etc.) are the same
the phantom request used for the group observation. That is, of the phantom request used for the group observation. That
they are as specified in the 'ph_req' parameter of the received is, they are as specified in the 'ph_req' parameter of the
informative response. received informative response.
* An outer Observe option is included and set to 0 (Register). * An outer Observe option is included and set to 0 (Register).
This will usually be set in the phantom request already.
* The outer options Proxy-Scheme, Uri-Host and Uri-Port are * The outer options Proxy-Scheme, Uri-Host and Uri-Port are
included, and set to the same values they had in the original included, and set to the same values they had in the original
registration request sent by the client. registration request sent by the client.
* The new option Listen-To-Multicast-Responses is included as an * The new option Listen-To-Multicast-Responses is included as an
outer option. The value is set to the serialization of the outer option. The value is set to the serialization of the
CBOR array specified by the 'tp_info' parameter of the CBOR array specified by the 'tp_info' parameter of the
informative response. informative response.
skipping to change at page 36, line 42 skipping to change at page 39, line 30
to achieve this is implementation specific. to achieve this is implementation specific.
After that, the proxy will listen to the IP multicast address and After that, the proxy will listen to the IP multicast address and
port number indicated in the Listen-To-Multicast-Responses option, as port number indicated in the Listen-To-Multicast-Responses option, as
'cli_addr' and 'cli_port' element of the serialized CBOR array, 'cli_addr' and 'cli_port' element of the serialized CBOR array,
respectively. Furthermore, multicast notifications will match the respectively. Furthermore, multicast notifications will match the
phantom request stored at the proxy, based on the Token value phantom request stored at the proxy, based on the Token value
specified in the 'token' element of the serialized CBOR array in the specified in the 'token' element of the serialized CBOR array in the
Listen-To-Multicast-Responses option. Listen-To-Multicast-Responses option.
An example is provided in Appendix D. An example is provided in Appendix F.
10. Informative Response Parameters 11. Informative Response Parameters
This specification defines a number of fields used in the informative This specification defines a number of fields used in the informative
response message defined in Section 2.2. response message defined in Section 2.2.
The table below summarizes them and specifies the CBOR key to use The table below summarizes them and specifies the CBOR key to use
instead of the full descriptive name. Note that the media type instead of the full descriptive name. Note that the media type
application/informative-response+cbor MUST be used when these fields application/informative-response+cbor MUST be used when these fields
are transported. are transported.
+------------+----------+-------------------+-------------+ +----------------+----------+-------------------+-------------+
| Name | CBOR Key | CBOR Type | Reference | | Name | CBOR Key | CBOR Type | Reference |
+------------+----------+-------------------+-------------+ +----------------+----------+-------------------+-------------+
| ph_req | 1 | byte string | Section 2.2 | | tp_info | 1 | array | Section 2.2 |
| | | | | | | | | |
| last_notif | 2 | byte string | Section 2.2 | | ph_req | 2 | byte string | Section 2.2 |
| | | | | | | | | |
| tp_info | 3 | array | Section 2.2 | | last_notif | 3 | byte string | Section 2.2 |
| | | | | | | | | |
| join_uri | 4 | text string | Section 6.1 | | join_uri | 4 | text string | Section 7.1 |
| | | | | | | | | |
| sec_gp | 5 | text string | Section 6.1 | | sec_gp | 5 | text string | Section 7.1 |
| | | | | | | | | |
| as_uri | 6 | text string | Section 6.1 | | as_uri | 6 | text string | Section 7.1 |
| | | | | | | | | |
| cs_alg | 7 | int / text string | Section 6.1 | | cs_alg | 7 | int / text string | Section 7.1 |
| | | | | | | | | |
| cs_crv | 8 | int / text string | Section 6.1 | | cs_crv | 8 | int / text string | Section 7.1 |
| | | | | | | | | |
| cs_kty | 9 | int / text string | Section 6.1 | | cs_kty | 9 | int / text string | Section 7.1 |
| | | | | | | | | |
| cs_kenc | 10 | int | Section 6.1 | | cs_kenc | 10 | int | Section 7.1 |
| | | | | | | | | |
| alg | 11 | int / text string | Section 6.1 | | alg | 11 | int / text string | Section 7.1 |
| | | | | | | | | |
| hkdf | 12 | int / text string | Section 6.1 | | hkdf | 12 | int / text string | Section 7.1 |
+------------+----------+-------------------+-------------+ | | | | |
| gp_material | 13 | map | Appendix C |
| | | | |
| srv_pub_key | 14 | byte string | Appendix C |
| | | | |
| srv_identifier | 15 | byte string | Appendix C |
| | | | |
| exp | 16 | uint | Appendix C |
+----------------+----------+-------------------+-------------+
11. Transport Protocol Identifiers Figure 9: CBOR abbreviations for informative response parameters
12. Transport Protocol Information
This specification defines some values of transport protocol This specification defines some values of transport protocol
identifiers used in the 'tp_info' parameter of the informative identifiers to use within the 'tp_info' parameter of the informative
response message defined in Section 2.2 of this specification. response message defined in Section 2.2 of this specification.
According to the encoding specified in Section 2.2.2, these values According to the encoding specified in Section 2.2.1, these values
are used as first element of the CBOR array 'tp_info' of an are used for the 'tp_id' element of 'srv_addr', under the 'tp_info'
informative response message. parameter.
The table below summarizes them, and specifies the integer value to The table below summarizes them, specifies the integer value to use
use instead of the full descriptive name. instead of the full descriptive name, and provides the corresponding
full set of information elements to include in the 'tp_info'
parameter.
+----------+------------------------------------+-------+-----------+ +-----------+-------------+-------+----------+-----------+-----------+
| Name | Description | Value | Reference | | Transport | Description | Value | Srv Addr | Req Info | Reference |
+----------+------------------------------------+-------+-----------+ | Protocol | | | | | |
| Reserved | This value is reserved | 0 | | +-----------+-------------+-------+----------+-----------+-----------+
| | | | | | Reserved | This value | 0 | | | [This |
| UDP | UDP is used to transport CoAP | 1 | Section 2 | | | is reserved | | | | document] |
| | messages, as per [RFC7252] and | | .2.2.1 | | | | | | | |
| | [I-D.ietf-core-groupcomm-bis] | | | | UDP | UDP is used | 1 | tp_id | token | [This |
+----------+------------------------------------+-------+-----------+ | | as per | | srv_host | cli_host | document] |
| | RFC7252 | | srv_port | ?cli_port | |
+-----------+-------------+-------+----------+-----------+-----------+
12. Security Considerations Figure 10: Transport protocol information
13. Security Considerations
The same security considerations from [RFC7252][RFC7641][I-D.ietf-cor The same security considerations from [RFC7252][RFC7641][I-D.ietf-cor
e-groupcomm-bis][RFC8613][I-D.ietf-core-oscore-groupcomm] hold for e-groupcomm-bis][RFC8613][I-D.ietf-core-oscore-groupcomm] hold for
this document. this document.
If multicast notifications are protected using Group OSCORE, the If multicast notifications are protected using Group OSCORE, the
original registration requests and related unicast (notification) original registration requests and related unicast (notification)
responses MUST also be secured, including and especially the responses MUST also be secured, including and especially the
informative responses from the server. This prevents on-path active informative responses from the server. This prevents on-path active
adversaries from altering the conveyed IP multicast address and adversaries from altering the conveyed IP multicast address and
serialized phantom registration request. Thus, it ensures secure serialized phantom registration request. Thus, it ensures secure
binding between every multicast notification for a same observed binding between every multicast notification for a same observed
resource and the phantom registration request that started the group resource and the phantom registration request that started the group
observation of that resource. observation of that resource.
To this end, clients and servers SHOULD use OSCORE or Group OSCORE, To this end, clients and servers SHOULD use OSCORE or Group OSCORE,
so ensuring that the secure binding above is enforced end-to-end so ensuring that the secure binding above is enforced end-to-end
between the server and each observing client. between the server and each observing client.
12.1. Listen-To-Multicast-Responses Option 13.1. Listen-To-Multicast-Responses Option
The CoAP option Listen-To-Multicast-Responses defined in Section 9.1 The CoAP option Listen-To-Multicast-Responses defined in Section 10.1
is of class U for OSCORE and Group OSCORE is of class U for OSCORE and Group OSCORE
[RFC8613][I-D.ietf-core-oscore-groupcomm]. [RFC8613][I-D.ietf-core-oscore-groupcomm].
This allows the proxy adjacent to the origin server to access the This allows the proxy adjacent to the origin server to access the
option value conveyed in a ticket request (see Section 9.2), and to option value conveyed in a ticket request (see Section 10.2), and to
retrieve from it the transport-specific information about a phantom retrieve from it the transport-specific information about a phantom
request. By doing so, the proxy becomes able to configure an request. By doing so, the proxy becomes able to configure an
observation of the target resource and to receive multicast observation of the target resource and to receive multicast
notifications matching to the phantom request. notifications matching to the phantom request.
Any proxy in the chain, as well as further possible intermediaries or Any proxy in the chain, as well as further possible intermediaries or
on-path active adversaries, are thus able to remove the option or on-path active adversaries, are thus able to remove the option or
alter its content, before the ticket request reaches the proxy alter its content, before the ticket request reaches the proxy
adjacent to the origin server. adjacent to the origin server.
skipping to change at page 39, line 22 skipping to change at page 42, line 30
origin server to incorrectly configure a group observation (e.g., by origin server to incorrectly configure a group observation (e.g., by
indicating a wrong multicast IP address) hence preventing the correct indicating a wrong multicast IP address) hence preventing the correct
reception of multicast notifications and their forwarding to the reception of multicast notifications and their forwarding to the
clients; or to configure bogus group observations that are currently clients; or to configure bogus group observations that are currently
not active on the origin server. not active on the origin server.
In order to prevent what described above, the ticket requests In order to prevent what described above, the ticket requests
conveying the Listen-To-Multicast-Responses option can be conveying the Listen-To-Multicast-Responses option can be
additionally protected hop-by-hop. additionally protected hop-by-hop.
13. IANA Considerations 14. IANA Considerations
This document has the following actions for IANA. This document has the following actions for IANA.
13.1. Media Type Registrations 14.1. Media Type Registrations
This specification registers the media type 'application/informative- This specification registers the media type 'application/informative-
response+cbor' for error messages as informative response defined in response+cbor' for error messages as informative response defined in
Section 2.2 of this specification, when carrying parameters encoded Section 2.2 of this specification, when carrying parameters encoded
in CBOR. This registration follows the procedures specified in in CBOR. This registration follows the procedures specified in
[RFC6838]. [RFC6838].
o Type name: application o Type name: application
o Subtype name: informative-response+cbor o Subtype name: informative-response+cbor
o Required parameters: none o Required parameters: N/A
o Optional parameters: none o Optional parameters: N/A
o Encoding considerations: Must be encoded as a CBOR map containing o Encoding considerations: Must be encoded as a CBOR map containing
the parameters defined in Section 2.2 of [this document]. the parameters defined in Section 2.2 of [this document].
o Security considerations: See Section 12 of [this document]. o Security considerations: See Section 13 of [this document].
o Interoperability considerations: n/a o Interoperability considerations: N/A
o Published specification: [this document] o Published specification: [this document]
o Applications that use this media type: The type is used by CoAP o Applications that use this media type: The type is used by CoAP
servers and clients that support error messages as informative servers and clients that support error messages as informative
response defined in Section 2.2 of [this document]. response defined in Section 2.2 of [this document].
o Additional information: n/a o Fragment identifier considerations: N/A
o Additional information: N/A
o Person & email address to contact for further information: o Person & email address to contact for further information:
iesg@ietf.org [1] iesg@ietf.org [1]
o Intended usage: COMMON o Intended usage: COMMON
o Restrictions on usage: None o Restrictions on usage: None
o Author: Marco Tiloca marco.tiloca@ri.se [2] o Author: Marco Tiloca marco.tiloca@ri.se [2]
o Change controller: IESG o Change controller: IESG
13.2. CoAP Content-Formats Registry 14.2. CoAP Content-Formats Registry
IANA is asked to add the following entry to the "CoAP Content- IANA is asked to add the following entry to the "CoAP Content-
Formats" sub-registry defined in Section 12.3 of [RFC7252], within Formats" sub-registry defined in Section 12.3 of [RFC7252], within
the "Constrained RESTful Environments (CoRE) Parameters" registry. the "Constrained RESTful Environments (CoRE) Parameters" registry.
Media Type: application/informative-response+cbor Media Type: application/informative-response+cbor
Encoding: - Encoding: -
ID: TBD ID: TBD
Reference: [this document] Reference: [this document]
13.3. Informative Response Parameters Registry 14.3. Informative Response Parameters Registry
This specification establishes the "Informative Response Parameters" This specification establishes the "Informative Response Parameters"
IANA registry. The registry has been created to use the "Expert IANA registry. The registry has been created to use the "Expert
Review Required" registration procedure [RFC8126]. Expert review Review Required" registration procedure [RFC8126]. Expert review
guidelines are provided in Section 13.6. guidelines are provided in Section 14.6.
The columns of this registry are: The columns of this registry are:
o Name: This is a descriptive name that enables easier reference to o Name: This is a descriptive name that enables easier reference to
the item. The name MUST be unique. It is not used in the the item. The name MUST be unique. It is not used in the
encoding. encoding.
o CBOR Key: This is the value used as CBOR key of the item. These o CBOR Key: This is the value used as CBOR key of the item. These
values MUST be unique. The value can be a positive integer, a values MUST be unique. The value can be a positive integer, a
negative integer, or a string. negative integer, or a string.
o CBOR Type: This contains the CBOR type of the item, or a pointer o CBOR Type: This contains the CBOR type of the item, or a pointer
to the registry that defines its type, when that depends on to the registry that defines its type, when that depends on
another item. another item.
o Reference: This contains a pointer to the public specification for o Reference: This contains a pointer to the public specification for
the item. the item.
This registry has been initially populated by the values in This registry has been initially populated by the values in
Section 10. The "Reference" column for all of these entries refers Section 11. The "Reference" column for all of these entries refers
to sections of this document. to sections of this document.
13.4. Transport Protocol Identifiers Registry 14.4. CoAP Transport Information Registry
This specification establishes the "Transport Protocol Identifiers" This specification defines the subregistry "CoAP Transport
IANA sub-registry, within the "Informative Response Parameters" Information" within the "CoRE Parameters" registry. The registry has
registry defined in Section 13.3 of this specification. The sub- been created to use the "Expert Review Required" registration
registry has been created to use the "Expert Review Required" procedure [RFC8126]. Expert review guidelines are provided in
registration procedure [RFC8126]. Expert review guidelines are Section 14.6.
provided in Section 13.6.
The columns of this sub-registry are: The columns of this registry are:
o Name: This is a descriptive name that enables easier reference to o Transport Protocol: This is a descriptive name that enables easier
the item. The name MUST be unique. It is not used in the reference to the item. The name MUST be unique. It is not used
encoding. in the encoding.
o Description: Text giving an overview of the transport protocol o Description: Text giving an overview of the transport protocol
referred by this item. referred by this item.
o Value: CBOR abbreviation for the name of this transport protocol. o Value: CBOR abbreviation for the transport protocol referred by
Different ranges of values use different registration policies this item. Different ranges of values use different registration
[RFC8126]. Integer values from -256 to 255 are designated as policies [RFC8126]. Integer values from -256 to 255 are
Standards Action. Integer values from -65536 to -257 and from 256 designated as Standards Action. Integer values from -65536 to
to 65535 are designated as Specification Required. Integer values -257 and from 256 to 65535 are designated as Specification
greater than 65535 are designated as Expert Review. Integer Required. Integer values greater than 65535 are designated as
values less than -65536 are marked as Private Use. Expert Review. Integer values less than -65536 are marked as
Private Use.
o Server Addr: List of elements providing addressing information of
the server.
o Req Info: List of elements providing transport-specific
information related to a pertinent CoAP request. Optional
elements are prepended by '?'.
o Reference: This contains a pointer to the public specification for o Reference: This contains a pointer to the public specification for
the item. the item.
This registry has been initially populated by the values in This registry has been initially populated by the values in
Section 11. The "Reference" column for all of these entries refers Section 12. The "Reference" column for all of these entries refers
to sections of this document. to sections of this document.
13.5. CoAP Option Numbers Registry 14.5. CoAP Option Numbers Registry
IANA is asked to enter the following option numbers to the "CoAP IANA is asked to enter the following option numbers to the "CoAP
Option Numbers" registry defined in [RFC7252] within the "CoRE Option Numbers" registry defined in [RFC7252] within the "CoRE
Parameters" registry. Parameters" registry.
+--------+--------------------------------------+-------------------+ +--------+--------------------------------------+-----------------+
| Number | Name | Reference | | Number | Name | Reference |
+--------+--------------------------------------+-------------------+ +--------+--------------------------------------+-----------------+
| TBD | Multicast-Response-Feedback-Divider | [[this document]] | | TBD | Multicast-Response-Feedback-Divider | [This document] |
+--------+--------------------------------------+-------------------+ +--------+--------------------------------------+-----------------+
| TBD | Listen-To-Multicast-Responses | [[this document]] | | TBD | Listen-To-Multicast-Responses | [This document] |
+--------+--------------------------------------+-------------------+ +--------+--------------------------------------+-----------------+
13.6. Expert Review Instructions 14.6. Expert Review Instructions
The IANA registries established in this document are defined as The IANA registries established in this document are defined as
expert review. This section gives some general guidelines for what expert review. This section gives some general guidelines for what
the experts should be looking for, but they are being designated as the experts should be looking for, but they are being designated as
experts for a reason so they should be given substantial latitude. experts for a reason so they should be given substantial latitude.
Expert reviewers should take into consideration the following points: Expert reviewers should take into consideration the following points:
o Point squatting should be discouraged. Reviewers are encouraged o Point squatting should be discouraged. Reviewers are encouraged
to get sufficient information for registration requests to ensure to get sufficient information for registration requests to ensure
skipping to change at page 42, line 42 skipping to change at page 46, line 4
The zones tagged as private use are intended for testing purposes The zones tagged as private use are intended for testing purposes
and closed environments, code points in other ranges should not be and closed environments, code points in other ranges should not be
assigned for testing. assigned for testing.
o Specifications are required for the standards track range of point o Specifications are required for the standards track range of point
assignment. Specifications should exist for specification assignment. Specifications should exist for specification
required ranges, but early assignment before a specification is required ranges, but early assignment before a specification is
available is considered to be permissible. Specifications are available is considered to be permissible. Specifications are
needed for the first-come, first-serve range if they are expected needed for the first-come, first-serve range if they are expected
to be used outside of closed environments in an interoperable way. to be used outside of closed environments in an interoperable way.
When specifications are not provided, the description provided When specifications are not provided, the description provided
needs to have sufficient information to identify what the point is needs to have sufficient information to identify what the point is
being used for. being used for.
o Experts should take into account the expected usage of fields when o Experts should take into account the expected usage of fields when
approving point assignment. The fact that there is a range for approving point assignment. The fact that there is a range for
standards track documents does not mean that a standards track standards track documents does not mean that a standards track
document cannot have points assigned outside of that range. The document cannot have points assigned outside of that range. The
length of the encoded value should be weighed against how many length of the encoded value should be weighed against how many
code points of that length are left, the size of device it will be code points of that length are left, the size of device it will be
used on, and the number of code points left that encode to that used on, and the number of code points left that encode to that
size. size.
14. References 15. References
14.1. Normative References 15.1. Normative References
[COSE.Algorithms] [COSE.Algorithms]
IANA, "COSE Algorithms", IANA, "COSE Algorithms",
<https://www.iana.org/assignments/cose/ <https://www.iana.org/assignments/cose/
cose.xhtml#algorithms>. cose.xhtml#algorithms>.
[COSE.Elliptic.Curves] [COSE.Elliptic.Curves]
IANA, "COSE Elliptic Curves", IANA, "COSE Elliptic Curves",
<https://www.iana.org/assignments/cose/ <https://www.iana.org/assignments/cose/
cose.xhtml#elliptic-curves>. cose.xhtml#elliptic-curves>.
[COSE.Key.Types] [COSE.Key.Types]
IANA, "COSE Key Types", IANA, "COSE Key Types",
<https://www.iana.org/assignments/cose/cose.xhtml#key- <https://www.iana.org/assignments/cose/cose.xhtml#key-
type>. type>.
[I-D.ietf-cbor-7049bis] [I-D.ietf-ace-key-groupcomm-oscore]
Bormann, C. and P. Hoffman, "Concise Binary Object Tiloca, M., Park, J., and F. Palombini, "Key Management
Representation (CBOR)", draft-ietf-cbor-7049bis-16 (work for OSCORE Groups in ACE", draft-ietf-ace-key-groupcomm-
in progress), September 2020. oscore-10 (work in progress), February 2021.
[I-D.ietf-ace-oscore-profile]
Palombini, F., Seitz, L., Selander, G., and M. Gunnarsson,
"OSCORE Profile of the Authentication and Authorization
for Constrained Environments Framework", draft-ietf-ace-
oscore-profile-16 (work in progress), January 2021.
[I-D.ietf-core-groupcomm-bis] [I-D.ietf-core-groupcomm-bis]
Dijk, E., Wang, C., and M. Tiloca, "Group Communication Dijk, E., Wang, C., and M. Tiloca, "Group Communication
for the Constrained Application Protocol (CoAP)", draft- for the Constrained Application Protocol (CoAP)", draft-
ietf-core-groupcomm-bis-02 (work in progress), November ietf-core-groupcomm-bis-03 (work in progress), February
2020. 2021.
[I-D.ietf-core-oscore-groupcomm] [I-D.ietf-core-oscore-groupcomm]
Tiloca, M., Selander, G., Palombini, F., and J. Park, Tiloca, M., Selander, G., Palombini, F., Mattsson, J., and
"Group OSCORE - Secure Group Communication for CoAP", J. Park, "Group OSCORE - Secure Group Communication for
draft-ietf-core-oscore-groupcomm-10 (work in progress), CoAP", draft-ietf-core-oscore-groupcomm-11 (work in
November 2020. progress), February 2021.
[I-D.ietf-cose-rfc8152bis-algs] [I-D.ietf-cose-rfc8152bis-algs]
Schaad, J., "CBOR Object Signing and Encryption (COSE): Schaad, J., "CBOR Object Signing and Encryption (COSE):
Initial Algorithms", draft-ietf-cose-rfc8152bis-algs-12 Initial Algorithms", draft-ietf-cose-rfc8152bis-algs-12
(work in progress), September 2020. (work in progress), September 2020.
[I-D.ietf-cose-rfc8152bis-struct] [I-D.ietf-cose-rfc8152bis-struct]
Schaad, J., "CBOR Object Signing and Encryption (COSE): Schaad, J., "CBOR Object Signing and Encryption (COSE):
Structures and Process", draft-ietf-cose-rfc8152bis- Structures and Process", draft-ietf-cose-rfc8152bis-
struct-14 (work in progress), September 2020. struct-15 (work in progress), February 2021.
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119, Requirement Levels", BCP 14, RFC 2119,
DOI 10.17487/RFC2119, March 1997, DOI 10.17487/RFC2119, March 1997,
<https://www.rfc-editor.org/info/rfc2119>. <https://www.rfc-editor.org/info/rfc2119>.
[RFC4944] Montenegro, G., Kushalnagar, N., Hui, J., and D. Culler, [RFC4944] Montenegro, G., Kushalnagar, N., Hui, J., and D. Culler,
"Transmission of IPv6 Packets over IEEE 802.15.4 "Transmission of IPv6 Packets over IEEE 802.15.4
Networks", RFC 4944, DOI 10.17487/RFC4944, September 2007, Networks", RFC 4944, DOI 10.17487/RFC4944, September 2007,
<https://www.rfc-editor.org/info/rfc4944>. <https://www.rfc-editor.org/info/rfc4944>.
skipping to change at page 44, line 48 skipping to change at page 48, line 18
[RFC8126] Cotton, M., Leiba, B., and T. Narten, "Guidelines for [RFC8126] Cotton, M., Leiba, B., and T. Narten, "Guidelines for
Writing an IANA Considerations Section in RFCs", BCP 26, Writing an IANA Considerations Section in RFCs", BCP 26,
RFC 8126, DOI 10.17487/RFC8126, June 2017, RFC 8126, DOI 10.17487/RFC8126, June 2017,
<https://www.rfc-editor.org/info/rfc8126>. <https://www.rfc-editor.org/info/rfc8126>.
[RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC [RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC
2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174,
May 2017, <https://www.rfc-editor.org/info/rfc8174>. May 2017, <https://www.rfc-editor.org/info/rfc8174>.
[RFC8288] Nottingham, M., "Web Linking", RFC 8288,
DOI 10.17487/RFC8288, October 2017,
<https://www.rfc-editor.org/info/rfc8288>.
[RFC8613] Selander, G., Mattsson, J., Palombini, F., and L. Seitz, [RFC8613] Selander, G., Mattsson, J., Palombini, F., and L. Seitz,
"Object Security for Constrained RESTful Environments "Object Security for Constrained RESTful Environments
(OSCORE)", RFC 8613, DOI 10.17487/RFC8613, July 2019, (OSCORE)", RFC 8613, DOI 10.17487/RFC8613, July 2019,
<https://www.rfc-editor.org/info/rfc8613>. <https://www.rfc-editor.org/info/rfc8613>.
14.2. Informative References [RFC8949] Bormann, C. and P. Hoffman, "Concise Binary Object
Representation (CBOR)", STD 94, RFC 8949,
DOI 10.17487/RFC8949, December 2020,
<https://www.rfc-editor.org/info/rfc8949>.
15.2. Informative References
[I-D.amsuess-core-cachable-oscore] [I-D.amsuess-core-cachable-oscore]
Amsuess, C. and M. Tiloca, "Cachable OSCORE", draft- Amsuess, C. and M. Tiloca, "Cachable OSCORE", draft-
amsuess-core-cachable-oscore-00 (work in progress), July amsuess-core-cachable-oscore-01 (work in progress),
2020. February 2021.
[I-D.ietf-ace-key-groupcomm-oscore]
Tiloca, M., Park, J., and F. Palombini, "Key Management
for OSCORE Groups in ACE", draft-ietf-ace-key-groupcomm-
oscore-09 (work in progress), November 2020.
[I-D.ietf-ace-oauth-authz] [I-D.ietf-ace-oauth-authz]
Seitz, L., Selander, G., Wahlstroem, E., Erdtman, S., and Seitz, L., Selander, G., Wahlstroem, E., Erdtman, S., and
H. Tschofenig, "Authentication and Authorization for H. Tschofenig, "Authentication and Authorization for
Constrained Environments (ACE) using the OAuth 2.0 Constrained Environments (ACE) using the OAuth 2.0
Framework (ACE-OAuth)", draft-ietf-ace-oauth-authz-35 Framework (ACE-OAuth)", draft-ietf-ace-oauth-authz-37
(work in progress), June 2020. (work in progress), February 2021.
[I-D.ietf-core-coap-pubsub] [I-D.ietf-core-coap-pubsub]
Koster, M., Keranen, A., and J. Jimenez, "Publish- Koster, M., Keranen, A., and J. Jimenez, "Publish-
Subscribe Broker for the Constrained Application Protocol Subscribe Broker for the Constrained Application Protocol
(CoAP)", draft-ietf-core-coap-pubsub-09 (work in (CoAP)", draft-ietf-core-coap-pubsub-09 (work in
progress), September 2019. progress), September 2019.
[I-D.ietf-core-coral] [I-D.ietf-core-coral]
Hartke, K., "The Constrained RESTful Application Language Hartke, K., "The Constrained RESTful Application Language
(CoRAL)", draft-ietf-core-coral-03 (work in progress), (CoRAL)", draft-ietf-core-coral-03 (work in progress),
March 2020. March 2020.
[I-D.ietf-core-resource-directory] [I-D.ietf-core-resource-directory]
Shelby, Z., Koster, M., Bormann, C., Stok, P., and C. Amsuess, C., Shelby, Z., Koster, M., Bormann, C., and P.
Amsuess, "CoRE Resource Directory", draft-ietf-core- Stok, "CoRE Resource Directory", draft-ietf-core-resource-
resource-directory-25 (work in progress), July 2020. directory-26 (work in progress), November 2020.
[I-D.ietf-tls-dtls13] [I-D.ietf-tls-dtls13]
Rescorla, E., Tschofenig, H., and N. Modadugu, "The Rescorla, E., Tschofenig, H., and N. Modadugu, "The
Datagram Transport Layer Security (DTLS) Protocol Version Datagram Transport Layer Security (DTLS) Protocol Version
1.3", draft-ietf-tls-dtls13-38 (work in progress), May 1.3", draft-ietf-tls-dtls13-41 (work in progress),
2020. February 2021.
[I-D.tiloca-core-oscore-discovery] [I-D.tiloca-core-oscore-discovery]
Tiloca, M., Amsuess, C., and P. Stok, "Discovery of OSCORE Tiloca, M., Amsuess, C., and P. Stok, "Discovery of OSCORE
Groups with the CoRE Resource Directory", draft-tiloca- Groups with the CoRE Resource Directory", draft-tiloca-
core-oscore-discovery-07 (work in progress), November core-oscore-discovery-08 (work in progress), February
2020. 2021.
[MOBICOM99] [MOBICOM99]
Ni, S., Tseng, Y., Chen, Y., and J. Sheu, "The Broadcast Ni, S., Tseng, Y., Chen, Y., and J. Sheu, "The Broadcast
Storm Problem in a Mobile Ad Hoc Network", Proceedings of Storm Problem in a Mobile Ad Hoc Network", Proceedings of
the 5th annual ACM/IEEE international conference on Mobile the 5th annual ACM/IEEE international conference on Mobile
computing and networking , August 1999, computing and networking , August 1999,
<https://people.eecs.berkeley.edu/~culler/cs294- <https://people.eecs.berkeley.edu/~culler/cs294-
f03/papers/bcast-storm.pdf>. f03/papers/bcast-storm.pdf>.
[RFC6347] Rescorla, E. and N. Modadugu, "Datagram Transport Layer [RFC6347] Rescorla, E. and N. Modadugu, "Datagram Transport Layer
Security Version 1.2", RFC 6347, DOI 10.17487/RFC6347, Security Version 1.2", RFC 6347, DOI 10.17487/RFC6347,
January 2012, <https://www.rfc-editor.org/info/rfc6347>. January 2012, <https://www.rfc-editor.org/info/rfc6347>.
[RFC6690] Shelby, Z., "Constrained RESTful Environments (CoRE) Link
Format", RFC 6690, DOI 10.17487/RFC6690, August 2012,
<https://www.rfc-editor.org/info/rfc6690>.
[RFC7519] Jones, M., Bradley, J., and N. Sakimura, "JSON Web Token
(JWT)", RFC 7519, DOI 10.17487/RFC7519, May 2015,
<https://www.rfc-editor.org/info/rfc7519>.
[RFC8610] Birkholz, H., Vigano, C., and C. Bormann, "Concise Data [RFC8610] Birkholz, H., Vigano, C., and C. Bormann, "Concise Data
Definition Language (CDDL): A Notational Convention to Definition Language (CDDL): A Notational Convention to
Express Concise Binary Object Representation (CBOR) and Express Concise Binary Object Representation (CBOR) and
JSON Data Structures", RFC 8610, DOI 10.17487/RFC8610, JSON Data Structures", RFC 8610, DOI 10.17487/RFC8610,
June 2019, <https://www.rfc-editor.org/info/rfc8610>. June 2019, <https://www.rfc-editor.org/info/rfc8610>.
[RFC8747] Jones, M., Seitz, L., Selander, G., Erdtman, S., and H. [RFC8747] Jones, M., Seitz, L., Selander, G., Erdtman, S., and H.
Tschofenig, "Proof-of-Possession Key Semantics for CBOR Tschofenig, "Proof-of-Possession Key Semantics for CBOR
Web Tokens (CWTs)", RFC 8747, DOI 10.17487/RFC8747, March Web Tokens (CWTs)", RFC 8747, DOI 10.17487/RFC8747, March
2020, <https://www.rfc-editor.org/info/rfc8747>. 2020, <https://www.rfc-editor.org/info/rfc8747>.
14.3. URIs 15.3. URIs
[1] mailto:iesg@ietf.org [1] mailto:iesg@ietf.org
[2] mailto:marco.tiloca@ri.se [2] mailto:marco.tiloca@ri.se
Appendix A. Different Sources for Group Observation Data Appendix A. Different Sources for Group Observation Data
While the clients usually receive the phantom registration request While the clients usually receive the phantom registration request
and other information related to the group observation through an and other information related to the group observation through an
Informative Response, the same data can be made available through Informative Response, the same data can be made available through
skipping to change at page 47, line 17 skipping to change at page 50, line 45
GET </ps/topics?rt=oic.r.temperature> GET </ps/topics?rt=oic.r.temperature>
Accept: CoRAL Accept: CoRAL
Response: Response:
2.05 Content 2.05 Content
Content-Format: CoRAL Content-Format: CoRAL
rdf:type <http://example.org/pubsub/topic-list> rdf:type <http://example.org/pubsub/topic-list>
topic </ps/topics/1234> { topic </ps/topics/1234> {
ph_req h"0160.."
last_notif h"256105.."
tp_info [1, h"7b", h"20010db80100..0001", 5683, tp_info [1, h"7b", h"20010db80100..0001", 5683,
h"ff35003020010db8..1234", 5683] h"ff35003020010db8..1234", 5683],
ph_req h"0160..",
last_notif h"256105.."
} }
Figure 11: Group observation discovery in a Pub-Sub scenario
With this information from the topic discovery step, the client can With this information from the topic discovery step, the client can
already set up its multicast address and start receiving multicast already set up its multicast address and start receiving multicast
notifications. notifications.
In heavily asymmetric networks like municipal notification services, In heavily asymmetric networks like municipal notification services,
discovery and notifications do not necessarily need to use the same discovery and notifications do not necessarily need to use the same
network link. For example, a departure monitor could use its (costly network link. For example, a departure monitor could use its (costly
and usually-off) cellular uplink to discover the topics it needs to and usually-off) cellular uplink to discover the topics it needs to
update its display to, and then listen on a LoRA-WAN interface for update its display to, and then listen on a LoRA-WAN interface for
receiving the actual multicast notifications. receiving the actual multicast notifications.
skipping to change at page 48, line 15 skipping to change at page 51, line 37
Request: Request:
GET </.well-known/core/mc-sender?token=6464> GET </.well-known/core/mc-sender?token=6464>
Response: Response:
2.05 Content 2.05 Content
Content-Format: application/informative-response+cbor Content-Format: application/informative-response+cbor
{ {
'ph_req': h"0160..",
'last_notif' : h"256105..",
'tp_info': [1, h"7b", h"20010db80100..0001", 5683, 'tp_info': [1, h"7b", h"20010db80100..0001", 5683,
h"ff35003020010db8..1234", 5683] h"ff35003020010db8..1234", 5683],
'ph_req': h"0160..",
'last_notif' : h"256105.."
} }
Figure 12: Group observation discovery with server introspection
For example, a network sniffer could offer sending such a request For example, a network sniffer could offer sending such a request
when unknown multicast notifications are seen on a network. when unknown multicast notifications are seen on a network.
Consequently, it can associate those notifications with a URI, or Consequently, it can associate those notifications with a URI, or
decrypt them, if member of the correct OSCORE group. decrypt them, if member of the correct OSCORE group.
Appendix B. Pseudo-Code for Rough Counting of Clients Appendix B. Pseudo-Code for Rough Counting of Clients
This appendix provides a description in pseudo-code of the two This appendix provides a description in pseudo-code of the two
algorithms used for the rough counting of active observers, as algorithms used for the rough counting of active observers, as
defined in Section 5. defined in Section 6.
In particular, Appendix B.1 describes the algorithm for the client In particular, Appendix B.1 describes the algorithm for the client
side, while Appendix B.2 describes an optimized version for side, while Appendix B.2 describes an optimized version for
constrained clients. Finally, Appendix B.3 describes the algorithm constrained clients. Finally, Appendix B.3 describes the algorithm
for the server side. for the server side.
B.1. Client Side B.1. Client Side
input: int Q, // Value of the MRFD option input: int Q, // Value of the MRFD option
int LEISURE_TIME, // DEFAULT_LEISURE from RFC 7252, int LEISURE_TIME, // DEFAULT_LEISURE from RFC 7252,
// unless overridden // unless overridden
output: None output: None
int RAND_MIN = 0; int RAND_MIN = 0;
int RAND_MAX = (2**Q) - 1; int RAND_MAX = (2**Q) - 1;
int I = randomInteger(RAND_MIN, RAND_MAX); int I = randomInteger(RAND_MIN, RAND_MAX);
skipping to change at page 52, line 5 skipping to change at page 55, line 5
int NEW_COUNT = COUNT_PRIME + ((E - N) / D); int NEW_COUNT = COUNT_PRIME + ((E - N) / D);
// Determine whether to cancel the group observation // Determine whether to cancel the group observation
if (NEW_COUNT < CANCEL_THRESHOLD) { if (NEW_COUNT < CANCEL_THRESHOLD) {
<Cancel the group observation>; <Cancel the group observation>;
return 0; return 0;
} }
return NEW_COUNT; return NEW_COUNT;
Appendix C. Example with a Proxy Appendix C. OSCORE Group Self-Managed by the Server
For simple settings, where no pre-arranged group with suitable
memberships is available, the server can be responsible to setup and
manage the OSCORE group used to protect the group observation.
In such a case, a client would implicitly request to join the OSCORE
group when sending the observe registration request to the server.
When replying, the server includes the group keying material and
related information in the informative response (see Section 2.2).
Additionally to what defined in Section 2, the CBOR map in the
informative response payload contains the following fields, whose
CBOR labels are defined in Section 11.
o 'gp_material': this element is a CBOR map, which includes what the
client needs in order to set up the Group OSCORE Security Context.
This parameter has as value a subset of the
Group_OSCORE_Input_Material object, which is defined in
Section 6.4 of [I-D.ietf-ace-key-groupcomm-oscore] and extends the
OSCORE_Input_Material object encoded in CBOR as defined in
Section 3.2.1 of [I-D.ietf-ace-oscore-profile].
In particular, the following elements of the
Group_OSCORE_Input_Material object are included, using the same
CBOR labels from the OSCORE Security Context Parameters Registry,
as in Section 6.4 of [I-D.ietf-ace-key-groupcomm-oscore].
* 'ms', 'contexId', 'cs_alg', 'cs_params', 'cs_key_params',
'cs_key_enc'. These elements MUST be included.
* 'hkdf', 'alg', 'salt'. These elements MAY be included.
The following elements of the Group_OSCORE_Input_Material object
MUST NOT be included.
* 'group_senderId', 'ecdh_alg', 'ecdh_params', 'ecdh_key_params'.
o 'srv_pub_key': this element is a CBOR byte string, which wraps the
serialization of the public key that the server uses in the OSCORE
group. If the public key of the server is encoded as a COSE_Key
(see the 'cs_key_enc' element of the 'gp_material' parameter), it
includes 'kid' specifying the Sender ID that the server has in the
OSCORE group.
o 'srv_identifier': this element MUST be present only if
'srv_pub_key' is also present and, at the same time, the used
encoding for the public key of the server does not allow to
specify a Sender ID within the associated public key. Otherwise,
it MUST NOT be present. If present, this element is a CBOR byte
string, with value the Sender ID that the server has in the OSCORE
group.
o 'exp': with value the expiration time of the keying material of
the OSCORE group specified in the 'gp_material' parameter, encoded
as a CBOR unsigned integer. This field contains a numeric value
representing the number of seconds from 1970-01-01T00:00:00Z UTC
until the specified UTC date/time, ignoring leap seconds,
analogous to what specified for NumericDate in Section 2 of
[RFC7519].
A client receiving an informative response uses the information above
to set up the Group OSCORE Security Context, as described in
Section 2 of [I-D.ietf-core-oscore-groupcomm]. Note that the client
does not obtain a Sender ID of its own, hence it installs a Security
Context that a "silent server" would, i.e. without Sender Context.
From then on, the client uses the received keying material to process
the incoming multicast notifications from the server.
The server complies with the following points.
o The server MUST NOT self-manage OSCORE groups and provide the
related keying material in the informative response for any other
purpose than the protection of group observations, as defined in
this document.
The server MAY use the same self-managed OSCORE group to protect
the phantom request and the multicast notifications of multiple
group observations it hosts.
o The server MUST NOT provide in the informative response the keying
material of other OSCORE groups it is or has been a member of.
After the time indicated in the 'exp' field:
o The server MUST stop using the keying material and MUST cancel the
group observations for which that keying material is used (see
Section 2.5). If the server creates a new group observation as a
replacement or follow-up using the same OSCORE group:
* The server MUST update the Master Secret.
* The server MUST update the ID Context (Gid). Consistently with
Section 2.3 of [I-D.ietf-core-oscore-groupcomm], the server
MUST assign an ID Context that it has never assigned before in
the OSCORE group.
* The server MAY update the Master Salt.
o The client MUST stop using the keying material and MAY re-register
the observation at the server.
Before the key material has expired, the server can send a multicast
response with response code 5.03 (Service Unavailable) to the
observing clients, protected with the current key material. In
particular, this is an informative response (see Section 2.2) and
contains the abovementioned parameters for the next group keying
material to be used. Alternatively, the server can simply cancel the
group observation (see Section 2.5), which results in the eventual
re-registration of the clients that are still interested in the group
observation.
Applications requiring backward security and forward security are
REQUIRED to use an actual group joining process (usually through a
dedicated Group Manager), e.g. the ACE joining procedure defined in
[I-D.ietf-ace-key-groupcomm-oscore]. The server can facilitate the
clients by providing them information about the OSCORE group to join,
as described in Section 7.1.
Appendix D. Phantom Request as Deterministic Request
In some settings, the server can assume that all the approaching
clients already have the exact phantom observation request to use.
For instance, the clients can be pre-configured with the phantom
observation request, or they may be expected to retrieve it through
dedicated means (see Appendix A), before sending an observe
registration request to the server.
If Group OSCORE is used to protect the group observation (see
Section 7), and the OSCORE group supports the concept of
Deterministic Client [I-D.amsuess-core-cachable-oscore], then the
server and each client in the OSCORE group can independently protect
the phantom observation request possibly available as plain CoAP
message. To this end, they use the approach defined in Section 2 of
[I-D.amsuess-core-cachable-oscore] to compute a protected
deterministic request, against which the protected multicast
notifications will match for the group observation in question.
Note that, if the optimization defined in Appendix C is also used,
the error informative response from the server has to include
additional information, i.e. the Sender ID of the Deterministic
Client in the OSCORE group, and the hash algorithm used to compute
the deterministic request (see Section 2.3.1 of
[I-D.amsuess-core-cachable-oscore]).
This optimization allows the server to not provide the same full
phantom observation request to each client in the error informative
response (see Section 2.2). That is, the informative response does
not need to include the 'ph_req' parameter, but only the 'tp_info'
parameter specifying the transport-specific information and
(optionally) the 'last_notif' parameter specifying the latest sent
multicast notification.
Appendix E. Example with a Proxy
This section provides an example when a proxy P is used between the This section provides an example when a proxy P is used between the
clients and the server. The same assumptions and notation used in clients and the server. The same assumptions and notation used in
Section 4 are used for this example. In addition, the proxy has Section 5 are used for this example. In addition, the proxy has
address PRX_ADDR and listens to the port number PRX_PORT. address PRX_ADDR and listens to the port number PRX_PORT.
Unless explicitly indicated, all messages transmitted on the wire are Unless explicitly indicated, all messages transmitted on the wire are
sent over unicast. sent over unicast.
C1 C2 P S C1 C2 P S
| | | | | | | |
| | | | (The value of the resource /r is "1234")
| | | |
+------------>| | Token: 0x4a +------------>| | Token: 0x4a
| GET | | | Observe: 0 (Register) | GET | | | Observe: 0 (Register)
| | | | Proxy-Uri: coap://sensor.example/r | | | | Proxy-Uri: coap://sensor.example/r
| | | | | | | |
| | +------->| Token: 0x5e | | +------->| Token: 0x5e
| | | GET | Observe: 0 (Register) | | | GET | Observe: 0 (Register)
| | | | Uri-Host: sensor.example | | | | Uri-Host: sensor.example
| | | | Uri-Path: r | | | | Uri-Path: r
| | | | | | | |
| | | | (S allocates the available Token value 0x7b) | | | | (S allocates the available Token value 0x7b)
skipping to change at page 52, line 51 skipping to change at page 59, line 16
| | | | | | | |
| | | | (S increments the observer counter | | | | (S increments the observer counter
| | | | for the group observation of /r) | | | | for the group observation of /r)
| | | | | | | |
| | | | | | | |
| | |<-------+ Token: 0x5e | | |<-------+ Token: 0x5e
| | | 5.03 | Content-Format: application/ | | | 5.03 | Content-Format: application/
| | | | informative-response+cbor | | | | informative-response+cbor
| | | | <Other options> | | | | <Other options>
| | | | Payload: { | | | | Payload: {
| | | | tp_info : [1, bstr(SRV_ADDR), SRV_PORT,
| | | | 0x7b, bstr(GRP_ADDR),
| | | | GRP_PORT],
| | | | ph_req : bstr(0x01 | OPT), | | | | ph_req : bstr(0x01 | OPT),
| | | | last_notif : bstr(0x25 | OPT | | | | | last_notif : bstr(0x45 | OPT |
| | | | 0xff | PAYLOAD), | | | | 0xff | PAYLOAD)
| | | | tp_info : [1, 0x7b,
| | | | bstr(SRV_ADDR), SRV_PORT,
| | | | bstr(GRP_ADDR), GRP_PORT]
| | | | } | | | | }
| | | | | | | |
| | | | (PAYLOAD in 'last_notif' : "1234")
| | | |
| | | | | | | |
| | | | (The proxy starts listening to the | | | | (The proxy starts listening to the
| | | | GRP_ADDR address and the GRP_PORT port.) | | | | GRP_ADDR address and the GRP_PORT port.)
| | | | | | | |
| | | | (The proxy adds C1 to its list of observers.) | | | | (The proxy adds C1 to its list of observers.)
| | | | | | | |
| | | | | | | |
|<------------+ | Token: 0x4a |<------------+ | Token: 0x4a
| 5.03 | | | Content-Format: application/ | 2.05 | | | Content-Format: application/cbor
| | | | informative-response+cbor
| | | | <Other options> | | | | <Other options>
| | | | Payload: { | | | | Payload: "1234"
| | | | ph_req : bstr(0x01 | OPT), : : : :
| | | | last_notif : bstr(0x25 | OPT | : : : :
| | | | 0xff | PAYLOAD), : : : :
| | | | tp_info : [1, 0x7b,
| | | | bstr(SRV_ADDR), SRV_PORT,
| | | | bstr(GRP_ADDR), GRP_PORT]
| | | | }
| | | |
| +----->| | Token: 0x01 | +----->| | Token: 0x01
| | GET | | Observe: 0 (Register) | | GET | | Observe: 0 (Register)
| | | | Proxy-Uri: coap://sensor.example/r | | | | Proxy-Uri: coap://sensor.example/r
| | | | | | | |
| | +------->| Token: 0x5e | | | | (The proxy has a fresh cache representation)
| | | GET | Observe: 0 (Register)
| | | | Uri-Host: sensor.example
| | | | Uri-Path: r
| | | |
| | |<-------+ Token: 0x5e
| | | 5.03 | Content-Format: application/
| | | | informative-response+cbor
| | | | <Other options>
| | | | Payload: {
| | | | ph_req : bstr(0x01 | OPT),
| | | | last_notif : bstr(0x25 | OPT |
| | | | 0xff | PAYLOAD),
| | | | tp_info : [1, 0x7b,
| | | | bstr(SRV_ADDR), SRV_PORT,
| | | | bstr(GRP_ADDR), GRP_PORT]
| | | | }
| | | |
| | | | (The proxy adds C2 to its list of observers.)
| | | |
| | | | | | | |
| |<-----+ | Token: 0x4a | |<-----+ | Token: 0x01
| | 5.03 | | Content-Format: application/ | | 2.05 | | Content-Format: application/cbor
| | | | informative-response+cbor
| | | | <Other options> | | | | <Other options>
| | | | Payload: { | | | | Payload: "1234"
| | | | ph_req : bstr(0x01 | OPT),
| | | | last_notif : bstr(0x25 | OPT |
| | | | 0xff | PAYLOAD),
| | | | tp_info : [1, 0x7b,
| | | | bstr(SRV_ADDR), SRV_PORT,
| | | | bstr(GRP_ADDR), GRP_PORT]
| | | | }
| | | | | | | |
| | | | (The value of the resource
| | | | /r changes to "5678".)
| | | | | | | |
| | | (*) | : : : :
: : : : (The value of the resource
: : : : /r changes to "5678".)
: : : (*) :
| | |<-------+ Token: 0x7b | | |<-------+ Token: 0x7b
| | | 2.05 | Observe: 11 | | | 2.05 | Observe: 11
| | | | Content-Format: application/ | | | | Content-Format: application/cbor
| | | | informative-response+cbor
| | | | <Other options> | | | | <Other options>
| | | | Payload: "5678" | | | | Payload: "5678"
| | | | | | | |
|<------------+ | Token: 0x4a |<------------+ | Token: 0x4a
| 2.05 | | | Observe: 54123 | 2.05 | | | Observe: 54123
| | | | Content-Format: application/ | | | | Content-Format: application/cbor
| | | | informative-response+cbor
| | | | <Other options> | | | | <Other options>
| | | | Payload: "5678" | | | | Payload: "5678"
| | | | | | | |
| |<-----+ | Token: 0x01 | |<-----+ | Token: 0x01
| | 2.05 | | Observe: 54123 | | 2.05 | | Observe: 54123
| | | | Content-Format: application/ | | | | Content-Format: application/cbor
| | | | informative-response+cbor
| | | | <Other options> | | | | <Other options>
| | | | Payload: "5678" | | | | Payload: "5678"
(*) Sent over IP multicast to GROUP_ADDR:GROUP_PORT (*) Sent over IP multicast to GROUP_ADDR:GROUP_PORT
Appendix D. Example with a Proxy and Group OSCORE Figure 13: Example of group observation with a proxy
Note that the proxy has all the information to understand the
observation request from C2, and can immediately start to serve the
still fresh values.
This behavior is mandated by Section 5 of [RFC7641], i.e. the proxy
registers itself only once with the next hop and fans out the
notifications it receives to all registered clients.
Appendix F. Example with a Proxy and Group OSCORE
This section provides an example when a proxy P is used between the This section provides an example when a proxy P is used between the
clients and the server, and Group OSCORE is used to protect multicast clients and the server, and Group OSCORE is used to protect multicast
notifications end-to-end between the server and the clients. notifications end-to-end between the server and the clients.
The same assumptions and notation used in Section 7 are used for this The same assumptions and notation used in Section 8 are used for this
example. In addition, the proxy has address PRX_ADDR and listens to example. In addition, the proxy has address PRX_ADDR and listens to
the port number PRX_PORT. the port number PRX_PORT.
Unless explicitly indicated, all messages transmitted on the wire are Unless explicitly indicated, all messages transmitted on the wire are
sent over unicast and protected with OSCORE end-to-end between a sent over unicast and protected with OSCORE end-to-end between a
client and the server. client and the server.
C1 C2 P S C1 C2 P S
| | | | (The value of the resource /r is "1234")
| | | | | | | |
+-------------->| | Token: 0x4a +-------------->| | Token: 0x4a
| FETCH | | | Observe: 0 (Register) | FETCH | | | Observe: 0 (Register)
| | | | OSCORE: {kid: 1 ; piv: 101 ; ...} | | | | OSCORE: {kid: 1 ; piv: 101 ; ...}
| | | | Uri-Host: sensor.example | | | | Uri-Host: sensor.example
| | | | Proxy-Scheme: coap | | | | Proxy-Scheme: coap
| | | | <Other class U/I options> | | | | <Other class U/I options>
| | | | 0xff | | | | 0xff
| | | | Encrypted_payload { | | | | Encrypted_payload {
| | | | 0x01 (GET), | | | | 0x01 (GET),
skipping to change at page 56, line 7 skipping to change at page 61, line 47
| | | | } | | | | }
| | | | | | | |
| | | | | | | |
| | | | (S allocates the available | | | | (S allocates the available
| | | | Token value 0x7b .) | | | | Token value 0x7b .)
| | | | | | | |
| | | | (S sends to itself a phantom observation | | | | (S sends to itself a phantom observation
| | | | request PH_REQ as coming from the | | | | request PH_REQ as coming from the
| | | | IP multicast address GRP_ADDR) | | | | IP multicast address GRP_ADDR)
| | | | | | | |
| | | |
| | | -------+ | | | -------+
| | | / | | | | / |
| | | \------>| Token: 0x7b | | | \------>| Token: 0x7b
| | | FETCH | Observe: 0 (Register) | | | FETCH | Observe: 0 (Register)
| | | | OSCORE: {kid: 5 ; piv: 501 ; | | | | OSCORE: {kid: 5 ; piv: 501 ;
| | | | kid context: 57ab2e; ...} | | | | kid context: 57ab2e; ...}
| | | | Uri-Host: sensor.example | | | | Uri-Host: sensor.example
| | | | <Other class U/I options> | | | | <Other class U/I options>
| | | | 0xff | | | | 0xff
| | | | Encrypted_payload { | | | | Encrypted_payload {
skipping to change at page 56, line 46 skipping to change at page 62, line 36
| | | 2.05 | OSCORE: {piv: 301 ; ...} | | | 2.05 | OSCORE: {piv: 301 ; ...}
| | | | <Other class U/I options> | | | | <Other class U/I options>
| | | | 0xff | | | | 0xff
| | | | Encrypted_payload { | | | | Encrypted_payload {
| | | | 5.03 (Service Unavailable), | | | | 5.03 (Service Unavailable),
| | | | Content-Format: application/ | | | | Content-Format: application/
| | | | informative-response+cbor, | | | | informative-response+cbor,
| | | | <Other class E options>, | | | | <Other class E options>,
| | | | 0xff, | | | | 0xff,
| | | | CBOR_payload { | | | | CBOR_payload {
| | | | tp_info : [1, bstr(SRV_ADDR),
| | | | SRV_PORT, 0x7b,
| | | | bstr(GRP_ADDR), GRP_PORT],
| | | | ph_req : bstr(0x05 | OPT | 0xff | | | | | ph_req : bstr(0x05 | OPT | 0xff |
| | | | PAYLOAD | SIGN), | | | | PAYLOAD | SIGN),
| | | | last_notif : bstr(0x25 | OPT | 0xff | | | | | last_notif : bstr(0x45 | OPT | 0xff |
| | | | PAYLOAD | SIGN), | | | | PAYLOAD | SIGN),
| | | | tp_info : [1, 0x7b, bstr(SRV_ADDR),
| | | | SRV_PORT, bstr(GRP_ADDR),
| | | | GRP_PORT]
| | | | join_uri : "coap://myGM/ | | | | join_uri : "coap://myGM/
| | | | ace-group/myGroup", | | | | ace-group/myGroup",
| | | | sec_gp : "myGroup" | | | | sec_gp : "myGroup"
| | | | } | | | | }
| | | | } | | | | }
| | | | | | | |
| | | |
|<--------------+ | Token: 0x4a |<--------------+ | Token: 0x4a
| 2.05 | | | OSCORE: {piv: 301 ; ...} | 2.05 | | | OSCORE: {piv: 301 ; ...}
| | | | <Other class U/I options> | | | | <Other class U/I options>
| | | | 0xff | | | | 0xff
| | | | Encrypted_payload { | | | | (Same Encrypted_payload)
| | | | 5.03 (Service Unavailable), | | | |
| | | | Content-Format: application/
| | | | informative-response+cbor,
| | | | <Other class E options>,
| | | | 0xff,
| | | | CBOR_payload {
| | | | ph_req : bstr(0x05 | OPT | 0xff |
| | | | PAYLOAD | SIGN),
| | | | last_notif : bstr(0x25 | OPT | 0xff |
| | | | PAYLOAD | SIGN),
| | | | tp_info : [1, 0x7b, bstr(SRV_ADDR),
| | | | SRV_PORT, bstr(GRP_ADDR),
| | | | GRP_PORT]
| | | | join_uri : "coap://myGM/
| | | | ace-group/myGroup",
| | | | sec_gp : "myGroup"
| | | | }
| | | | }
| | | | | | | |
+-------------->| | Token: 0x4b +-------------->| | Token: 0x4b
| FETCH | | | Observe: 0 (Register) | FETCH | | | Observe: 0 (Register)
| | | | OSCORE: {kid: 5 ; piv: 501 ; ...} | | | | OSCORE: {kid: 5 ; piv: 501 ; ...}
| | | | Uri-Host: sensor.example | | | | Uri-Host: sensor.example
| | | | Proxy-Scheme: coap | | | | Proxy-Scheme: coap
| | | | Listen-To- | | | | Listen-To-
| | | | Multicast-Responses: {[0x7b, 1, | | | | Multicast-Responses: {[1, bstr(SRV_ADDR),
| | | | bstr(SRV_ADDR), | | | | SRV_PORT, 0x7b,
| | | | SRV_PORT,
| | | | bstr(GRP_ADDR), | | | | bstr(GRP_ADDR),
| | | | GRP_PORT] | | | | GRP_PORT]
| | | | } | | | | }
| | | | <Other class U/I options> | | | | <Other class U/I options>
| | | | 0xff | | | | 0xff
| | | | Encrypted_payload { | | | | Encrypted_payload {
| | | | 0x01 (GET), | | | | 0x01 (GET),
| | | | Observe: 0 (Register), | | | | Observe: 0 (Register),
| | | | Uri-Path: r | | | | Uri-Path: r
| | | | <Other class E options> | | | | <Other class E options>
| | | | } | | | | }
| | | | <Counter signature> | | | | <Counter signature>
| | | | | | | |
| | | | | | | |
| | | | (The proxy starts listening to the | | | | (The proxy starts listening to the
| | | | GRP_ADDR address and the GRP_PORT port.) | | | | GRP_ADDR address and the GRP_PORT port.)
| | | | | | | |
| | | | (The proxy adds C1 to | | | | (The proxy adds C1 to
| | | | its list of observers.) | | | | its list of observers.)
| | | | : : : :
| | | | : : : :
: : : :
| +------>| | Token: 0x01 | +------>| | Token: 0x01
| | FETCH | | Observe: 0 (Register) | | FETCH | | Observe: 0 (Register)
| | | | OSCORE: {kid: 2 ; piv: 201 ; ...} | | | | OSCORE: {kid: 2 ; piv: 201 ; ...}
| | | | Uri-Host: sensor.example | | | | Uri-Host: sensor.example
| | | | Proxy-Scheme: coap | | | | Proxy-Scheme: coap
| | | | <Other class U/I options> | | | | <Other class U/I options>
| | | | 0xff | | | | 0xff
| | | | Encrypted_payload { | | | | Encrypted_payload {
| | | | 0x01 (GET), | | | | 0x01 (GET),
| | | | Observe: 0 (Register), | | | | Observe: 0 (Register),
skipping to change at page 59, line 7 skipping to change at page 64, line 32
| | | 2.05 | OSCORE: {piv: 401 ; ...} | | | 2.05 | OSCORE: {piv: 401 ; ...}
| | | | <Other class U/I options> | | | | <Other class U/I options>
| | | | 0xff | | | | 0xff
| | | | Encrypted_payload { | | | | Encrypted_payload {
| | | | 5.03 (Service Unavailable), | | | | 5.03 (Service Unavailable),
| | | | Content-Format: application/ | | | | Content-Format: application/
| | | | informative-response+cbor, | | | | informative-response+cbor,
| | | | <Other class E options>, | | | | <Other class E options>,
| | | | 0xff, | | | | 0xff,
| | | | CBOR_payload { | | | | CBOR_payload {
| | | | tp_info : [1, bstr(SRV_ADDR),
| | | | SRV_PORT, 0x7b,
| | | | bstr(GRP_ADDR), GRP_PORT],
| | | | ph_req : bstr(0x05 | OPT | 0xff | | | | | ph_req : bstr(0x05 | OPT | 0xff |
| | | | PAYLOAD | SIGN), | | | | PAYLOAD | SIGN),
| | | | last_notif : bstr(0x25 | OPT | 0xff | | | | | last_notif : bstr(0x45 | OPT | 0xff |
| | | | PAYLOAD | SIGN), | | | | PAYLOAD | SIGN),
| | | | tp_info : [1, 0x7b, bstr(SRV_ADDR),
| | | | SRV_PORT, bstr(GRP_ADDR),
| | | | GRP_PORT]
| | | | join_uri : "coap://myGM/ | | | | join_uri : "coap://myGM/
| | | | ace-group/myGroup", | | | | ace-group/myGroup",
| | | | sec_gp : "myGroup" | | | | sec_gp : "myGroup"
| | | | } | | | | }
| | | | } | | | | }
| | | | | | | |
| |<------+ | Token: 0x01 | |<------+ | Token: 0x01
| | 2.05 | | OSCORE: {piv: 401 ; ...} | | 2.05 | | OSCORE: {piv: 401 ; ...}
| | | | <Other class U/I options> | | | | <Other class U/I options>
| | | | 0xff | | | | 0xff
| | | | Encrypted_payload { | | | | (Same Encrypted_payload)
| | | | 5.03 (Service Unavailable), | | | |
| | | | Content-Format: application/
| | | | informative-response+cbor,
| | | | <Other class E options>,
| | | | 0xff,
| | | | CBOR_payload {
| | | | ph_req : bstr(0x05 | OPT | 0xff |
| | | | PAYLOAD | SIGN),
| | | | last_notif : bstr(0x25 | OPT | 0xff |
| | | | PAYLOAD | SIGN),
| | | | tp_info : [1, 0x7b, bstr(SRV_ADDR),
| | | | SRV_PORT, bstr(GRP_ADDR),
| | | | GRP_PORT]
| | | | join_uri : "coap://myGM/
| | | | ace-group/myGroup",
| | | | sec_gp : "myGroup"
| | | | }
| | | | }
| | | | | | | |
| +------>| | Token: 0x02 | +------>| | Token: 0x02
| | FETCH | | Observe: 0 (Register) | | FETCH | | Observe: 0 (Register)
| | | | OSCORE: {kid: 5 ; piv: 501 ; ...} | | | | OSCORE: {kid: 5 ; piv: 501 ; ...}
| | | | Uri-Host: sensor.example | | | | Uri-Host: sensor.example
| | | | Proxy-Scheme: coap | | | | Proxy-Scheme: coap
| | | | Listen-To- | | | | Listen-To-
| | | | Multicast-Responses: {[0x7b, 1, | | | | Multicast-Responses: {[1, bstr(SRV_ADDR),
| | | | bstr(SRV_ADDR), | | | | SRV_PORT, 0x7b,
| | | | SRV_PORT,
| | | | bstr(GRP_ADDR), | | | | bstr(GRP_ADDR),
| | | | GRP_PORT] | | | | GRP_PORT]
| | | | } | | | | }
| | | | <Other class U/I options> | | | | <Other class U/I options>
| | | | 0xff | | | | 0xff
| | | | Encrypted_payload { | | | | Encrypted_payload {
| | | | 0x01 (GET), | | | | 0x01 (GET),
| | | | Observe: 0 (Register), | | | | Observe: 0 (Register),
| | | | Uri-Path: r | | | | Uri-Path: r
| | | | <Other class E options> | | | | <Other class E options>
| | | | } | | | | }
| | | | <Counter signature> | | | | <Counter signature>
| | | | | | | |
| | | | (The proxy adds C2 to its list of
| | | | observers, and serves the cached
| | | | response)
| | | | | | | |
| | | | (The proxy adds C2 to | |<------+ | Token: 0x02
| | | | its list of observers.) | | 2.05 | | OSCORE: {piv: 301 ; ...}
| | | | | | | | <Other class U/I options>
| | | | | | | | 0xff
| | | | (Same as earlier to C1)
: : : :
: : : :
: : : :
| | | | (The value of the resource | | | | (The value of the resource
| | | | /r changes to "5678".) | | | | /r changes to "5678".)
| | | | | | | |
| | | | | | | |
| | | (*) | | | | (*) |
| | |<--------+ Token: 0x7b | | |<--------+ Token: 0x7b
| | | 2.05 | Observe: 11 | | | 2.05 | Observe: 11
| | | | OSCORE: {kid: 5; piv: 502 ; | | | | OSCORE: {kid: 5; piv: 502 ;
| | | | kid context: 57ab2e; ...} | | | | kid context: 57ab2e; ...}
| | | | <Other class U/I options> | | | | <Other class U/I options>
skipping to change at page 60, line 45 skipping to change at page 66, line 12
| | | | 2.05 (Content), | | | | 2.05 (Content),
| | | | Observe: 11, | | | | Observe: 11,
| | | | Content-Format: application/cbor, | | | | Content-Format: application/cbor,
| | | | <Other class E options>, | | | | <Other class E options>,
| | | | 0xff, | | | | 0xff,
| | | | CBOR_Payload : "5678" | | | | CBOR_Payload : "5678"
| | | | } | | | | }
| | | | <Counter signature> | | | | <Counter signature>
| | | | | | | |
| | | | | | | |
| | | |
|<--------------+ | Token: 0x4b |<--------------+ | Token: 0x4b
| 2.05 | | | Observe: 54123 | 2.05 | | | Observe: 54123
| | | | OSCORE: {kid: 5; piv: 502 ; | | | | OSCORE: {kid: 5; piv: 502 ;
| | | | kid context: 57ab2e; ...} | | | | kid context: 57ab2e; ...}
| | | | <Other class U/I options> | | | | <Other class U/I options>
| | | | 0xff | | | | 0xff
| | | | Encrypted_payload { | | | | (Same Encrypted_payload)
| | | | 2.05 (Content),
| | | | Observe: 11,
| | | | Content-Format: application/cbor,
| | | | <Other class E options>,
| | | | 0xff,
| | | | CBOR_Payload : "5678"
| | | | }
| | | | <Counter signature>
| | | | | | | |
| |<------+ | Token: 0x02 | |<------+ | Token: 0x02
| | 2.05 | | Observe: 54123 | | 2.05 | | Observe: 54123
| | | | OSCORE: {kid: 5; piv: 502 ; | | | | OSCORE: {kid: 5; piv: 502 ;
| | | | kid context: 57ab2e; ...} | | | | kid context: 57ab2e; ...}
| | | | <Other class U/I options> | | | | <Other class U/I options>
| | | | 0xff | | | | 0xff
| | | | Encrypted_payload { | | | | (Same Encrypted_payload)
| | | | 2.05 (Content),
| | | | Observe: 11,
| | | | Content-Format: application/cbor,
| | | | <Other class E options>,
| | | | 0xff,
| | | | CBOR_Payload : "5678"
| | | | }
| | | | <Counter signature>
(*) Sent over IP multicast to GROUP_ADDR:GROUP_PORT and protected (*) Sent over IP multicast to GROUP_ADDR:GROUP_PORT and protected
with Group OSCORE end-to-end between the server and the clients. with Group OSCORE end-to-end between the server and the clients.
Figure 14: Example of group observation with a proxy and Group OSCORE
Unlike in the unprotected example in Appendix E, the proxy does _not_
have all the information to perform request deduplication, and can
only recognize the identical request once the client sends the ticket
request.
Acknowledgments Acknowledgments
The authors sincerely thank Carsten Bormann, Klaus Hartke, Jaime The authors sincerely thank Carsten Bormann, Klaus Hartke, Jaime
Jimenez, John Mattsson, Ludwig Seitz, Jim Schaad and Goeran Selander Jimenez, John Mattsson, Ludwig Seitz, Jim Schaad and Goeran Selander
for their comments and feedback. for their comments and feedback.
The work on this document has been partly supported by VINNOVA and The work on this document has been partly supported by VINNOVA and
the Celtic-Next project CRITISEC; and by the H2020 project SIFIS-Home the Celtic-Next project CRITISEC; and by the H2020 project SIFIS-Home
(Grant agreement 952652). (Grant agreement 952652).
 End of changes. 220 change blocks. 
621 lines changed or deleted 874 lines changed or added

This html diff was produced by rfcdiff 1.45. The latest version is available from http://tools.ietf.org/tools/rfcdiff/