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/ |