draft-ietf-core-observe-multicast-notifications-00.txt | draft-ietf-core-observe-multicast-notifications-01.txt | |||
---|---|---|---|---|
CoRE Working Group M. Tiloca | CoRE Working Group M. Tiloca | |||
Internet-Draft R. Hoeglund | Internet-Draft R. Höglund | |||
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. Amsüss | |||
Expires: 3 October 2021 | Expires: 13 January 2022 | |||
F. Palombini | F. Palombini | |||
Ericsson AB | Ericsson AB | |||
1 April 2021 | 12 July 2021 | |||
Observe Notifications as CoAP Multicast Responses | Observe Notifications as CoAP Multicast Responses | |||
draft-ietf-core-observe-multicast-notifications-00 | draft-ietf-core-observe-multicast-notifications-01 | |||
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 addressed to all the clients | server to send a single notification addressed to all the clients | |||
observing a same target resource. This document updates RFC7252 and | observing a same target resource. This document updates RFC7252 and | |||
RFC7641, and defines how a server sends observe notifications as | RFC7641, and defines how a server sends observe notifications as | |||
response messages over multicast, synchronizing all the observers of | response messages over multicast, synchronizing all the observers of | |||
a same resource on a same shared Token value. Besides, this document | a same resource on a same shared Token value. Besides, this document | |||
defines how Group OSCORE can be used to protect multicast | defines how Group OSCORE can be used to protect multicast | |||
notifications end-to-end between the server and the observer clients. | notifications end-to-end between the server and the observer clients. | |||
Discussion Venues | ||||
This note is to be removed before publishing as an RFC. | ||||
Discussion of this document takes place on the Constrained RESTful | ||||
Environments Working Group mailing list (core@ietf.org), which is | ||||
archived at https://mailarchive.ietf.org/arch/browse/core/. | ||||
Source for this draft and an issue tracker can be found at | ||||
https://github.com/core-wg/observe-multicast-notifications. | ||||
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 3 October 2021. | This Internet-Draft will expire on 13 January 2022. | |||
Copyright Notice | Copyright Notice | |||
Copyright (c) 2021 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 (https://trustee.ietf.org/ | Provisions Relating to IETF Documents (https://trustee.ietf.org/ | |||
license-info) in effect on the date of publication of this document. | license-info) in effect on the date of publication of this document. | |||
Please review these documents carefully, as they describe your rights | Please review these documents carefully, as they describe your rights | |||
and restrictions with respect to this document. Code Components | and restrictions with respect to this document. Code Components | |||
extracted from this document must include Simplified BSD License text | extracted from this document must include Simplified BSD License text | |||
as described in Section 4.e of the Trust Legal Provisions and are | as described in Section 4.e of the Trust Legal Provisions and are | |||
provided without warranty as described in the Simplified BSD License. | provided without warranty as described in the Simplified BSD License. | |||
Table of Contents | Table of Contents | |||
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3 | 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 4 | |||
1.1. Terminology . . . . . . . . . . . . . . . . . . . . . . . 5 | 1.1. Terminology . . . . . . . . . . . . . . . . . . . . . . . 5 | |||
2. Server-Side Requirements . . . . . . . . . . . . . . . . . . 5 | 2. Server-Side Requirements . . . . . . . . . . . . . . . . . . 6 | |||
2.1. Request . . . . . . . . . . . . . . . . . . . . . . . . . 6 | 2.1. Request . . . . . . . . . . . . . . . . . . . . . . . . . 6 | |||
2.2. Informative Response . . . . . . . . . . . . . . . . . . 7 | 2.2. Informative Response . . . . . . . . . . . . . . . . . . 7 | |||
2.2.1. Encoding of Transport-Specific Message Information . 8 | 2.2.1. Encoding of Transport-Specific Message Information . 9 | |||
2.2.2. Encoding of Transport-Independent Message | 2.2.2. Encoding of Transport-Independent Message | |||
Information . . . . . . . . . . . . . . . . . . . . . 11 | Information . . . . . . . . . . . . . . . . . . . . . 12 | |||
2.3. Notifications . . . . . . . . . . . . . . . . . . . . . . 12 | 2.3. Notifications . . . . . . . . . . . . . . . . . . . . . . 12 | |||
2.4. Congestion Control . . . . . . . . . . . . . . . . . . . 13 | 2.4. Congestion Control . . . . . . . . . . . . . . . . . . . 13 | |||
2.5. Cancellation . . . . . . . . . . . . . . . . . . . . . . 13 | 2.5. Cancellation . . . . . . . . . . . . . . . . . . . . . . 14 | |||
3. Client-Side Requirements . . . . . . . . . . . . . . . . . . 14 | 3. Client-Side Requirements . . . . . . . . . . . . . . . . . . 14 | |||
3.1. Request . . . . . . . . . . . . . . . . . . . . . . . . . 14 | 3.1. Request . . . . . . . . . . . . . . . . . . . . . . . . . 14 | |||
3.2. Informative Response . . . . . . . . . . . . . . . . . . 14 | 3.2. Informative Response . . . . . . . . . . . . . . . . . . 14 | |||
3.3. Notifications . . . . . . . . . . . . . . . . . . . . . . 16 | 3.3. Notifications . . . . . . . . . . . . . . . . . . . . . . 16 | |||
3.4. Cancellation . . . . . . . . . . . . . . . . . . . . . . 16 | 3.4. Cancellation . . . . . . . . . . . . . . . . . . . . . . 16 | |||
4. Web Linking . . . . . . . . . . . . . . . . . . . . . . . . . 16 | 4. Web Linking . . . . . . . . . . . . . . . . . . . . . . . . . 16 | |||
5. Example . . . . . . . . . . . . . . . . . . . . . . . . . . . 17 | 5. Example . . . . . . . . . . . . . . . . . . . . . . . . . . . 17 | |||
6. Rough Counting of Clients in the Group Observation . . . . . 19 | 6. Rough Counting of Clients in the Group Observation . . . . . 19 | |||
6.1. Processing on the Client Side . . . . . . . . . . . . . . 20 | 6.1. Multicast-Response-Feedback-Divider Option . . . . . . . 19 | |||
6.2. Processing on the Server Side . . . . . . . . . . . . . . 21 | 6.2. Processing on the Client Side . . . . . . . . . . . . . . 20 | |||
6.2.1. Request for Feedback . . . . . . . . . . . . . . . . 21 | 6.3. Processing on the Server Side . . . . . . . . . . . . . . 21 | |||
6.2.2. Collection of Feedback . . . . . . . . . . . . . . . 21 | 6.3.1. Request for Feedback . . . . . . . . . . . . . . . . 21 | |||
6.2.3. Processing of Feedback . . . . . . . . . . . . . . . 22 | 6.3.2. Collection of Feedback . . . . . . . . . . . . . . . 22 | |||
7. Protection of Multicast Notifications with Group OSCORE . . . 23 | 6.3.3. Processing of Feedback . . . . . . . . . . . . . . . 22 | |||
7.1. Signaling the OSCORE Group in the Informative Response . 24 | ||||
7.2. Server-Side Requirements . . . . . . . . . . . . . . . . 26 | 7. Protection of Multicast Notifications with Group OSCORE . . . 24 | |||
7.2.1. Registration . . . . . . . . . . . . . . . . . . . . 26 | 7.1. Signaling the OSCORE Group in the Informative Response . 25 | |||
7.2.2. Informative Response . . . . . . . . . . . . . . . . 27 | 7.2. Server-Side Requirements . . . . . . . . . . . . . . . . 27 | |||
7.2.3. Notifications . . . . . . . . . . . . . . . . . . . . 27 | 7.2.1. Registration . . . . . . . . . . . . . . . . . . . . 27 | |||
7.2.4. Cancellation . . . . . . . . . . . . . . . . . . . . 28 | 7.2.2. Informative Response . . . . . . . . . . . . . . . . 28 | |||
7.3. Client-Side Requirements . . . . . . . . . . . . . . . . 28 | 7.2.3. Notifications . . . . . . . . . . . . . . . . . . . . 28 | |||
7.3.1. Informative Response . . . . . . . . . . . . . . . . 28 | 7.2.4. Cancellation . . . . . . . . . . . . . . . . . . . . 29 | |||
7.3.2. Notifications . . . . . . . . . . . . . . . . . . . . 29 | 7.3. Client-Side Requirements . . . . . . . . . . . . . . . . 29 | |||
8. Example with Group OSCORE . . . . . . . . . . . . . . . . . . 30 | 7.3.1. Informative Response . . . . . . . . . . . . . . . . 29 | |||
9. Intermediaries . . . . . . . . . . . . . . . . . . . . . . . 34 | 7.3.2. Notifications . . . . . . . . . . . . . . . . . . . . 30 | |||
10. Intermediaries Together with End-to-End Security . . . . . . 35 | 8. Example with Group OSCORE . . . . . . . . . . . . . . . . . . 31 | |||
10.1. The Listen-To-Multicast-Responses Option . . . . . . . . 36 | 9. Intermediaries . . . . . . . . . . . . . . . . . . . . . . . 35 | |||
10.2. Message Processing . . . . . . . . . . . . . . . . . . . 37 | 10. Intermediaries Together with End-to-End Security . . . . . . 36 | |||
11. Informative Response Parameters . . . . . . . . . . . . . . . 39 | 10.1. Listen-To-Multicast-Responses Option . . . . . . . . . . 37 | |||
12. Transport Protocol Information . . . . . . . . . . . . . . . 40 | 10.2. Message Processing . . . . . . . . . . . . . . . . . . . 38 | |||
11. Informative Response Parameters . . . . . . . . . . . . . . . 40 | ||||
12. Transport Protocol Information . . . . . . . . . . . . . . . 41 | ||||
13. Security Considerations . . . . . . . . . . . . . . . . . . . 41 | 13. Security Considerations . . . . . . . . . . . . . . . . . . . 41 | |||
13.1. Listen-To-Multicast-Responses Option . . . . . . . . . . 41 | 13.1. Listen-To-Multicast-Responses Option . . . . . . . . . . 42 | |||
14. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 42 | 14. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 42 | |||
14.1. Media Type Registrations . . . . . . . . . . . . . . . . 42 | 14.1. Media Type Registrations . . . . . . . . . . . . . . . . 43 | |||
14.2. CoAP Content-Formats Registry . . . . . . . . . . . . . 43 | 14.2. CoAP Content-Formats Registry . . . . . . . . . . . . . 44 | |||
14.3. Informative Response Parameters Registry . . . . . . . . 43 | 14.3. Informative Response Parameters Registry . . . . . . . . 44 | |||
14.4. CoAP Transport Information Registry . . . . . . . . . . 44 | 14.4. CoAP Transport Information Registry . . . . . . . . . . 45 | |||
14.5. CoAP Option Numbers Registry . . . . . . . . . . . . . . 45 | 14.5. CoAP Option Numbers Registry . . . . . . . . . . . . . . 45 | |||
14.6. Expert Review Instructions . . . . . . . . . . . . . . . 45 | 14.6. Expert Review Instructions . . . . . . . . . . . . . . . 46 | |||
15. References . . . . . . . . . . . . . . . . . . . . . . . . . 46 | 15. References . . . . . . . . . . . . . . . . . . . . . . . . . 46 | |||
15.1. Normative References . . . . . . . . . . . . . . . . . . 46 | 15.1. Normative References . . . . . . . . . . . . . . . . . . 46 | |||
15.2. Informative References . . . . . . . . . . . . . . . . . 48 | 15.2. Informative References . . . . . . . . . . . . . . . . . 49 | |||
Appendix A. Different Sources for Group Observation Data . . . . 50 | Appendix A. Different Sources for Group Observation Data . . . . 51 | |||
A.1. Topic Discovery in Publish-Subscribe Settings . . . . . . 50 | A.1. Topic Discovery in Publish-Subscribe Settings . . . . . . 51 | |||
A.2. Introspection at the Multicast Notification Sender . . . 51 | A.2. Introspection at the Multicast Notification Sender . . . 52 | |||
Appendix B. Pseudo-Code for Rough Counting of Clients . . . . . 52 | Appendix B. Pseudo-Code for Rough Counting of Clients . . . . . 53 | |||
B.1. Client Side . . . . . . . . . . . . . . . . . . . . . . . 52 | B.1. Client Side . . . . . . . . . . . . . . . . . . . . . . . 53 | |||
B.2. Client Side - Optimized Version . . . . . . . . . . . . . 53 | B.2. Client Side - Optimized Version . . . . . . . . . . . . . 54 | |||
B.3. Server Side . . . . . . . . . . . . . . . . . . . . . . . 54 | B.3. Server Side . . . . . . . . . . . . . . . . . . . . . . . 55 | |||
Appendix C. OSCORE Group Self-Managed by the Server . . . . . . 56 | Appendix C. OSCORE Group Self-Managed by the Server . . . . . . 57 | |||
Appendix D. Phantom Request as Deterministic Request . . . . . . 58 | Appendix D. Phantom Request as Deterministic Request . . . . . . 60 | |||
Appendix E. Example with a Proxy . . . . . . . . . . . . . . . . 59 | Appendix E. Example with a Proxy . . . . . . . . . . . . . . . . 60 | |||
Appendix F. Example with a Proxy and Group OSCORE . . . . . . . 61 | Appendix F. Example with a Proxy and Group OSCORE . . . . . . . 63 | |||
Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . . . 67 | Appendix G. Example with a Proxy and Deterministic Requests . . 69 | |||
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 67 | G.1. Assumptions and Walkthrough . . . . . . . . . . . . . . . 69 | |||
G.2. Message Exchange . . . . . . . . . . . . . . . . . . . . 71 | ||||
Appendix H. Document Updates . . . . . . . . . . . . . . . . . . 76 | ||||
H.1. Version -00 to -01 . . . . . . . . . . . . . . . . . . . 76 | ||||
Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . . . 76 | ||||
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 76 | ||||
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 25 ¶ | skipping to change at page 4, line 44 ¶ | |||
can benefit of observation for discovering (to-be-created) OSCORE | can benefit of observation for discovering (to-be-created) OSCORE | |||
groups [I-D.ietf-core-oscore-groupcomm], by retrieving from the | groups [I-D.ietf-core-oscore-groupcomm], by retrieving from the | |||
Resource Directory updated links and descriptions to join them | Resource Directory updated links and descriptions to join them | |||
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 document fills this gap and provides the | |||
the following twofold contribution. | following twofold contribution. | |||
First, it updates [RFC7252] and [RFC7641], by defining a method to | First, it updates [RFC7252] and [RFC7641], by defining a method to | |||
deliver Observe notifications as CoAP responses addressed to multiple | deliver Observe notifications as CoAP responses addressed to multiple | |||
clients, e.g. over IP multicast. In the proposed method, the group | clients, e.g., over IP multicast. In the proposed method, the group | |||
of potential observers entrusts the server to manage the Token space | of potential observers entrusts the server to manage the Token space | |||
for multicast notifications. By doing so, the server provides all | for multicast notifications. By doing so, the server provides all | |||
the observers of a target resource with the same Token value to bind | 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 | 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 document 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 | |||
resource by using Group OSCORE. This provides a secure binding | resource by using Group OSCORE. This provides a secure binding | |||
between each of such notifications and the observation of each of the | between each of such notifications and the observation of each of the | |||
clients. | clients. | |||
1.1. Terminology | 1.1. Terminology | |||
skipping to change at page 5, line 18 ¶ | skipping to change at page 5, line 32 ¶ | |||
"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 [RFC8949], | [I-D.ietf-core-groupcomm-bis], Observe [RFC7641], CBOR [RFC8949], | |||
OSCORE [RFC8613], and Group OSCORE [I-D.ietf-core-oscore-groupcomm]. | OSCORE [RFC8613], and Group OSCORE [I-D.ietf-core-oscore-groupcomm]. | |||
This specification additionally defines the following terminology. | This document additionally defines the following terminology. | |||
* Traditional observation. A resource observation associated to a | * Traditional observation. A resource observation associated to a | |||
single observer client, as defined in [RFC7641]. | single observer client, as defined in [RFC7641]. | |||
* Group observation. A resource observation associated to a group | * 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. | |||
* Phantom request. The CoAP request message that the server would | * Phantom request. The CoAP request message that the server would | |||
have received to start or cancel a group observation on one of its | have received to start or cancel a group observation on one of its | |||
skipping to change at page 6, line 28 ¶ | skipping to change at page 6, line 46 ¶ | |||
notifications. | 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 | |||
request with an Observe option set to 0 (register). | request with an Observe option set to 0 (register). | |||
2. The server selects an available value T, from the Token space of | 2. The server selects an available value T, from the Token space of | |||
a CoAP endpoint used for messages having: | a CoAP endpoint used for messages having: | |||
* As source address and port number, the IP multicast address | * As source address and port number, the IP multicast address | |||
GRP_ADDR and port number GRP_PORT. | GRP_ADDR and port number GRP_PORT. | |||
* As destination address and port number, the server address | * As destination address and port number, the server address | |||
SRV_ADDR and port number SRV_PORT, intended for accessing the | SRV_ADDR and port number SRV_PORT, intended for accessing the | |||
target resource. | target resource. | |||
This Token space is under exclusive control of the server. | This Token space is under exclusive control of the server. | |||
3. The server processes the phantom observation request above, | 3. The server processes the phantom observation request above, | |||
without transmitting it on the wire. The request is addressed to | without transmitting it on the wire. The request is addressed to | |||
the resource for which the server wants to start the group | the resource for which the server wants to start the group | |||
observation, as if sent by the group of observers, i.e. with | observation, as if sent by the group of observers, i.e., with | |||
GRP_ADDR as source address and GRP_PORT as source port. | GRP_ADDR as source address and GRP_PORT as source port. | |||
4. Upon processing the self-generated phantom registration request, | 4. Upon processing the self-generated phantom registration request, | |||
the server interprets it as an observe registration received from | the server interprets it as an observe registration received from | |||
the group of potential observer clients. In particular, from | the group of potential observer clients. In particular, from | |||
then on, the server MUST use T as its own local Token value | then on, the server MUST use T as its own local Token value | |||
associated to that observation, with respect to the (previous hop | associated to that observation, with respect to the (previous hop | |||
towards the) clients. | towards the) clients. | |||
5. The server does not immediately respond to the phantom | 5. The server does not immediately respond to the phantom | |||
skipping to change at page 8, line 27 ¶ | skipping to change at page 8, line 38 ¶ | |||
* 'last_notif', with value the byte serialization of the transport- | * '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.2. | the CBOR byte string is formatted as defined in Section 2.2.2. | |||
This parameter MAY be included. | This parameter MAY be included. | |||
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 => array, ; 'tp_info', i.e. transport-specific information | 1 => array, ; 'tp_info', i.e., transport-specific information | |||
2 => bstr, ; 'ph_req' (transport-independent information) | 2 => bstr, ; 'ph_req' (transport-independent information) | |||
? 3 => bstr ; 'last_notif' (transport-independent information) | ? 3 => bstr ; 'last_notif' (transport-independent information) | |||
} | } | |||
Figure 1: Format of the informative response payload | 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 | |||
skipping to change at page 9, line 29 ¶ | skipping to change at page 9, line 39 ¶ | |||
) | ) | |||
Figure 2: General format of 'tp_info' | Figure 2: General format of 'tp_info' | |||
The 'srv_addr' element of 'tp_info' specifies the addressing | The 'srv_addr' element of 'tp_info' specifies the addressing | |||
information of the server, and includes at least one element 'tp_id' | information of the server, and includes at least one element 'tp_id' | |||
which is formatted as follows. | which is formatted as follows. | |||
* 'tp_id' : this element is a CBOR integer, which specifies the | * 'tp_id' : this element is a CBOR integer, which specifies the | |||
transport protocol used to transport the CoAP response from the | transport protocol used to transport the CoAP response from the | |||
server, i.e. a multicast notification in this specification. | server, i.e., a multicast notification in this document. | |||
This element takes value from the "Value" column of the "CoAP | This element takes value from the "Value" column of the "CoAP | |||
Transport Information" registry defined in Section 14.4 of this | Transport Information" registry defined in Section 14.4 of this | |||
specification. This element MUST be present. The value of this | document. This element MUST be present. The value of this | |||
element determines: | element determines: | |||
- How many elements are required to follow in 'srv_addr', as well | - How many elements are required to follow in 'srv_addr', as well | |||
as what information they convey, their encoding and their | as what information they convey, their encoding and their | |||
semantics. | semantics. | |||
- How many elements are required in the 'req_info' element of the | - How many elements are required in the 'req_info' element of the | |||
'tp_info' array, as well as what information they convey, their | 'tp_info' array, as well as what information they convey, their | |||
encoding and their semantics. | encoding and their semantics. | |||
This specification registers the integer value 1 ("UDP") to be | This document registers the integer value 1 ("UDP") to be used as | |||
used as value for the 'tp_id' element, when CoAP responses are | value for the 'tp_id' element, when CoAP responses are transported | |||
transported over UDP. In such a case, the full encoding of the | over UDP. In such a case, the full encoding of the 'tp_info' CBOR | |||
'tp_info' CBOR array is as defined in Section 2.2.1.1. | array is as defined in Section 2.2.1.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 entry with an integer value to be used for 'tp_id', | - Register an entry with an integer value to be used for 'tp_id', | |||
in the "CoAP Transport Information" registry defined in | in the "CoAP Transport Information" registry defined in | |||
Section 14.4 of this specification. | Section 14.4 of this document. | |||
- Accordingly, define the elements of the 'tp_info' CBOR array, | - Accordingly, define the elements of the 'tp_info' CBOR array, | |||
i.e. the elements following 'tp_id' in 'srv_addr' as well as | i.e., the elements following 'tp_id' in 'srv_addr' as well as | |||
the elements in 'req_info', as to what information they convey, | the elements in 'req_info', as to what information they convey, | |||
their encoding and their semantics. | their encoding and their semantics. | |||
The 'req_info' element of 'tp_info' specifies transport-specific | The 'req_info' element of 'tp_info' specifies transport-specific | |||
information related to a pertinent request message, i.e. the phantom | information related to a pertinent request message, i.e., the phantom | |||
observation request in this specification. The exact format of | observation request in this document. The exact format of 'req_info' | |||
'req_info' depends on the value of 'tp_id'. | depends on the value of 'tp_id'. | |||
Given a specific value of 'tp_id', the complete set of elements | 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 | 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 | indicated by the two columns "Srv Addr" and "Req Info" of the "CoAP | |||
Transport Information" registry defined in Section 14.4, | Transport Information" registry defined in Section 14.4, | |||
respectively. | respectively. | |||
2.2.1.1. UDP Transport-Specific Information | 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 | |||
skipping to change at page 13, line 18 ¶ | skipping to change at page 13, line 28 ¶ | |||
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: | |||
* The multicast notifications MUST be Non-confirmable. | * The multicast notifications MUST be Non-confirmable. | |||
* In constrained environments such as low-power, lossy networks | * In constrained environments such as low-power, lossy networks | |||
(LLNs), the server should only support multicast notifications for | (LLNs), the server should only support multicast notifications for | |||
resources that are small. Following related guidelines from | resources that are small. Following related guidelines from | |||
Section 2.2.4 of [I-D.ietf-core-groupcomm-bis], this can consist, | Section 3.6 of [I-D.ietf-core-groupcomm-bis], this can consist, | |||
for example, in having the payload of multicast notifications as | for example, in having the payload of multicast notifications as | |||
limited to approximately 5% of the IP Maximum Transmit Unit (MTU) | limited to approximately 5% of the IP Maximum Transmit Unit (MTU) | |||
size, so that it fits into a single link-layer frame in case IPv6 | size, so that it fits into a single link-layer frame in case IPv6 | |||
over Low-Power Wireless Personal Area Networks (6LoWPAN) (see | over Low-Power Wireless Personal Area Networks (6LoWPAN) (see | |||
Section 4 of [RFC4944]) is used. | Section 4 of [RFC4944]) is used. | |||
* The server SHOULD provide multicast notifications with the | * The server SHOULD provide multicast notifications with the | |||
smallest possible IP multicast scope that fulfills the application | smallest possible IP multicast scope that fulfills the application | |||
needs. For example, following related guidelines from | needs. For example, following related guidelines from Section 3.6 | |||
Section 2.2.4 of [I-D.ietf-core-groupcomm-bis], site-local scope | of [I-D.ietf-core-groupcomm-bis], site-local scope is always | |||
is always preferred over global scope IP multicast, if this | preferred over global scope IP multicast, if this fulfills the | |||
fulfills the application needs. Similarly, realm-local scope is | application needs. Similarly, realm-local scope is always | |||
always preferred over site-local scope, if this fulfills the | preferred over site-local scope, if this fulfills the application | |||
application needs. | needs. | |||
* Following related guidelines from Section 4.5.1 of [RFC7641], the | * Following related guidelines from Section 4.5.1 of [RFC7641], the | |||
server SHOULD NOT send more than one multicast notification every | server SHOULD NOT send more than one multicast notification every | |||
3 seconds, and SHOULD use an even less aggressive rate when | 3 seconds, and SHOULD use an even less aggressive rate when | |||
possible (see also Section 3.1.2 of [RFC8085]). The transmission | possible (see also Section 3.1.2 of [RFC8085]). The transmission | |||
rate of multicast notifications should also take into account the | rate of multicast notifications should also take into account the | |||
avoidance of a possible "broadcast storm" problem [MOBICOM99]. | avoidance of a possible "broadcast storm" problem [MOBICOM99]. | |||
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 6. | 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 a | |||
a phantom cancellation request, i.e. a GET request with an Observe | multicast response with response code 5.03 (Service Unavailable), | |||
option set to 1 (deregister), without transmitting it on the wire. | signaling that the group observation has been terminated. The | |||
As per Section 3.6 of [RFC7641], all other options MUST be identical | response has the same Token value T of the phantom registration | |||
to those in the phantom registration request, except for the set of | request, it has no payload, and it does not include an Observe | |||
ETag Options. This request has the same Token value T of the phantom | option. | |||
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 | ||||
observers, i.e. with the multicast IP address GRP_ADDR as source | ||||
address and the port number GRP_PORT as source port. | ||||
After that, the server sends a multicast response with response code | The server sends the response to the same multicast IP address | |||
5.03 (Service Unavailable), signaling that the group observation has | GRP_ADDR and port number GRP_PORT used to send the multicast | |||
been terminated. The response has no payload, and is sent to the | notifications related to the target resource. Finally, the server | |||
same multicast IP address GRP_ADDR and port number GRP_PORT used to | releases the resources allocated for the group observation, and | |||
send the multicast notifications related to the target resource. As | especially frees up the Token value T used at its CoAP endpoint. | |||
per [RFC7641], this response does not include an Observe option. | ||||
Finally, the server releases the resources allocated for the group | ||||
observation, and especially frees up the Token value T used at its | ||||
CoAP endpoint. | ||||
3. Client-Side Requirements | 3. Client-Side Requirements | |||
3.1. Request | 3.1. Request | |||
A client sends an observation request to the server as described in | A client sends an observation request to the server as described in | |||
[RFC7641], i.e. a GET request with an Observe option set to 0 | [RFC7641], i.e., a GET request with an Observe option set to 0 | |||
(register). The request MUST NOT encode link-local addresses. If | (register). The request MUST NOT encode link-local addresses. If | |||
the server is not configured to accept registrations on that target | the server is not configured to accept registrations on that target | |||
resource with a group observation, this would still result in a | resource with a group observation, this would still result in a | |||
positive notification response to the client as described in | positive notification response to the client as described in | |||
[RFC7641]. | [RFC7641]. | |||
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. | |||
skipping to change at page 16, line 43 ¶ | skipping to change at page 16, line 51 ¶ | |||
In case the server has canceled 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. Web Linking | 4. Web Linking | |||
The possible use of multicast notifications in a group observation | The possible use of multicast notifications in a group observation | |||
may be indicated by a target "grp_obs" attribute in a web link | 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] | [RFC8288] to a resource, e.g., using a link-format document | |||
if the resource is accessible over CoAP. | [RFC6690]. | |||
The "grp_obs" attribute is a hint, indicating that the server might | The "grp_obs" attribute is a hint, indicating that the server might | |||
send multicast notifications for observations of the resource | send multicast notifications for observations of the resource | |||
targeted by the link. Note that this is simply a hint, i.e. it does | 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 | not include any information required to participate in a group | |||
observation, and to receive and process multicast notifications. | observation, and to receive and process multicast notifications. | |||
A value MUST NOT be given for the "grp_obs" attribute; any present | 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 | value MUST be ignored by parsers. The "grp_obs" attribute MUST NOT | |||
appear more than once in a given link-value; occurrences after the | appear more than once in a given link-value; occurrences after the | |||
first MUST be ignored by parsers. | first MUST be ignored by parsers. | |||
The example in Figure 4 shows a use of the "grp_obs" attribute: the | 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 | client does resource discovery on a server and gets back a list of | |||
skipping to change at page 18, line 34 ¶ | skipping to change at page 18, line 42 ¶ | |||
| | | | | | |||
| (S creates a group observation of /r .) | | | (S creates a group observation of /r .) | | |||
| | | | | | |||
| (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 | | |||
| Max-Age: 0 | | ||||
| <Other options> | | | <Other options> | | |||
| Payload: { | | | Payload: { | | |||
| tp_info : [1, bstr(SRV_ADDR), SRV_PORT, | | | tp_info : [1, bstr(SRV_ADDR), SRV_PORT, | | |||
| 0x7b, bstr(GRP_ADDR), GRP_PORT], | | | 0x7b, bstr(GRP_ADDR), GRP_PORT], | | |||
| ph_req : bstr(0x01 | OPT), | | | ph_req : bstr(0x01 | OPT), | | |||
| last_notif : bstr(0x45 | OPT | 0xff | PAYLOAD) | | | last_notif : bstr(0x45 | OPT | 0xff | PAYLOAD) | | |||
| } | | | } | | |||
| | | | | | |||
| | | ||||
| | | ||||
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 | | |||
| Max-Age: 0 | | ||||
| <Other options> | | | <Other options> | | |||
| Payload: { | | | Payload: { | | |||
| tp_info : [1, bstr(SRV_ADDR), SRV_PORT, | | | tp_info : [1, bstr(SRV_ADDR), SRV_PORT, | | |||
| 0x7b, bstr(GRP_ADDR), GRP_PORT], | | | 0x7b, bstr(GRP_ADDR), GRP_PORT], | | |||
| ph_req : bstr(0x01 | OPT), | | | ph_req : bstr(0x01 | OPT), | | |||
| last_notif : bstr(0x45 | OPT | 0xff | PAYLOAD) | | | last_notif : bstr(0x45 | OPT | 0xff | PAYLOAD) | | |||
| } | | | } | | |||
| | | | | | |||
| (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" | | |||
| | | | | | |||
Figure 5: Example of group observation | Figure 5: Example of group observation | |||
6. Rough Counting of Clients in the Group Observation | 6. Rough Counting of Clients in the Group Observation | |||
To allow the server to keep an estimate of interested clients without | 6.1. Multicast-Response-Feedback-Divider Option | |||
creating undue traffic on the network, a new CoAP option is | ||||
introduced, which SHOULD be supported by clients that listen to | In order to allow the server to keep an estimate of interested | |||
multicast responses. | clients without creating undue traffic on the network, a new CoAP | |||
option is introduced, which SHOULD be supported by clients that | ||||
listen to multicast responses. | ||||
The option is called Multicast-Response-Feedback-Divider. As | The option is called Multicast-Response-Feedback-Divider. As | |||
summarized in Figure 6, the option is not critical but proxy-unsafe, | summarized in Figure 6, the option is not Critical, not Safe-to- | |||
and integer valued. | Forward, and integer valued. Since the option is not Safe-to- | |||
Forward, the column "N" indicates a dash for "not applicable". | ||||
+-----+---+---+---+---+---------------------+--------+------+---------+ | +-----+---+---+---+---+---------------------+--------+------+---------+ | |||
| 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 6: 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]. | |||
6.1. Processing on the Client Side | 6.2. 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 | |||
should wait a random fraction of the Leisure time (see Section 8.2 of | should wait a random fraction of the Leisure time (see Section 8.2 of | |||
[RFC7252]), and then registers a regular unicast observation on the | [RFC7252]), and then registers a regular unicast observation on the | |||
same target resource. | same target resource. | |||
To this end, the client essentially follows the steps that got it | To this end, the client essentially follows the steps that got it | |||
originally subscribed to group notifications for the target resource. | originally subscribed to group notifications for the target resource. | |||
In particular, the client sends an observation request to the server, | In particular, the client sends an observation request to the server, | |||
i.e. a GET request with an Observe option set to 0 (register). The | i.e., a GET request with an Observe option set to 0 (register). The | |||
request MUST be addressed to the same target resource, and MUST have | request MUST be addressed to the same target resource, and MUST have | |||
the same destination IP address and port number used for the original | the same destination IP address and port number used for the original | |||
registration request, regardless the source IP address and port | registration request, regardless the source IP address and port | |||
number of the received multicast notification. | number of the received multicast notification. | |||
Since the observation registration is only done for its side effect | Since the observation registration is only done for its side effect | |||
of showing as an attempted observation at the server, the client MUST | of showing as an attempted observation at the server, the client MUST | |||
send the unicast request in a non confirmable way, and with the | send the unicast request in a non confirmable way, and with the | |||
maximum No-Response setting [RFC7967]. In the request, the client | maximum No-Response setting [RFC7967]. In the request, the client | |||
MUST include a Multicast-Response-Feedback-Divider option, whose | MUST include a Multicast-Response-Feedback-Divider option, whose | |||
value MUST be empty (Option Length = 0). The client does not need to | value MUST be empty (Option Length = 0). The client does not need to | |||
wait for responses, and can keep processing further notifications on | wait for responses, and can keep processing further notifications on | |||
the same token. | the same Token. | |||
The client MUST ignore the Multicast-Response-Feedback-Divider | The client MUST ignore the Multicast-Response-Feedback-Divider | |||
option, if the multicast notification is retrieved from the | option, if the multicast notification is retrieved from the | |||
'last_notif' parameter of an informative response (see Section 2.2). | 'last_notif' parameter of an informative response (see Section 2.2). | |||
A client includes the Multicast-Response-Feedback-Divider option only | A client includes the Multicast-Response-Feedback-Divider option only | |||
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 and Appendix B.2 provide a description in pseudo-code of | |||
above performed by the client. | the operations above performed by the client. | |||
6.2. Processing on the Server Side | 6.3. 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. | |||
6.2.1. Request for Feedback | 6.3.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: | |||
* L is computed as L = ceil(log2(N / M)). | * L is computed as L = ceil(log2(N / M)). | |||
* N is the current value of the observer counter, possibly rounded | * N is the current value of the observer counter, possibly rounded | |||
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. | |||
6.2.2. Collection of Feedback | 6.3.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, | |||
which may be hard to know or estimate for the server. | which may be hard to know or estimate for the server. | |||
If this information is not known to the server, it is recommended to | If this information is not known to the server, it is recommended to | |||
define MAX_CONFIRMATION_WAIT as follows. | define MAX_CONFIRMATION_WAIT as follows. | |||
MAX_CONFIRMATION_WAIT = MAX_RTT + MAX_CLIENT_REQUEST_DELAY | MAX_CONFIRMATION_WAIT = MAX_RTT + MAX_CLIENT_REQUEST_DELAY | |||
where MAX_RTT is as defined in Section 4.8.2 of [RFC7252] and has | where MAX_RTT is as defined in Section 4.8.2 of [RFC7252] and has | |||
default value 202 seconds, while MAX_CLIENT_REQUEST_DELAY is | default value 202 seconds, while MAX_CLIENT_REQUEST_DELAY is | |||
equivalent to MAX_SERVER_RESPONSE_DELAY defined in Section 2.3.1 of | equivalent to MAX_SERVER_RESPONSE_DELAY defined in Section 3.1.5 of | |||
[I-D.ietf-core-groupcomm-bis] and has default value 250 seconds. In | [I-D.ietf-core-groupcomm-bis] and has default value 250 seconds. In | |||
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. | |||
6.2.3. Processing of Feedback | 6.3.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 E = 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 (E/N) and (N/E). | 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. | |||
skipping to change at page 23, line 27 ¶ | skipping to change at page 23, line 42 ¶ | |||
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 | |||
of 18 actually active clients, 5 send a re-registration request based | of 18 actually active clients, 5 send a re-registration request based | |||
on their random draw, of which one request gets lost, thus leaving 4 | on their random draw, of which one request gets lost, thus leaving 4 | |||
re-registration requests received by the server. Also, no new | re-registration requests received by the server. Also, no new | |||
clients have been added to the group observation during this time, | clients have been added to the group observation during this time, | |||
i.e. COUNT' is equal to COUNT. As a consequence, assuming that a | i.e., COUNT' is equal to COUNT. As a consequence, assuming that a | |||
dampener value D = 1 is used, the server computes the new estimated | dampener value D = 1 is used, the server computes the new estimated | |||
count value as 32 + (16 - 32) = 16, and keeps the group observation | count value as 32 + (16 - 32) = 16, and keeps the group observation | |||
active. | active. | |||
To produce a most accurate updated counter, a server can include a | To produce a most accurate updated counter, a server can include a | |||
Multicast-Response-Feedback-Divider option with value Q = 0 in its | Multicast-Response-Feedback-Divider option with value Q = 0 in its | |||
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. | |||
skipping to change at page 24, line 15 ¶ | skipping to change at page 24, line 28 ¶ | |||
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 7.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. | server and/or with 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 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. | 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). | |||
7.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 11. | CBOR labels are defined in Section 11. | |||
* 'join_uri', with value the URI for joining the OSCORE group at the | * '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 | |||
skipping to change at page 25, line 12 ¶ | skipping to change at page 25, line 31 ¶ | |||
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. | |||
* 'sec_gp', with value the name of the OSCORE group, encoded as a | * 'sec_gp', with value the name of the OSCORE group, encoded as a | |||
CBOR text string. | CBOR text string. | |||
* Optionally, 'as_uri', with value the URI of the Authorization | * Optionally, 'as_uri', with value the URI of the Authorization | |||
Server associated to the Group Manager for the OSCORE group, | Server associated to the Group Manager for the OSCORE group, | |||
encoded as a CBOR text string. | encoded as a CBOR text string. | |||
* Optionally, 'cs_alg', with value the COSE algorithm | * Optionally, 'hkdf', with value the HKDF Algorithm used in the | |||
[I-D.ietf-cose-rfc8152bis-algs] used to countersign messages in | OSCORE group, encoded as a CBOR text string or integer. The value | |||
the OSCORE group, encoded as a CBOR text string or integer. The | is taken from the 'Value' column of the "COSE Algorithms" registry | |||
value is taken from the 'Value' column of the "COSE Algorithms" | [COSE.Algorithms]. | |||
registry [COSE.Algorithms]. | ||||
* Optionally, 'cs_alg_crv', with value the elliptic curve (if | * Optionally, 'pub_key_enc', with value the encoding of the public | |||
applicable) for the COSE algorithm [I-D.ietf-cose-rfc8152bis-algs] | keys used in the OSCORE group, encoded as a CBOR integer. The | |||
used to countersign messages in the OSCORE group, encoded as a | value is taken from the 'Label' column of the "COSE Header | |||
CBOR text string or integer. The value is taken from the 'Value' | Parameters" Registry [COSE.Header.Parameters]. Consistently with | |||
column of the "COSE Elliptic Curve" registry | Section 2.3 of [I-D.ietf-core-oscore-groupcomm], acceptable values | |||
[COSE.Elliptic.Curves]. | denote an encoding that MUST explicitly provide the full set of | |||
information related to the public key algorithm, including, e.g., | ||||
the used elliptic curve (when applicable). | ||||
* Optionally, 'cs_key_kty', with value the COSE key type | At the time of writing this specification, acceptable public key | |||
[I-D.ietf-cose-rfc8152bis-struct] of countersignature keys used to | encodings are CWTs [RFC8392], unprotected CWT claim sets | |||
countersign messages in the OSCORE group, encoded as a CBOR text | [I-D.ietf-rats-uccs], X.509 certificates [RFC7925] and C509 | |||
string or an integer. The value is taken from the 'Value' column | certificates [I-D.ietf-cose-cbor-encoded-cert]. Further encodings | |||
of the "COSE Key Types" registry [COSE.Key.Types]. | may be available in the future, and would be acceptable to use as | |||
long as they comply with the criteria defined above. | ||||
* Optionally, 'cs_key_crv', with value the elliptic curve (if | [ As to CWTs and unprotected CWT claim sets, there is a pending | |||
applicable) of countersignature keys used to countersign messages | registration requested by draft-ietf-lake-edhoc. ] | |||
in the OSCORE group, encoded as a CBOR text string or integer. | ||||
The value is taken from the 'Value' column of the "COSE Elliptic | ||||
Curve" registry [COSE.Elliptic.Curves]. | ||||
* Optionally, 'cs_kenc', with value the encoding of the public keys | [ As to C509 certificates, there is a pending registration | |||
used in the OSCORE group, encoded as a CBOR integer. The value is | requested by draft-ietf-cose-cbor-encoded-cert. ] | |||
taken from the 'Confirmation Key' column of the "CWT Confirmation | ||||
Method" registry defined in [RFC8747]. Future specifications may | ||||
define additional values for this parameter. | ||||
* Optionally, 'alg', with value the COSE AEAD algorithm | * Optionally, 'sign_enc_alg', with value the Signature Encryption | |||
[I-D.ietf-cose-rfc8152bis-algs], encoded as a CBOR text string or | Algorithm used in the OSCORE group to encrypt messages protected | |||
integer. The value is taken from the 'Value' column of the "COSE | with the group mode, encoded as a CBOR text string or integer. | |||
The value is taken from the 'Value' column of the "COSE | ||||
Algorithms" registry [COSE.Algorithms]. | Algorithms" registry [COSE.Algorithms]. | |||
* Optionally, 'hkdf', with value the COSE HKDF algorithm | * Optionally, 'sign_alg', with value the Signature Algorithm used to | |||
[I-D.ietf-cose-rfc8152bis-algs], encoded as a CBOR text string or | sign messages in the OSCORE group, encoded as a CBOR text string | |||
integer. The value is taken from the 'Value' column of the "COSE | or integer. The value is taken from the 'Value' column of the | |||
Algorithms" registry [COSE.Algorithms]. | "COSE Algorithms" registry [COSE.Algorithms]. | |||
The values of 'cs_alg', 'cs_alg_crv', 'cs_key_kty', 'cs_key_crv' and | * Optionally, 'sign_params', encoded as a CBOR array and including | |||
'cs_key_kenc' provide an early knowledge of the format and encoding | the following two elements: | |||
of public keys used in the OSCORE group. Thus, the client does not | ||||
need to ask the Group Manager for this information as a preliminary | ||||
step before the (ACE) join process, or to perform a trial-and-error | ||||
exchange with the Group Manager upon joining the group. Hence, the | ||||
client is able to provide the Group Manager with its own public key | ||||
in the correct expected format and encoding, at the very first step | ||||
of the (ACE) join process. | ||||
The values of 'cs_alg', 'alg' and 'hkdf' provide an early knowledge | - 'sign_alg_capab': a CBOR array, with the same format and value | |||
of the algorithms used in the OSCORE group. Thus, the client is able | of the COSE capabilities array for the algorithm indicated in | |||
to decide whether to actually proceed with the (ACE) join process, | 'sign_alg', as specified for that algorithm in the | |||
depending on its support for the indicated algorithms. | 'Capabilities' column of the "COSE Algorithms" Registry | |||
[COSE.Algorithms]. | ||||
- 'sign_key_type_capab': a CBOR array, with the same format and | ||||
value of the COSE capabilities array for the COSE key type of | ||||
the keys used with the algorithm indicated in 'sign_alg', as | ||||
specified for that key type in the 'Capabilities' column of the | ||||
"COSE Key Types" Registry [COSE.Key.Types]. | ||||
The values of 'sign_alg', 'sign_params' and 'pub_key_enc' provide an | ||||
early knowledge of the format and encoding of public keys used in the | ||||
OSCORE group. Thus, the client does not need to ask the Group | ||||
Manager for this information as a preliminary step before the (ACE) | ||||
join process, or to perform a trial-and-error exchange with the Group | ||||
Manager upon joining the group. Hence, the client is able to provide | ||||
the Group Manager with its own public key in the correct expected | ||||
format and encoding, at the very first step of the (ACE) join | ||||
process. | ||||
The values of 'hkdf', 'sign_enc_alg' and 'sign_alg' provide an early | ||||
knowledge of the algorithms used in the OSCORE group. Thus, the | ||||
client is able to decide whether to actually proceed with the (ACE) | ||||
join process, depending on its support for the indicated algorithms. | ||||
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. | |||
skipping to change at page 26, line 51 ¶ | skipping to change at page 27, line 36 ¶ | |||
following differences. | following differences. | |||
7.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: | |||
* As 'kid', the Sender ID of the server in the OSCORE group. | * As 'kid', the Sender ID of the server in the OSCORE group. | |||
* As 'piv', the previously consumed Sender Sequence Number value SN | * 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). | |||
7.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 7.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 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 7.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 7.1). | OSCORE group to join, as additional parameters (see Section 7.1). | |||
7.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 | sign the multicast notification (see Section 4.3 of | |||
of [I-D.ietf-core-oscore-groupcomm]). | [I-D.ietf-core-oscore-groupcomm]). | |||
* The 'request_kid' is the 'kid' value in the OSCORE option of the | * The 'request_kid' is the 'kid' value in the OSCORE option of the | |||
phantom registration request, i.e. the Sender ID of the server. | phantom registration request, i.e., the Sender ID of the server. | |||
* The 'request_piv' is the 'piv' value in the OSCORE option of the | * The 'request_piv' is the 'piv' value in the OSCORE option of the | |||
phantom registration request, i.e. the consumed Sender Sequence | phantom registration request, i.e., the consumed Sender Sequence | |||
Number SN of the server. | Number SN of the server. | |||
* The 'request_kid_context' is the 'kid context' value in the OSCORE | * 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. | |||
7.2.4. Cancellation | 7.2.4. Cancellation | |||
When canceling a group observation (see Section 2.5), the phantom | When canceling a group observation (see Section 2.5), the multicast | |||
cancellation request MUST be secured, by using Group OSCORE. In | response with error code 5.03 (Service Unavailable) is also protected | |||
particular, the group mode of Group OSCORE defined in Section 8 of | ||||
[I-D.ietf-core-oscore-groupcomm] MUST be used. | ||||
Like defined in Section 7.2.1 for the phantom registration request, | ||||
the server protects the phantom cancellation request as per | ||||
Section 8.1 of [I-D.ietf-core-oscore-groupcomm], by using its Sender | ||||
Context and consuming its current Sender Sequence number in the | ||||
OSCORE group, from its Sender Context. The following, corresponding | ||||
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]. The server MUST use its own Sender | |||
Sequence Number as Partial IV to protect the error response, and | ||||
Note that, differently from the multicast notifications, this | include it as Partial IV in the OSCORE option of the response. | |||
multicast error response will be the only one securely paired with | ||||
the phantom cancellation request. | ||||
7.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. | |||
7.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 | |||
skipping to change at page 29, line 42 ¶ | skipping to change at page 30, line 26 ¶ | |||
succeed, or to step 6 otherwise. | succeed, or to step 6 otherwise. | |||
7.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 7.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 | For both decryption and signature verification, the client MUST set | |||
and 4.3.2 of [I-D.ietf-core-oscore-groupcomm] as follows. The | the 'external_aad' defined in Section 4.3 of | |||
particular way to achieve this is implementation specific. | [I-D.ietf-core-oscore-groupcomm] as follows. The particular way to | |||
achieve this is implementation specific. | ||||
* 'request_kid' takes the value of the 'kid' field from the OSCORE | * 'request_kid' takes the value of the 'kid' field from the OSCORE | |||
option of the phantom registration request (see Section 7.3.1). | option of the phantom registration request (see Section 7.3.1). | |||
* 'request_piv' takes the value of the 'piv' field from the OSCORE | * 'request_piv' takes the value of the 'piv' field from the OSCORE | |||
option of the phantom registration request (see Section 7.3.1). | option of the phantom registration request (see Section 7.3.1). | |||
* 'request_kid_context' takes the value of the 'kid context' field | * '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 7.3.1). | Section 7.3.1). | |||
skipping to change at page 31, line 15 ¶ | skipping to change at page 32, line 5 ¶ | |||
* 'OPT' denotes a sequence of CoAP options. This refers to the | * 'OPT' denotes a sequence of CoAP options. This refers to the | |||
phantom registration request encoded by the 'ph_req' parameter, or | phantom registration request encoded by the 'ph_req' parameter, or | |||
to the corresponding latest multicast notification encoded by the | to the corresponding latest multicast notification encoded by the | |||
'last_notif' parameter. | 'last_notif' parameter. | |||
* 'PAYLOAD' denotes an encrypted CoAP payload. This refers to the | * 'PAYLOAD' denotes an encrypted CoAP payload. This refers to the | |||
phantom registration request encoded by the 'ph_req' parameter, or | phantom registration request encoded by the 'ph_req' parameter, or | |||
to the corresponding latest multicast notification encoded by the | to the corresponding latest multicast notification encoded by the | |||
'last_notif' parameter. | 'last_notif' parameter. | |||
* 'SIGN' denotes the counter signature appended to an encrypted CoAP | * 'SIGN' denotes the signature appended to an encrypted CoAP | |||
payload. This refers to the phantom registration request encoded | payload. This refers to the phantom registration request encoded | |||
by the 'ph_req' parameter, or to the corresponding latest | by the 'ph_req' parameter, or to the corresponding latest | |||
multicast notification encoded by the 'last_notif' parameter. | multicast notification encoded by the 'last_notif' parameter. | |||
C_1 ------------ [ Unicast w/ OSCORE ] ------------------> S /r | C_1 ------------ [ Unicast w/ OSCORE ] ------------------> S /r | |||
| 0.05 (FETCH) | | | 0.05 (FETCH) | | |||
| Token: 0x4a | | | Token: 0x4a | | |||
| OSCORE: {kid: 1 ; piv: 101 ; ...} | | | OSCORE: {kid: 1; piv: 101; ...} | | |||
| <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 .) | | |||
| | | | | | |||
skipping to change at page 31, line 34 ¶ | skipping to change at page 32, line 24 ¶ | |||
| <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> | | |||
| 0xff | | | 0xff | | |||
| Encrypted_payload { | | | Encrypted_payload { | | |||
| 0x01 (GET), | | | 0x01 (GET), | | |||
| Observe: 0 (Register), | | | Observe: 0 (Register), | | |||
| <Other class E options> | | | <Other class E options> | | |||
| } | | | } | | |||
| <Counter signature> | | | <Signature> | | |||
| | | | | | |||
| | | | | | |||
| (S steps SN_5 in the Group OSCORE Sec. Ctx : SN_5 <== 502) | | | (S steps SN_5 in the Group OSCORE Sec. Ctx : SN_5 <== 502) | | |||
| | | | | | |||
| (S creates a group observation of /r .) | | | (S creates a group observation of /r .) | | |||
| | | | | | |||
| (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 w/ OSCORE ] ---------------- S | C_1 <--------------- [ Unicast w/ OSCORE ] ---------------- S | |||
| 2.05 (Content) | | | 2.05 (Content) | | |||
| Token: 0x4a | | | Token: 0x4a | | |||
| OSCORE: {piv: 301; ...} | | | OSCORE: {piv: 301; ...} | | |||
| Max-Age: 0 | | ||||
| <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, | | | tp_info : [1, bstr(SRV_ADDR), SRV_PORT, | | |||
| 0x7b, bstr(GRP_ADDR), GRP_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(0x45 | OPT | 0xff | PAYLOAD | SIGN), | | | last_notif : bstr(0x45 | OPT | 0xff | PAYLOAD | SIGN), | | |||
| 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; ...} | | |||
| <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 increments the observer counter | | | (S increments the observer counter | | |||
| for the group observation of /r .) | | | for the group observation of /r .) | | |||
| | | | | | |||
C_2 <--------------- [ Unicast w/ OSCORE ] ---------------- S | C_2 <--------------- [ Unicast w/ OSCORE ] ---------------- S | |||
| 2.05 (Content) | | | 2.05 (Content) | | |||
| Token: 0x01 | | | Token: 0x01 | | |||
| OSCORE: {piv: 401; ...} | | | OSCORE: {piv: 401; ...} | | |||
| Max-Age: 0 | | ||||
| <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, | | | tp_info : [1, bstr(SRV_ADDR), SRV_PORT, | | |||
| 0x7b, bstr(GRP_ADDR), GRP_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(0x45 | OPT | 0xff | PAYLOAD | SIGN), | | | last_notif : bstr(0x45 | OPT | 0xff | PAYLOAD | SIGN), | | |||
| 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 | |||
C_2 (Destination address/port: GRP_ADDR/GRP_PORT) | | C_2 (Destination address/port: GRP_ADDR/GRP_PORT) | | |||
| 2.05 (Content) | | | 2.05 (Content) | | |||
| Token: 0x7b | | | Token: 0x7b | | |||
| 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 { | | | Encrypted_payload { | | |||
| 2.05 (Content), | | | 2.05 (Content), | | |||
| Observe: 11, | | | Observe: [empty], | | |||
| 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> | | | <Signature> | | |||
| | | | | | |||
Figure 7: Example of group observation with Group OSCORE | 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 sign 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. | |||
9. Intermediaries | 9. Intermediaries | |||
skipping to change at page 36, line 30 ¶ | skipping to change at page 37, line 17 ¶ | |||
performs a new observe registration request, by transmitting the re- | performs a new observe registration request, by transmitting the re- | |||
built phantom request as intended to reach the proxy adjacent to the | built phantom request as intended to reach the proxy adjacent to the | |||
origin server. In particular, the client includes the new Listen-To- | origin server. In particular, the client includes the new Listen-To- | |||
Multicast-Responses CoAP option defined in Section 10.1, to provide | Multicast-Responses CoAP option defined in Section 10.1, to provide | |||
that proxy with the transport-specific information required for | that proxy with the transport-specific information required for | |||
receiving 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 10.2. | in Section 10.2. | |||
10.1. The Listen-To-Multicast-Responses Option | 10.1. Listen-To-Multicast-Responses Option | |||
To allow the proxy to listen to the multicast notifications sent by | In order to allow the proxy to listen to the multicast notifications | |||
the server, a new CoAP option is introduced. This option MUST be | sent by the server, a new CoAP option is introduced. This option | |||
supported by clients interested to take part in group observations | MUST be supported by clients interested to take part in group | |||
through intermediaries, and by proxies that collect multicast | observations through intermediaries, and by proxies that collect | |||
notifications and forward them back to the observer clients. | multicast 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 8, the option is critical | only for requests. As summarized in Figure 8, the option is critical | |||
and proxy-unsafe. | and not Safe-to-Forward. Since the option is not Safe-to-Forward, | |||
the column "N" indicates a dash for "not applicable". | ||||
+-----+---+---+---+---+-------------------+--------+--------+---------+ | +-----+---+---+---+---+-------------------+--------+--------+---------+ | |||
| 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 | |||
skipping to change at page 37, line 45 ¶ | skipping to change at page 38, line 35 ¶ | |||
* The client builds a ticket request (see Appendix B of | * 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 | - 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 | no reason for this Token to be the same as the phantom | |||
request's. | request's. | |||
- The Code field, the outer CoAP options and the encrypted | - The outer Code field, the outer CoAP options and the encrypted | |||
payload (containing inner options, AEAD tag etc.) are the same | payload with AEAD tag (protecting the inner Code, the inner | |||
of the phantom request used for the group observation. That | CoAP options and the possible plain CoAP payload) concatenated | |||
is, they are as specified in the 'ph_req' parameter of the | with the signature are the same of the phantom request used for | |||
received informative response. | the group observation. That is, they are as specified in the | |||
'ph_req' parameter of the 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. | 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. | |||
Note that, except for transport-specific information such as | Note that, except for transport-specific information such as | |||
the Token and Message ID values, every different client | the Token and Message ID values, every different client | |||
participating to the same group observation (hence rebuilding | participating to the same group observation (hence rebuilding | |||
the same phantom request) will build the same ticket request. | the same phantom request) will build the same ticket request. | |||
Note also that, identically to the phantom request, the ticket | Note also that, identically to the phantom request, the ticket | |||
request is still protected with Group OSCORE, i.e. it has the | request is still protected with Group OSCORE, i.e., it has the | |||
same OSCORE option, encrypted payload and counter signature. | same OSCORE option, encrypted payload and signature. | |||
Then, the client sends the ticket request to the next hop towards the | Then, the client sends the ticket request to the next hop towards the | |||
origin server. Every proxy in the chain forwards the ticket request | origin server. Every proxy in the chain forwards the ticket request | |||
to the next hop towards the origin server, until the last proxy in | to the next hop towards the origin server, until the last proxy in | |||
the chain is reached. This last proxy, adjacent to the origin | the chain is reached. This last proxy, adjacent to the origin | |||
server, proceeds as follows. | server, proceeds as follows. | |||
* The proxy MUST NOT further forward the ticket request to the | * The proxy MUST NOT further forward the ticket request to the | |||
origin server. | origin server. | |||
skipping to change at page 38, line 43 ¶ | skipping to change at page 39, line 34 ¶ | |||
from the ticket request. | from the ticket request. | |||
* The proxy removes the Listen-To-Multicast-Responses option from | * The proxy removes the Listen-To-Multicast-Responses option from | |||
the ticket request, and extracts the conveyed transport-specific | the ticket request, and extracts the conveyed transport-specific | |||
information. | information. | |||
* The proxy rebuilds the phantom request associated to the group | * The proxy rebuilds the phantom request associated to the group | |||
observation, by using the ticket request as directly providing the | observation, by using the ticket request as directly providing the | |||
required transport-independent information. This includes the | required transport-independent information. This includes the | |||
outer Code field, the outer CoAP options and the encrypted payload | outer Code field, the outer CoAP options and the encrypted payload | |||
concatenated with the counter signature. | with AEAD tag concatenated with the signature. | |||
* The proxy configures an observation of the target resource at the | * The proxy configures an observation of the target resource at the | |||
origin server, acting as a client directly taking part in the | origin server, acting as a client directly taking part in the | |||
group observation. To this end, the proxy uses the rebuilt | group observation. To this end, the proxy uses the rebuilt | |||
phantom request and the transport-specific information retrieved | phantom request and the transport-specific information retrieved | |||
from the Listen-To-Multicast-Responses Option. The particular way | from the Listen-To-Multicast-Responses Option. The particular way | |||
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 F. | An example is provided in Appendix F. | |||
11. Informative Response Parameters | 11. Informative Response Parameters | |||
This specification defines a number of fields used in the informative | This document 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 | | |||
+================+==========+===================+=============+ | +================+==========+===================+=============+ | |||
| tp_info | 1 | array | Section 2.2 | | | tp_info | 0 | array | Section 2.2 | | |||
+----------------+----------+-------------------+-------------+ | ||||
| ph_req | 2 | byte string | Section 2.2 | | ||||
+----------------+----------+-------------------+-------------+ | +----------------+----------+-------------------+-------------+ | |||
| last_notif | 3 | byte string | Section 2.2 | | | ph_req | 1 | byte string | Section 2.2 | | |||
+----------------+----------+-------------------+-------------+ | +----------------+----------+-------------------+-------------+ | |||
| join_uri | 4 | text string | Section 7.1 | | | last_notif | 2 | byte string | Section 2.2 | | |||
+----------------+----------+-------------------+-------------+ | +----------------+----------+-------------------+-------------+ | |||
| sec_gp | 5 | text string | Section 7.1 | | | join_uri | 3 | text string | Section 7.1 | | |||
+----------------+----------+-------------------+-------------+ | +----------------+----------+-------------------+-------------+ | |||
| as_uri | 6 | text string | Section 7.1 | | | sec_gp | 4 | text string | Section 7.1 | | |||
+----------------+----------+-------------------+-------------+ | +----------------+----------+-------------------+-------------+ | |||
| cs_alg | 7 | int / text string | Section 7.1 | | | as_uri | 5 | text string | Section 7.1 | | |||
+----------------+----------+-------------------+-------------+ | +----------------+----------+-------------------+-------------+ | |||
| cs_crv | 8 | int / text string | Section 7.1 | | | hkdf | 6 | int / text string | Section 7.1 | | |||
+----------------+----------+-------------------+-------------+ | +----------------+----------+-------------------+-------------+ | |||
| cs_kty | 9 | int / text string | Section 7.1 | | | pub_key_enc | 7 | int | Section 7.1 | | |||
+----------------+----------+-------------------+-------------+ | +----------------+----------+-------------------+-------------+ | |||
| cs_kenc | 10 | int | Section 7.1 | | | sign_enc_alg | 8 | int / text string | Section 7.1 | | |||
+----------------+----------+-------------------+-------------+ | +----------------+----------+-------------------+-------------+ | |||
| alg | 11 | int / text string | Section 7.1 | | | sign_alg | 9 | int / text string | Section 7.1 | | |||
+----------------+----------+-------------------+-------------+ | +----------------+----------+-------------------+-------------+ | |||
| hkdf | 12 | int / text string | Section 7.1 | | | sign_params | 10 | array | Section 7.1 | | |||
+----------------+----------+-------------------+-------------+ | +----------------+----------+-------------------+-------------+ | |||
| gp_material | 13 | map | Appendix C | | | gp_material | 11 | map | Appendix C | | |||
+----------------+----------+-------------------+-------------+ | +----------------+----------+-------------------+-------------+ | |||
| srv_pub_key | 14 | byte string | Appendix C | | | srv_pub_key | 12 | byte string | Appendix C | | |||
+----------------+----------+-------------------+-------------+ | +----------------+----------+-------------------+-------------+ | |||
| srv_identifier | 15 | byte string | Appendix C | | | srv_identifier | 13 | byte string | Appendix C | | |||
+----------------+----------+-------------------+-------------+ | +----------------+----------+-------------------+-------------+ | |||
| exp | 16 | uint | Appendix C | | | exp | 14 | uint | Appendix C | | |||
+----------------+----------+-------------------+-------------+ | +----------------+----------+-------------------+-------------+ | |||
Table 1 | Table 1 | |||
12. Transport Protocol Information | 12. Transport Protocol Information | |||
This specification defines some values of transport protocol | This document defines some values of transport protocol identifiers | |||
identifiers to use within the 'tp_info' parameter of the informative | to use within the 'tp_info' parameter of the informative response | |||
response message defined in Section 2.2 of this specification. | message defined in Section 2.2. | |||
According to the encoding specified in Section 2.2.1, these values | According to the encoding specified in Section 2.2.1, these values | |||
are used for the 'tp_id' element of 'srv_addr', under the 'tp_info' | are used for the 'tp_id' element of 'srv_addr', under the 'tp_info' | |||
parameter. | parameter. | |||
The table below summarizes them, specifies the integer value to use | The table below summarizes them, specifies the integer value to use | |||
instead of the full descriptive name, and provides the corresponding | instead of the full descriptive name, and provides the corresponding | |||
full set of information elements to include in the 'tp_info' | full set of information elements to include in the 'tp_info' | |||
parameter. | parameter. | |||
skipping to change at page 41, line 30 ¶ | skipping to change at page 41, line 40 ¶ | |||
+-----------+-------------+-------+----------+-----------+-----------+ | +-----------+-------------+-------+----------+-----------+-----------+ | |||
Figure 9: Transport protocol information | Figure 9: Transport protocol information | |||
13. Security Considerations | 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 as per | |||
original registration requests and related unicast (notification) | Section 7, the following applies. | |||
responses MUST also be secured, including and especially the | ||||
informative responses from the server. This prevents on-path active | * The original registration requests and related unicast | |||
adversaries from altering the conveyed IP multicast address and | (notification) responses MUST also be secured, including and | |||
serialized phantom registration request. Thus, it ensures secure | especially the informative responses from the server. This | |||
binding between every multicast notification for a same observed | prevents on-path active adversaries from altering the conveyed IP | |||
resource and the phantom registration request that started the group | multicast address and serialized phantom registration request. | |||
observation of that resource. | Thus, it ensures secure binding between every multicast | |||
notification for a same observed resource and the phantom | ||||
registration request that started the group observation of that | ||||
resource. | ||||
* A re-registration request, possibly including the Multicast- | ||||
Response-Feedback-Divider option to support the rough counting of | ||||
clients (see Section 6), MUST also be secured. | ||||
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. | |||
13.1. Listen-To-Multicast-Responses Option | 13.1. Listen-To-Multicast-Responses Option | |||
The CoAP option Listen-To-Multicast-Responses defined in Section 10.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]. | |||
skipping to change at page 42, line 36 ¶ | skipping to change at page 43, line 7 ¶ | |||
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. | |||
14. IANA Considerations | 14. IANA Considerations | |||
This document has the following actions for IANA. | This document has the following actions for IANA. | |||
14.1. Media Type Registrations | 14.1. Media Type Registrations | |||
This specification registers the media type 'application/informative- | This document 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, when carrying parameters encoded in CBOR. This | |||
in CBOR. This registration follows the procedures specified in | registration follows the procedures specified in [RFC6838]. | |||
[RFC6838]. | ||||
* Type name: application | * Type name: application | |||
* Subtype name: informative-response+cbor | * Subtype name: informative-response+cbor | |||
* Required parameters: N/A | * Required parameters: N/A | |||
* Optional parameters: N/A | * Optional parameters: N/A | |||
* Encoding considerations: Must be encoded as a CBOR map containing | * Encoding considerations: Must be encoded as a CBOR map containing | |||
skipping to change at page 43, line 31 ¶ | skipping to change at page 43, line 49 ¶ | |||
* Intended usage: COMMON | * Intended usage: COMMON | |||
* Restrictions on usage: None | * Restrictions on usage: None | |||
* Author: Marco Tiloca marco.tiloca@ri.se | * Author: Marco Tiloca marco.tiloca@ri.se | |||
(mailto:marco.tiloca@ri.se) | (mailto:marco.tiloca@ri.se) | |||
* Change controller: IESG | * Change controller: IESG | |||
* Provisional registration? No | ||||
14.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] | |||
14.3. Informative Response Parameters Registry | 14.3. Informative Response Parameters Registry | |||
This specification establishes the "Informative Response Parameters" | This document establishes the "Informative Response Parameters" IANA | |||
IANA registry. The registry has been created to use the "Expert | registry. The registry has been created to use the "Expert Review | |||
Review Required" registration procedure [RFC8126]. Expert review | Required" registration procedure [RFC8126]. Expert review guidelines | |||
guidelines are provided in Section 14.6. | are provided in Section 14.6. | |||
The columns of this registry are: | The columns of this registry are: | |||
* Name: This is a descriptive name that enables easier reference to | * 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. | |||
* CBOR Key: This is the value used as CBOR key of the item. These | * 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. | |||
skipping to change at page 44, line 26 ¶ | skipping to change at page 45, line 7 ¶ | |||
* Reference: This contains a pointer to the public specification for | * 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 11. The "Reference" column for all of these entries refers | |||
to sections of this document. | to sections of this document. | |||
14.4. CoAP Transport Information Registry | 14.4. CoAP Transport Information Registry | |||
This specification defines the subregistry "CoAP Transport | This document defines the subregistry "CoAP Transport Information" | |||
Information" within the "CoRE Parameters" registry. The registry has | within the "CoRE Parameters" registry. The registry has been created | |||
been created to use the "Expert Review Required" registration | to use the "Expert Review Required" registration procedure [RFC8126]. | |||
procedure [RFC8126]. Expert review guidelines are provided in | Expert review guidelines are provided in Section 14.6. It should be | |||
Section 14.6. | noted that, in addition to the expert review, some portions of the | |||
Registry require a specification, potentially a Standards Track RFC, | ||||
to be supplied as well. | ||||
The columns of this registry are: | The columns of this registry are: | |||
* Transport Protocol: This is a descriptive name that enables easier | * Transport Protocol: This is a descriptive name that enables easier | |||
reference to the item. The name MUST be unique. It is not used | reference to the item. The name MUST be unique. It is not used | |||
in the encoding. | in the encoding. | |||
* Description: Text giving an overview of the transport protocol | * Description: Text giving an overview of the transport protocol | |||
referred by this item. | referred by this item. | |||
skipping to change at page 46, line 27 ¶ | skipping to change at page 47, line 10 ¶ | |||
15. References | 15. References | |||
15.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.Header.Parameters] | |||
IANA, "COSE Elliptic Curves", | IANA, "COSE Header Parameters", | |||
<https://www.iana.org/assignments/cose/ | <https://www.iana.org/assignments/cose/cose.xhtml#header- | |||
cose.xhtml#elliptic-curves>. | parameters>. | |||
[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-ace-key-groupcomm-oscore] | [I-D.ietf-ace-key-groupcomm-oscore] | |||
Tiloca, M., Park, J., and F. Palombini, "Key Management | Tiloca, M., Park, J., and F. Palombini, "Key Management | |||
for OSCORE Groups in ACE", Work in Progress, Internet- | for OSCORE Groups in ACE", Work in Progress, Internet- | |||
Draft, draft-ietf-ace-key-groupcomm-oscore-09, 2 November | Draft, draft-ietf-ace-key-groupcomm-oscore-11, 12 July | |||
2020, <http://www.ietf.org/internet-drafts/draft-ietf-ace- | 2021, <https://www.ietf.org/archive/id/draft-ietf-ace-key- | |||
key-groupcomm-oscore-09.txt>. | groupcomm-oscore-11.txt>. | |||
[I-D.ietf-ace-oscore-profile] | [I-D.ietf-ace-oscore-profile] | |||
Palombini, F., Seitz, L., Selander, G., and M. Gunnarsson, | Palombini, F., Seitz, L., Selander, G., and M. Gunnarsson, | |||
"OSCORE Profile of the Authentication and Authorization | "OSCORE Profile of the Authentication and Authorization | |||
for Constrained Environments Framework", Work in Progress, | for Constrained Environments Framework", Work in Progress, | |||
Internet-Draft, draft-ietf-ace-oscore-profile-15, 26 | Internet-Draft, draft-ietf-ace-oscore-profile-19, 6 May | |||
January 2021, <http://www.ietf.org/internet-drafts/draft- | 2021, <https://www.ietf.org/archive/id/draft-ietf-ace- | |||
ietf-ace-oscore-profile-15.txt>. | oscore-profile-19.txt>. | |||
[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)", Work in | for the Constrained Application Protocol (CoAP)", Work in | |||
Progress, Internet-Draft, draft-ietf-core-groupcomm-bis- | Progress, Internet-Draft, draft-ietf-core-groupcomm-bis- | |||
02, 2 November 2020, <http://www.ietf.org/internet-drafts/ | 04, 12 July 2021, <https://www.ietf.org/archive/id/draft- | |||
draft-ietf-core-groupcomm-bis-02.txt>. | ietf-core-groupcomm-bis-04.txt>. | |||
[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. P., | |||
"Group OSCORE - Secure Group Communication for CoAP", Work | and J. Park, "Group OSCORE - Secure Group Communication | |||
in Progress, Internet-Draft, draft-ietf-core-oscore- | for CoAP", Work in Progress, Internet-Draft, draft-ietf- | |||
groupcomm-10, 2 November 2020, <http://www.ietf.org/ | core-oscore-groupcomm-12, 12 July 2021, | |||
internet-drafts/draft-ietf-core-oscore-groupcomm-10.txt>. | <https://www.ietf.org/archive/id/draft-ietf-core-oscore- | |||
groupcomm-12.txt>. | ||||
[I-D.ietf-cose-rfc8152bis-algs] | ||||
Schaad, J., "CBOR Object Signing and Encryption (COSE): | ||||
Initial Algorithms", Work in Progress, Internet-Draft, | ||||
draft-ietf-cose-rfc8152bis-algs-12, 24 September 2020, | ||||
<http://www.ietf.org/internet-drafts/draft-ietf-cose- | ||||
rfc8152bis-algs-12.txt>. | ||||
[I-D.ietf-cose-rfc8152bis-struct] | ||||
Schaad, J., "CBOR Object Signing and Encryption (COSE): | ||||
Structures and Process", Work in Progress, Internet-Draft, | ||||
draft-ietf-cose-rfc8152bis-struct-14, 24 September 2020, | ||||
<http://www.ietf.org/internet-drafts/draft-ietf-cose- | ||||
rfc8152bis-struct-14.txt>. | ||||
[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 48, line 45 ¶ | skipping to change at page 49, line 18 ¶ | |||
<https://www.rfc-editor.org/info/rfc8613>. | <https://www.rfc-editor.org/info/rfc8613>. | |||
[RFC8949] Bormann, C. and P. Hoffman, "Concise Binary Object | [RFC8949] Bormann, C. and P. Hoffman, "Concise Binary Object | |||
Representation (CBOR)", STD 94, RFC 8949, | Representation (CBOR)", STD 94, RFC 8949, | |||
DOI 10.17487/RFC8949, December 2020, | DOI 10.17487/RFC8949, December 2020, | |||
<https://www.rfc-editor.org/info/rfc8949>. | <https://www.rfc-editor.org/info/rfc8949>. | |||
15.2. Informative References | 15.2. Informative References | |||
[I-D.amsuess-core-cachable-oscore] | [I-D.amsuess-core-cachable-oscore] | |||
Amsuess, C. and M. Tiloca, "Cachable OSCORE", Work in | Amsüss, C. and M. Tiloca, "Cacheable OSCORE", Work in | |||
Progress, Internet-Draft, draft-amsuess-core-cachable- | Progress, Internet-Draft, draft-amsuess-core-cachable- | |||
oscore-00, 13 July 2020, <http://www.ietf.org/internet- | oscore-01, 22 February 2021, | |||
drafts/draft-amsuess-core-cachable-oscore-00.txt>. | <https://www.ietf.org/archive/id/draft-amsuess-core- | |||
cachable-oscore-01.txt>. | ||||
[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)", Work in Progress, Internet-Draft, | Framework (ACE-OAuth)", Work in Progress, Internet-Draft, | |||
draft-ietf-ace-oauth-authz-36, 16 November 2020, | draft-ietf-ace-oauth-authz-43, 10 July 2021, | |||
<http://www.ietf.org/internet-drafts/draft-ietf-ace-oauth- | <https://www.ietf.org/archive/id/draft-ietf-ace-oauth- | |||
authz-36.txt>. | authz-43.txt>. | |||
[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)", Work in Progress, Internet-Draft, draft-ietf- | (CoAP)", Work in Progress, Internet-Draft, draft-ietf- | |||
core-coap-pubsub-09, 30 September 2019, | core-coap-pubsub-09, 30 September 2019, | |||
<http://www.ietf.org/internet-drafts/draft-ietf-core-coap- | <https://www.ietf.org/archive/id/draft-ietf-core-coap- | |||
pubsub-09.txt>. | pubsub-09.txt>. | |||
[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)", Work in Progress, Internet-Draft, draft-ietf- | (CoRAL)", Work in Progress, Internet-Draft, draft-ietf- | |||
core-coral-03, 9 March 2020, <http://www.ietf.org/ | core-coral-03, 9 March 2020, | |||
internet-drafts/draft-ietf-core-coral-03.txt>. | <https://www.ietf.org/archive/id/draft-ietf-core-coral- | |||
03.txt>. | ||||
[I-D.ietf-core-resource-directory] | [I-D.ietf-core-resource-directory] | |||
Amsuess, C., Shelby, Z., Koster, M., Bormann, C., and P. | Amsüss, C., Shelby, Z., Koster, M., Bormann, C., and P. V. | |||
Stok, "CoRE Resource Directory", Work in Progress, | D. Stok, "CoRE Resource Directory", Work in Progress, | |||
Internet-Draft, draft-ietf-core-resource-directory-26, 2 | Internet-Draft, draft-ietf-core-resource-directory-28, 7 | |||
November 2020, <http://www.ietf.org/internet-drafts/draft- | March 2021, <https://www.ietf.org/archive/id/draft-ietf- | |||
ietf-core-resource-directory-26.txt>. | core-resource-directory-28.txt>. | |||
[I-D.ietf-cose-cbor-encoded-cert] | ||||
Raza, S., Höglund, J., Selander, G., Mattsson, J. P., and | ||||
M. Furuhed, "CBOR Encoded X.509 Certificates (C509 | ||||
Certificates)", Work in Progress, Internet-Draft, draft- | ||||
ietf-cose-cbor-encoded-cert-01, 25 May 2021, | ||||
<https://www.ietf.org/archive/id/draft-ietf-cose-cbor- | ||||
encoded-cert-01.txt>. | ||||
[I-D.ietf-rats-uccs] | ||||
Birkholz, H., O'Donoghue, J., Cam-Winget, N., and C. | ||||
Bormann, "A CBOR Tag for Unprotected CWT Claims Sets", | ||||
Work in Progress, Internet-Draft, draft-ietf-rats-uccs-00, | ||||
19 May 2021, <https://www.ietf.org/archive/id/draft-ietf- | ||||
rats-uccs-00.txt>. | ||||
[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", Work in Progress, Internet-Draft, draft-ietf-tls- | 1.3", Work in Progress, Internet-Draft, draft-ietf-tls- | |||
dtls13-40, 20 January 2021, <http://www.ietf.org/internet- | dtls13-43, 30 April 2021, <https://www.ietf.org/internet- | |||
drafts/draft-ietf-tls-dtls13-40.txt>. | drafts/draft-ietf-tls-dtls13-43.txt>. | |||
[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. V. D. Stok, "Discovery of | |||
Groups with the CoRE Resource Directory", Work in | OSCORE Groups with the CoRE Resource Directory", Work in | |||
Progress, Internet-Draft, draft-tiloca-core-oscore- | Progress, Internet-Draft, draft-tiloca-core-oscore- | |||
discovery-07, 2 November 2020, <http://www.ietf.org/ | discovery-09, 12 July 2021, | |||
internet-drafts/draft-tiloca-core-oscore-discovery- | <https://www.ietf.org/archive/id/draft-tiloca-core-oscore- | |||
07.txt>. | discovery-09.txt>. | |||
[MOBICOM99] | [MOBICOM99] | |||
Ni, S.-Y., Tseng, Y.-C., Chen, Y.-S., and J.-P. Sheu, "The | Ni, S.-Y., Tseng, Y.-C., Chen, Y.-S., and J.-P. Sheu, "The | |||
Broadcast Storm Problem in a Mobile Ad Hoc Network", | Broadcast Storm Problem in a Mobile Ad Hoc Network", | |||
Proceedings of the 5th annual ACM/IEEE international | Proceedings of the 5th annual ACM/IEEE international | |||
conference on Mobile computing and networking , August | conference on Mobile computing and networking , August | |||
1999, <https://people.eecs.berkeley.edu/~culler/cs294- | 1999, <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 | |||
skipping to change at page 50, line 25 ¶ | skipping to change at page 51, line 13 ¶ | |||
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 | [RFC6690] Shelby, Z., "Constrained RESTful Environments (CoRE) Link | |||
Format", RFC 6690, DOI 10.17487/RFC6690, August 2012, | Format", RFC 6690, DOI 10.17487/RFC6690, August 2012, | |||
<https://www.rfc-editor.org/info/rfc6690>. | <https://www.rfc-editor.org/info/rfc6690>. | |||
[RFC7519] Jones, M., Bradley, J., and N. Sakimura, "JSON Web Token | [RFC7519] Jones, M., Bradley, J., and N. Sakimura, "JSON Web Token | |||
(JWT)", RFC 7519, DOI 10.17487/RFC7519, May 2015, | (JWT)", RFC 7519, DOI 10.17487/RFC7519, May 2015, | |||
<https://www.rfc-editor.org/info/rfc7519>. | <https://www.rfc-editor.org/info/rfc7519>. | |||
[RFC7925] Tschofenig, H., Ed. and T. Fossati, "Transport Layer | ||||
Security (TLS) / Datagram Transport Layer Security (DTLS) | ||||
Profiles for the Internet of Things", RFC 7925, | ||||
DOI 10.17487/RFC7925, July 2016, | ||||
<https://www.rfc-editor.org/info/rfc7925>. | ||||
[RFC8392] Jones, M., Wahlstroem, E., Erdtman, S., and H. Tschofenig, | ||||
"CBOR Web Token (CWT)", RFC 8392, DOI 10.17487/RFC8392, | ||||
May 2018, <https://www.rfc-editor.org/info/rfc8392>. | ||||
[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. | ||||
Tschofenig, "Proof-of-Possession Key Semantics for CBOR | ||||
Web Tokens (CWTs)", RFC 8747, DOI 10.17487/RFC8747, March | ||||
2020, <https://www.rfc-editor.org/info/rfc8747>. | ||||
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 | |||
different services, such as the following ones. | different services, such as the following ones. | |||
A.1. Topic Discovery in Publish-Subscribe Settings | A.1. Topic Discovery in Publish-Subscribe Settings | |||
In a Publish-Subscribe scenario ([I-D.ietf-core-coap-pubsub]), a | In a Publish-Subscribe scenario [I-D.ietf-core-coap-pubsub], a group | |||
group observation can be discovered along with topic metadata. For | observation can be discovered along with topic metadata. For | |||
instance, a discovery step can make the following metadata available. | instance, a discovery step can make the following metadata available. | |||
This example assumes a CoRAL namespace [I-D.ietf-core-coral], that | This example assumes a CoRAL namespace [I-D.ietf-core-coral], that | |||
contains properties analogous to those in the content-format | contains properties analogous to those in the content-format | |||
application/informative-response+cbor. | application/informative-response+cbor. | |||
Request: | Request: | |||
GET </ps/topics?rt=oic.r.temperature> | GET </ps/topics?rt=oic.r.temperature> | |||
Accept: CoRAL | Accept: CoRAL | |||
skipping to change at page 52, line 24 ¶ | skipping to change at page 53, line 24 ¶ | |||
{ | { | |||
'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..", | 'ph_req': h"0160..", | |||
'last_notif' : h"256105.." | 'last_notif' : h"256105.." | |||
} | } | |||
Figure 11: Group observation discovery with server introspection | Figure 11: 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 in 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 6. | 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 | |||
skipping to change at page 56, line 34 ¶ | skipping to change at page 57, line 34 ¶ | |||
Group_OSCORE_Input_Material object, which is defined in | Group_OSCORE_Input_Material object, which is defined in | |||
Section 6.4 of [I-D.ietf-ace-key-groupcomm-oscore] and extends the | Section 6.4 of [I-D.ietf-ace-key-groupcomm-oscore] and extends the | |||
OSCORE_Input_Material object encoded in CBOR as defined in | OSCORE_Input_Material object encoded in CBOR as defined in | |||
Section 3.2.1 of [I-D.ietf-ace-oscore-profile]. | Section 3.2.1 of [I-D.ietf-ace-oscore-profile]. | |||
In particular, the following elements of the | In particular, the following elements of the | |||
Group_OSCORE_Input_Material object are included, using the same | Group_OSCORE_Input_Material object are included, using the same | |||
CBOR labels from the OSCORE Security Context Parameters Registry, | CBOR labels from the OSCORE Security Context Parameters Registry, | |||
as in Section 6.4 of [I-D.ietf-ace-key-groupcomm-oscore]. | as in Section 6.4 of [I-D.ietf-ace-key-groupcomm-oscore]. | |||
- 'ms', 'contexId', 'cs_alg', 'cs_params', 'cs_key_params', | - 'ms', 'contexId', 'pub_key_enc', 'sign_enc_alg', 'sign_alg' and | |||
'cs_key_enc'. These elements MUST be included. | 'sign_params'. These elements MUST be included. | |||
- 'hkdf', 'alg', 'salt'. These elements MAY be included. | - 'hkdf' and 'salt'. These elements MAY be included. | |||
The following elements of the Group_OSCORE_Input_Material object | The 'group_senderId' element of the Group_OSCORE_Input_Material | |||
MUST NOT be included. | object MUST NOT be included. | |||
- 'group_senderId', 'ecdh_alg', 'ecdh_params', 'ecdh_key_params'. | If the optimization defined in this appendix is combined with the | |||
use of phantom requests as deterministic requests (see | ||||
Appendix D), the elements 'alg', 'ecdh_alg' and 'ecdh_params' of | ||||
the Group_OSCORE_Input_Material object MUST also be included. | ||||
Otherwise, they MUST NOT be included. | ||||
* 'srv_pub_key': this element is a CBOR byte string, which wraps the | * '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 | original binary representation of the server's public key used in | |||
group. If the public key of the server is encoded as a COSE_Key | the OSCORE group. In particular, the original binary | |||
(see the 'cs_key_enc' element of the 'gp_material' parameter), it | representation complies with the encoding specified by the | |||
includes 'kid' specifying the Sender ID that the server has in the | 'pub_key_enc' element of 'gp_material'. | |||
OSCORE group. | ||||
* 'srv_identifier': this element MUST be present only if | * 'srv_identifier': this element MUST be included and is encoded as | |||
'srv_pub_key' is also present and, at the same time, the used | a CBOR byte string, with value the Sender ID that the server has | |||
encoding for the public key of the server does not allow to | in the OSCORE group. | |||
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. | ||||
* 'exp': with value the expiration time of the keying material of | * 'exp': with value the expiration time of the keying material of | |||
the OSCORE group specified in the 'gp_material' parameter, encoded | the OSCORE group specified in the 'gp_material' parameter, encoded | |||
as a CBOR unsigned integer. This field contains a numeric value | as a CBOR unsigned integer. This field contains a numeric value | |||
representing the number of seconds from 1970-01-01T00:00:00Z UTC | representing the number of seconds from 1970-01-01T00:00:00Z UTC | |||
until the specified UTC date/time, ignoring leap seconds, | until the specified UTC date/time, ignoring leap seconds, | |||
analogous to what specified for NumericDate in Section 2 of | analogous to what specified for NumericDate in Section 2 of | |||
[RFC7519]. | [RFC7519]. | |||
Note that the informative response does not require to include an | ||||
explicit proof-of-possession (PoP) of the server's private key. | ||||
Although the server is also acting as Group Manager and a PoP | ||||
evidence of the Group Manager's private key is included in a full- | ||||
fledged Joining Response (see Section 6.4 of | ||||
[I-D.ietf-ace-key-groupcomm-oscore]), such proof-of-possession will | ||||
be achieved through every multicast notification, that the server | ||||
sends as protected with the group mode of Group OSCORE and including | ||||
a signature computed with its private key. | ||||
A client receiving an informative response uses the information above | A client receiving an informative response uses the information above | |||
to set up the Group OSCORE Security Context, as described in | to set up the Group OSCORE Security Context, as described in | |||
Section 2 of [I-D.ietf-core-oscore-groupcomm]. Note that the client | 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 | 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. | Context that a "silent server" would, i.e., without Sender Context. | |||
From then on, the client uses the received keying material to process | From then on, the client uses the received keying material to process | |||
the incoming multicast notifications from the server. | the incoming multicast notifications from the server. | |||
The server complies with the following points. | Since the server is also acting as Group Manager, the public key of | |||
the server provided in the 'srv_pub_key' element of the informative | ||||
response is also used in the 'gm_public_key' element of the | ||||
external_aad for encrypting and signing the phantom request and | ||||
multicast notifications (see Section 4.3 of | ||||
[I-D.ietf-core-oscore-groupcomm]) | ||||
Furthermore, the server complies with the following points. | ||||
* The server MUST NOT self-manage OSCORE groups and provide the | * The server MUST NOT self-manage OSCORE groups and provide the | |||
related keying material in the informative response for any other | related keying material in the informative response for any other | |||
purpose than the protection of group observations, as defined in | purpose than the protection of group observations, as defined in | |||
this document. | this document. | |||
The server MAY use the same self-managed OSCORE group to protect | The server MAY use the same self-managed OSCORE group to protect | |||
the phantom request and the multicast notifications of multiple | the phantom request and the multicast notifications of multiple | |||
group observations it hosts. | group observations it hosts. | |||
* The server MUST NOT provide in the informative response the keying | * The server MUST NOT provide in the informative response the keying | |||
material of other OSCORE groups it is or has been a member of. | material of other OSCORE groups it is or has been a member of. | |||
After the time indicated in the 'exp' field: | After the time indicated in the 'exp' field: | |||
* The server MUST stop using the keying material and MUST cancel the | * The server MUST stop using the keying material and MUST cancel the | |||
group observations for which that keying material is used (see | group observations for which that keying material is used (see | |||
Section 2.5). If the server creates a new group observation as a | Section 2.5 and Section 7.2.4). If the server creates a new group | |||
replacement or follow-up using the same OSCORE 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 Master Secret. | |||
- The server MUST update the ID Context (Gid). Consistently with | - The server MUST update the ID Context used as Group Identifier | |||
Section 2.3 of [I-D.ietf-core-oscore-groupcomm], the server | (Gid), consistently with Section 3.2 of | |||
MUST assign an ID Context that it has never assigned before in | [I-D.ietf-core-oscore-groupcomm]. | |||
the OSCORE group. | ||||
- The server MAY update the Master Salt. | - The server MAY update the Master Salt. | |||
* The client MUST stop using the keying material and MAY re-register | * The client MUST stop using the keying material and MAY re-register | |||
the observation at the server. | the observation at the server. | |||
Before the key material has expired, the server can send a multicast | Before the keying material has expired, the server can send a | |||
response with response code 5.03 (Service Unavailable) to the | multicast response with response code 5.03 (Service Unavailable) to | |||
observing clients, protected with the current key material. In | the observing clients, protected with the current keying material. | |||
particular, this is an informative response (see Section 2.2) and | In particular, this is an informative response (see Section 2.2), | |||
contains the abovementioned parameters for the next group keying | which additionally contains the abovementioned parameters for the | |||
material to be used. Alternatively, the server can simply cancel the | next group keying material to be used. The response has the same | |||
group observation (see Section 2.5), which results in the eventual | Token value T of the phantom registration request and it does not | |||
re-registration of the clients that are still interested in the group | include an Observe option. The server MUST use its own Sender | |||
observation. | Sequence Number as Partial IV to protect the error response, and | |||
include it as Partial IV in the OSCORE option of the response. | ||||
When some clients leave the OSCORE group and forget about the group | ||||
observation, the server does not have to provide the remaining | ||||
clients with any stale Sender IDs, as normally required for Group | ||||
OSCORE (see Section 3.2 of [I-D.ietf-core-oscore-groupcomm]). In | ||||
fact, only two entities in the group have a Sender ID, i.e., the | ||||
server and possibly the Deterministic Client, if the optimization | ||||
defined in this appendix is combined with the use of phantom requests | ||||
as deterministic requests (see Appendix D). In particular, both of | ||||
them never change their Sender ID during the group lifetime, while | ||||
they both remain part of the group until the group ceases to exist. | ||||
As an alternative to renewing the keying material before it expires, | ||||
the server can simply cancel the group observation (see Section 2.5 | ||||
and Section 7.2.4), 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 | Applications requiring backward security and forward security are | |||
REQUIRED to use an actual group joining process (usually through a | REQUIRED to use an actual group joining process (usually through a | |||
dedicated Group Manager), e.g. the ACE joining procedure defined in | dedicated Group Manager), e.g., the ACE joining procedure defined in | |||
[I-D.ietf-ace-key-groupcomm-oscore]. The server can facilitate the | [I-D.ietf-ace-key-groupcomm-oscore]. The server can facilitate the | |||
clients by providing them information about the OSCORE group to join, | clients by providing them information about the OSCORE group to join, | |||
as described in Section 7.1. | as described in Section 7.1. | |||
Appendix D. Phantom Request as Deterministic Request | Appendix D. Phantom Request as Deterministic Request | |||
In some settings, the server can assume that all the approaching | In some settings, the server can assume that all the approaching | |||
clients already have the exact phantom observation request to use. | clients already have the exact phantom observation request to use. | |||
For instance, the clients can be pre-configured with the phantom | For instance, the clients can be pre-configured with the phantom | |||
skipping to change at page 59, line 7 ¶ | skipping to change at page 60, line 34 ¶ | |||
Deterministic Client [I-D.amsuess-core-cachable-oscore], then the | Deterministic Client [I-D.amsuess-core-cachable-oscore], then the | |||
server and each client in the OSCORE group can independently protect | server and each client in the OSCORE group can independently protect | |||
the phantom observation request possibly available as plain CoAP | the phantom observation request possibly available as plain CoAP | |||
message. To this end, they use the approach defined in Section 2 of | message. To this end, they use the approach defined in Section 2 of | |||
[I-D.amsuess-core-cachable-oscore] to compute a protected | [I-D.amsuess-core-cachable-oscore] to compute a protected | |||
deterministic request, against which the protected multicast | deterministic request, against which the protected multicast | |||
notifications will match for the group observation in question. | notifications will match for the group observation in question. | |||
Note that, if the optimization defined in Appendix C is also used, | Note that, if the optimization defined in Appendix C is also used, | |||
the error informative response from the server has to include | the error informative response from the server has to include | |||
additional information, i.e. the Sender ID of the Deterministic | additional information, i.e., the Sender ID of the Deterministic | |||
Client in the OSCORE group, and the hash algorithm used to compute | Client in the OSCORE group, and the hash algorithm used to compute | |||
the deterministic request (see Section 2.3.1 of | the deterministic request (see Section 2.3.1 of | |||
[I-D.amsuess-core-cachable-oscore]). | [I-D.amsuess-core-cachable-oscore]). | |||
This optimization allows the server to not provide the same full | This optimization allows the server to not provide the same full | |||
phantom observation request to each client in the error informative | phantom observation request to each client in the error informative | |||
response (see Section 2.2). That is, the informative response does | response (see Section 2.2). That is, the informative response does | |||
not need to include the 'ph_req' parameter, but only the 'tp_info' | not need to convey the full phantom request in the 'ph_req' | |||
parameter specifying the transport-specific information and | parameter, but only the 'tp_info' parameter specifying the transport- | |||
(optionally) the 'last_notif' parameter specifying the latest sent | specific information and (optionally) the 'last_notif' parameter | |||
multicast notification. | specifying the latest sent multicast notification. | |||
Appendix E. Example with a Proxy | 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 5 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") | | | | | (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 | |||
| | | | | | | | | | |||
skipping to change at page 60, line 7 ¶ | skipping to change at page 61, line 34 ¶ | |||
| | | | 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 | |||
| | | GET | Observe: 0 (Register) | | | | GET | Observe: 0 (Register) | |||
| | | | Uri-Host: sensor.example | | | | | Uri-Host: sensor.example | |||
| | | | Uri-Path: r | | | | | Uri-Path: r | |||
| | | | | | | | | | |||
| | | | | ||||
| | | | (S creates a group observation of /r) | | | | | (S creates a group observation of /r) | |||
| | | | | | | | | | |||
| | | | (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 | |||
| | | | Max-Age: 0 | ||||
| | | | <Other options> | | | | | <Other options> | |||
| | | | Payload: { | | | | | Payload: { | |||
| | | | tp_info : [1, bstr(SRV_ADDR), SRV_PORT, | | | | | tp_info : [1, bstr(SRV_ADDR), SRV_PORT, | |||
| | | | 0x7b, bstr(GRP_ADDR), | | | | | 0x7b, bstr(GRP_ADDR), | |||
| | | | GRP_PORT], | | | | | GRP_PORT], | |||
| | | | ph_req : bstr(0x01 | OPT), | | | | | ph_req : bstr(0x01 | OPT), | |||
| | | | last_notif : bstr(0x45 | OPT | | | | | | last_notif : bstr(0x45 | OPT | | |||
| | | | 0xff | PAYLOAD) | | | | | 0xff | PAYLOAD) | |||
| | | | } | | | | | } | |||
| | | | | | | | | | |||
| | | | (PAYLOAD in 'last_notif' : "1234") | | | | | (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 | |||
| 2.05 | | | Content-Format: application/cbor | | 2.05 | | | Observe: 54120 | |||
| | | | Content-Format: application/cbor | ||||
| | | | <Other options> | | | | | <Other options> | |||
| | | | Payload: "1234" | | | | | Payload: "1234" | |||
| | | | | ||||
: : : : | : : : : | |||
: : : : | : : : : | |||
: : : : | : : : : | |||
| | | | | ||||
| | | | | ||||
| +----->| | Token: 0x01 | | +----->| | Token: 0x01 | |||
| | GET | | Observe: 0 (Register) | | | GET | | Observe: 0 (Register) | |||
| | | | Proxy-Uri: coap://sensor.example/r | | | | | Proxy-Uri: coap://sensor.example/r | |||
| | | | | | | | | | |||
| | | | (The proxy has a fresh cache representation) | | | | | (The proxy has a fresh cache representation) | |||
| | | | | | | | | | |||
| |<-----+ | Token: 0x01 | | |<-----+ | Token: 0x01 | |||
| | 2.05 | | Content-Format: application/cbor | | | 2.05 | | Observe: 54120 | |||
| | | | Content-Format: application/cbor | ||||
| | | | <Other options> | | | | | <Other options> | |||
| | | | Payload: "1234" | | | | | Payload: "1234" | |||
| | | | | | | | | | |||
| | | | | ||||
: : : : | : : : : | |||
: : : : (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 | |||
| | | | Content-Format: application/cbor | | | | | Content-Format: application/cbor | |||
| | | | <Other options> | | | | | <Other options> | |||
| | | | Payload: "5678" | | | | | Payload: "5678" | |||
| | | | | | | | | | |||
|<------------+ | Token: 0x4a | |<------------+ | Token: 0x4a | |||
| 2.05 | | | Observe: 54123 | | 2.05 | | | Observe: 54123 | |||
| | | | Content-Format: application/cbor | | | | | Content-Format: application/cbor | |||
| | | | <Other options> | | | | | <Other options> | |||
| | | | Payload: "5678" | | | | | Payload: "5678" | |||
| | | | | | | | | | |||
| |<-----+ | Token: 0x01 | | |<-----+ | Token: 0x01 | |||
| | 2.05 | | Observe: 54123 | | | 2.05 | | Observe: 54123 | |||
| | | | Content-Format: application/cbor | | | | | Content-Format: application/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 | |||
Figure 12: Example of group observation with a proxy | Figure 12: Example of group observation with a proxy | |||
Note that the proxy has all the information to understand the | Note that the proxy has all the information to understand the | |||
observation request from C2, and can immediately start to serve the | observation request from C2, and can immediately start to serve the | |||
still fresh values. | still fresh values. | |||
This behavior is mandated by Section 5 of [RFC7641], i.e. the proxy | 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 | registers itself only once with the next hop and fans out the | |||
notifications it receives to all registered clients. | notifications it receives to all registered clients. | |||
Appendix F. Example with a Proxy and Group OSCORE | 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 8 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") | | | | | | |||
| | | | (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), | |||
| | | | Observe: 0 (Register), | | | | | Observe: 0 (Register), | |||
| | | | Uri-Path: r, | | | | | Uri-Path: r, | |||
| | | | <Other class E options> | | | | | <Other class E options> | |||
| | | | } | | | | | } | |||
| | | | | | | | | | |||
| | +-------->| Token: 0x5e | | | +-------->| Token: 0x5e | |||
| | | 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 | |||
| | | | <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> | |||
| | | | } | | | | | } | |||
| | | | | | | | | | |||
skipping to change at page 62, line 51 ¶ | skipping to change at page 64, line 34 ¶ | |||
| | | | 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 { | |||
| | | | 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> | | | | | <Signature> | |||
| | | | | ||||
| | | | | | | | | | |||
| | | | (S steps SN_5 in the Group OSCORE | | | | | (S steps SN_5 in the Group OSCORE | |||
| | | | Security Context : SN_5 <== 502) | | | | | Security Context : SN_5 <== 502) | |||
| | | | | | | | | | |||
| | | | (S creates a group observation of /r) | | | | | (S creates a group observation of /r) | |||
| | | | | | | | | | |||
| | | | | ||||
| | | | (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 | |||
| | | 2.05 | OSCORE: {piv: 301 ; ...} | | | | 2.05 | OSCORE: {piv: 301; ...} | |||
| | | | Max-Age: 0 | ||||
| | | | <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), | | | | | tp_info : [1, bstr(SRV_ADDR), | |||
skipping to change at page 64, line 4 ¶ | skipping to change at page 65, line 33 ¶ | |||
| | | | ph_req : bstr(0x05 | OPT | 0xff | | | | | | ph_req : bstr(0x05 | OPT | 0xff | | |||
| | | | PAYLOAD | SIGN), | | | | | PAYLOAD | SIGN), | |||
| | | | last_notif : bstr(0x45 | OPT | 0xff | | | | | | last_notif : bstr(0x45 | OPT | 0xff | | |||
| | | | PAYLOAD | SIGN), | | | | | PAYLOAD | SIGN), | |||
| | | | 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 | |||
| | | | (Same Encrypted_payload) | | | | | (Same Encrypted_payload) | |||
| | | | | | | | | | |||
| | | | | ||||
+-------------->| | Token: 0x4b | +-------------->| | Token: 0x4b | |||
| FETCH | | | Observe: 0 (Register) | | FETCH | | | Observe: 0 (Register) | |||
| | | | OSCORE: {kid: 5 ; piv: 501 ; ...} | | | | | OSCORE: {kid: 5 ; piv: 501; | |||
| | | | kid context: 57ab2e; ...} | ||||
| | | | Uri-Host: sensor.example | | | | | Uri-Host: sensor.example | |||
| | | | Proxy-Scheme: coap | | | | | Proxy-Scheme: coap | |||
| | | | Listen-To- | | | | | Listen-To- | |||
| | | | Multicast-Responses: {[1, bstr(SRV_ADDR), | | | | | Multicast-Responses: {[1, bstr(SRV_ADDR), | |||
| | | | SRV_PORT, 0x7b, | | | | | SRV_PORT, 0x7b, | |||
| | | | 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> | | | | | <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.) | |||
| | | | | ||||
|<--------------| | | ||||
| | ACK | | | ||||
: : : : | : : : : | |||
: : : : | : : : : | |||
: : : : | : : : : | |||
| | | | | ||||
| +------>| | 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), | |||
| | | | Uri-Path: r, | | | | | Uri-Path: r, | |||
| | | | <Other class E options> | | | | | <Other class E options> | |||
| | | | } | | | | | } | |||
| | | | | | | | | | |||
| | +-------->| Token: 0x5e | | | +-------->| Token: 0x5f | |||
| | | 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 | |||
| | | | <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> | |||
| | | | } | | | | | } | |||
| | | | | | | | | | |||
| | |<--------+ Token: 0x5e | | | |<--------+ Token: 0x5f | |||
| | | 2.05 | OSCORE: {piv: 401 ; ...} | | | | 2.05 | OSCORE: {piv: 401; ...} | |||
| | | | Max-Age: 0 | ||||
| | | | <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), | | | | | tp_info : [1, bstr(SRV_ADDR), | |||
skipping to change at page 65, line 46 ¶ | skipping to change at page 67, line 31 ¶ | |||
| | | | PAYLOAD | SIGN), | | | | | PAYLOAD | SIGN), | |||
| | | | last_notif : bstr(0x45 | OPT | 0xff | | | | | | last_notif : bstr(0x45 | OPT | 0xff | | |||
| | | | PAYLOAD | SIGN), | | | | | PAYLOAD | SIGN), | |||
| | | | 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 | |||
| | | | (Same Encrypted_payload) | | | | | (Same Encrypted_payload) | |||
| | | | | | | | | | |||
| | | | | ||||
| +------>| | Token: 0x02 | | +------>| | Token: 0x02 | |||
| | FETCH | | Observe: 0 (Register) | | | FETCH | | Observe: 0 (Register) | |||
| | | | OSCORE: {kid: 5 ; piv: 501 ; ...} | | | | | OSCORE: {kid: 5; piv: 501; | |||
| | | | kid context: 57ab2e; ...} | ||||
| | | | Uri-Host: sensor.example | | | | | Uri-Host: sensor.example | |||
| | | | Proxy-Scheme: coap | | | | | Proxy-Scheme: coap | |||
| | | | Listen-To- | | | | | Listen-To- | |||
| | | | Multicast-Responses: {[1, bstr(SRV_ADDR), | | | | | Multicast-Responses: {[1, bstr(SRV_ADDR), | |||
| | | | SRV_PORT, 0x7b, | | | | | SRV_PORT, 0x7b, | |||
| | | | 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> | | | | | <Signature> | |||
| | | | | | | | | | |||
| | | | (The proxy adds C2 to its list of | | | | | (The proxy adds C2 to | |||
| | | | observers, and serves the cached | | | | | its list of observers.) | |||
| | | | response) | | |<------| | | |||
| | ACK | | | ||||
| | | | | | | | | | |||
| |<------+ | Token: 0x02 | ||||
| | 2.05 | | OSCORE: {piv: 301 ; ...} | ||||
| | | | <Other class U/I options> | ||||
| | | | 0xff | ||||
| | | | (Same as earlier to C1) | ||||
: : : : | ||||
: : : : | : : : : | |||
: : : : (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 | |||
| | | | 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 { | | | | | Encrypted_payload { | |||
| | | | 2.05 (Content), | | | | | 2.05 (Content), | |||
| | | | Observe: 11, | | | | | Observe: [empty], | |||
| | | | 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> | | | | | <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 | |||
| | | | (Same Encrypted_payload) | | | | | (Same Encrypted_payload and 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 | |||
| | | | (Same Encrypted_payload) | | | | | (Same Encrypted_payload and 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 13: Example of group observation with a proxy and Group OSCORE | Figure 13: Example of group observation with a proxy and Group OSCORE | |||
Unlike in the unprotected example in Appendix E, the proxy does _not_ | Unlike in the unprotected example in Appendix E, the proxy does _not_ | |||
have all the information to perform request deduplication, and can | have all the information to perform request deduplication, and can | |||
only recognize the identical request once the client sends the ticket | only recognize the identical request once the client sends the ticket | |||
request. | request. | |||
Appendix G. Example with a Proxy and Deterministic Requests | ||||
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 | ||||
notifications end-to-end between the server and the clients. | ||||
In addition, the phantom request is especially a deterministic | ||||
request (see Appendix D), which is protected with the pairwise mode | ||||
of Group OSCORE as defined in [I-D.amsuess-core-cachable-oscore]. | ||||
G.1. Assumptions and Walkthrough | ||||
The example provided in this appendix as reflected by the message | ||||
exchange shown in Appendix G.2 assumes the following. | ||||
1. The OSCORE group supports deterministic requests. Thus, the | ||||
server creates the phantom request as a deterministic request | ||||
[I-D.amsuess-core-cachable-oscore], and stores it locally as one | ||||
of its issued phantom requests, without starting the group | ||||
observation yet. | ||||
2. The server makes the phantom request available through other | ||||
means, e.g., a pub-sub broker, together with the transport- | ||||
specific information for listening to multicast notifications | ||||
bound to the phantom request (see Appendix A). | ||||
3. Since the phantom request is a deterministic request, the server | ||||
can more efficiently make it available in its smaller, plain | ||||
version. The clients can obtain it from the particular | ||||
alternative source, and compute the protected version to use | ||||
from the retrieved plain version. | ||||
4. If the client does not rely on a proxy between itself and the | ||||
server, it simply sets the group observation and starts | ||||
listening to multicast notifications. Building on point (2) | ||||
above, the same would happen if the phantom request would not be | ||||
specifically a deterministic request. | ||||
5. If the client relies on a proxy between itself and the server, | ||||
it uses the phantom request as a ticket request. However, | ||||
unlike the case considered in Section 10 when the ticket request | ||||
is not deterministic, the client does not include a Listen-to- | ||||
Multicast-Responses option in the phantom request sent to the | ||||
proxy. | ||||
6. Unlike for the case considered in Section 10, here the proxy | ||||
does not know that the request is exactly a ticket request for | ||||
subscribing to multicast notifications. Thus, the proxy simply | ||||
forwards the ticket request to the server as it normally does | ||||
for any request. | ||||
7. The server receives the ticket request, which is a deviation | ||||
from the case where the ticket request is not deterministic and | ||||
stops at the proxy (see Section 10). Then, the server can | ||||
clearly understand what is happening. In fact, as the result of | ||||
an early check, the server recognizes the phantom request among | ||||
the stored ones. This happens through a byte-by-byte comparison | ||||
of the incoming message minus the transport-related fields, | ||||
i.e., by considering only: i) the outer REST code; ii) the outer | ||||
options; and iii) the ciphertext and signature from the message | ||||
payload. | ||||
8. Having recognized the incoming request as one of the self- | ||||
generated deterministic phantom requests made available at | ||||
external sources, the server does not perform any OSCORE | ||||
processing on it. This opens for replying to the proxy with an | ||||
unprotected response, although not signaling any OSCORE-related | ||||
error. | ||||
9. The server starts the group observation and replies with an | ||||
error response, i.e., the usual 5.03 informative response, | ||||
including: the transport information, the phantom request, and | ||||
(optionally) the latest notification. | ||||
10. From the received 5.03 response, the proxy retrieves everything | ||||
needed to set itself as an observer in the group observation, | ||||
and it starts listening to multicast notifications. If the 5.03 | ||||
response included a latest notification, the proxy caches it and | ||||
forwards it back to the client, otherwise it replies with an | ||||
empty ACK (if it has not done it already and the request from | ||||
the client was Confirmable). | ||||
11. Like in the case with a non-deterministic phantom request | ||||
considered in Section 10, the proxy fans out the multicast | ||||
notifications to the origin clients as they come. Also, as new | ||||
clients following the first one contact the proxy, this does not | ||||
have to contact the server again as in Section 10, since the | ||||
deterministic phantom request would produce a cache hit as per | ||||
[I-D.amsuess-core-cachable-oscore]. Thus, the proxy can serve | ||||
such clients with the latest fresh multicast notification from | ||||
its cache. | ||||
G.2. Message Exchange | ||||
The same assumptions and notation used in Section 8 are used for this | ||||
example. As a recap of some specific value: | ||||
* Two clients C_1 and C_2 register 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 exchanges occur, no clients | ||||
are observing the resource /r , which has value "1234". | ||||
* The server S sends multicast notifications to the IP multicast | ||||
address GRP_ADDR and port number GRP_PORT, and starts the group | ||||
observation upon receiving a registration request from a first | ||||
client that wishes to start a traditional observation on the | ||||
resource /r. | ||||
* S is a member of the OSCORE group with 'kid context' = 0x57ab2e as | ||||
Group ID. In the OSCORE group, S has 'kid' = 5 as Sender ID, and | ||||
SN_5 = 501 as Sender Sequence Number. | ||||
In addition: | ||||
* The proxy has address PRX_ADDR and listens to the port number | ||||
PRX_PORT. | ||||
* The deterministic client in the OSCORE group has 'kid' 9. | ||||
Unless explicitly indicated, all messages transmitted on the wire are | ||||
sent over unicast and protected with Group OSCORE end-to-end between | ||||
a client and the server. | ||||
C1 C2 P S | ||||
| | | | | ||||
| | | | (The value of the resource /r is "1234") | ||||
| | | | | ||||
| | | | (The server prepares a deterministic | ||||
| | | | phantom request PH_REQ. The server | ||||
| | | | stores PH_REQ locally and makes it | ||||
| | | | available at an external source) | ||||
| | | | | ||||
| | | | (C1 obtains PH_REQ and sends it to P) | ||||
| | | | | ||||
| | | | | ||||
+-------------->| | Token: 0x4a | ||||
| FETCH | | | Uri-Host: sensor.example | ||||
| | | | Observe: 0 (Register) | ||||
| | | | OSCORE: {kid: 9 ; piv: 0 ; | ||||
| | | | kid context: 0x57ab2e ; ... } | ||||
| | | | Proxy-Scheme: coap | ||||
| | | | <Other class U/I options> | ||||
| | | | 0xff | ||||
| | | | Encrypted_payload { | ||||
| | | | 0x01 (GET), | ||||
| | | | Observe: 0 (Register), | ||||
| | | | Uri-Path: r, | ||||
| | | | <Other class E options> | ||||
| | | | } | ||||
| | | | | ||||
| | +-------->| Token: 0x5e | ||||
| | | FETCH | Uri-Host: sensor.example | ||||
| | | | Observe: 0 (Register) | ||||
| | | | OSCORE: {kid: 9 ; piv: 0 ; | ||||
| | | | kid context: 0x57ab2e ; ... } | ||||
| | | | <Other class U/I options> | ||||
| | | | 0xff | ||||
| | | | Encrypted_payload { | ||||
| | | | 0x01 (GET), | ||||
| | | | Observe: 0 (Register), | ||||
| | | | Uri-Path: r, | ||||
| | | | <Other class E options> | ||||
| | | | } | ||||
| | | | | ||||
| | | | (S recognizes PH_REQ through byte-by-byte | ||||
| | | | comparison against the stored one, and | ||||
| | | | skips any OSCORE processing) | ||||
| | | | | ||||
| | | | (S allocates the available | ||||
| | | | Token value 0x7b .) | ||||
| | | | | ||||
| | | | (S sends to itself PH_REQ, with Token 0x7b | ||||
| | | | and as coming from the IP multicast | ||||
| | | | address GRP_ADDR; now the OSCORE | ||||
| | | | processing does happen, as specified | ||||
| | | | for a deterministic request) | ||||
| | | | | ||||
| | | -------| | ||||
| | | / | | ||||
| | | \------>| Token: 0x7b | ||||
| | | FETCH | Uri-Host: sensor.example | ||||
| | | | Observe: 0 (Register) | ||||
| | | | OSCORE: {kid: 9 ; piv: 0 ; | ||||
| | | | kid context: 0x57ab2e ; ... } | ||||
| | | | <Other class U/I options> | ||||
| | | | 0xff | ||||
| | | | Encrypted_payload { | ||||
| | | | 0x01 (GET), | ||||
| | | | Observe: 0 (Register), | ||||
| | | | Uri-Path: r, | ||||
| | | | <Other class E options> | ||||
| | | | } | ||||
| | | | | ||||
| | | | (S prepares the "last notification" | ||||
| | | | response defined below) | ||||
| | | | | ||||
| | | | 0x45 (2.05 Content) | ||||
| | | | Observe: 10 | ||||
| | | | OSCORE: {kid: 5 ; piv: 501 ; | ||||
| | | | kid context: 57ab2e; ...} | ||||
| | | | Max-Age: 3000 | ||||
| | | | <Other class U/I options> | ||||
| | | | 0xff | ||||
| | | | Encrypted_payload { | ||||
| | | | 0x45 (2.05 Content), | ||||
| | | | Observe: [empty], | ||||
| | | | Payload: "1234" | ||||
| | | | } | ||||
| | | | | ||||
| | | | (S responds to the proxy with an | ||||
| | | | unprotected informative response) | ||||
| | | | | ||||
| | |<--------| Token: 0x5e | ||||
| | | 5.03 | Content-Format: application/ | ||||
| | | | informative-response+cbor | ||||
| | | | Max-Age: 0 | ||||
| | | | 0xff, | ||||
| | | | CBOR_payload { | ||||
| | | | tp_info : [1, bstr(SRV_ADDR), SRV_PORT, | ||||
| | | | 0x7b, bstr(GRP_ADDR), | ||||
| | | | GRP_PORT], | ||||
| | | | ph_req : <the deterministic | ||||
| | | | phantom request>, | ||||
| | | | last_notif : <the "last notification" | ||||
| | | | response prepared above> | ||||
| | | | } | ||||
| | | | } | ||||
| | | | | ||||
| | | | (P extracts PH_REQ and starts listening | ||||
| | | | to multicast notifications with Token | ||||
| | | | 0x7b at GRP_ADDR:GRP_PORT) | ||||
| | | | | ||||
| | | | (P extracts the "last notification" | ||||
| | | | response, caches it and forwards | ||||
| | | | it back to C1) | ||||
| | | | | ||||
|<--------------+ | Token: 0x4a | ||||
| 2.05 | | | Observe: 54120 | ||||
| | | | OSCORE: {kid: 5 ; piv: 501 ; | ||||
| | | | kid context: 57ab2e; ...} | ||||
| | | | Max-Age: 2995 | ||||
| | | | <Other class U/I options> | ||||
| | | | 0xff | ||||
| | | | Encrypted_payload { | ||||
| | | | 0x45 (2.05 Content), | ||||
| | | | Observe: [empty], | ||||
| | | | Payload: "1234" | ||||
| | | | } | ||||
| | | | | ||||
: : : | | ||||
: : : | | ||||
: : : | | ||||
| | | | | ||||
| | | | (C2 obtains PH_REQ and sends it to P) | ||||
| | | | | ||||
| +------>| | Token: 0x01 | ||||
| | FETCH | | Uri-Host: sensor.example | ||||
| | | | Observe: 0 (Register) | ||||
| | | | OSCORE: {kid: 9 ; piv: 0 ; | ||||
| | | | kid context: 57ab2e; ...} | ||||
| | | | Proxy-Scheme: coap | ||||
| | | | <Other class U/I options> | ||||
| | | | 0xff | ||||
| | | | Encrypted_payload { | ||||
| | | | 0x01 (GET), | ||||
| | | | Observe: 0 (Register), | ||||
| | | | Uri-Path: r, | ||||
| | | | <Other class E options> | ||||
| | | | } | ||||
| | | | | ||||
| | | | (P serves C2 from it cache) | ||||
| | | | | ||||
| |<------+ | Token: 0x01 | ||||
| | 2.05 | | Observe: 54120 | ||||
| | | | OSCORE: {kid: 5 ; piv: 501 ; | ||||
| | | | kid context: 57ab2e; | ||||
| | | | Max-Age: 1800 | ||||
| | | | <Other class U/I options> | ||||
| | | | 0xff | ||||
| | | | Encrypted_payload { | ||||
| | | | 0x45 (2.05 Content), | ||||
| | | | Observe: [empty], | ||||
| | | | Payload: "1234" | ||||
| | | | } | ||||
| | | | | ||||
: : : | | ||||
: : : | | ||||
: : : | | ||||
| | | | | ||||
| | | | (The value of the resource | ||||
| | | | /r changes to "5678".) | ||||
| | | | | ||||
| | | (*) | | ||||
| | |<--------| Token: 0x7b | ||||
| | | 2.05 | Observe: 11 | ||||
| | | | OSCORE: {kid: 5; piv: 502 ; ...} | ||||
| | | | <Other class U/I options> | ||||
| | | | 0xff | ||||
| | | | Encrypted_payload { | ||||
| | | | 0x45 (2.05 Content), | ||||
| | | | Observe: [empty], | ||||
| | | | Content-Format: application/cbor, | ||||
| | | | <Other class E options>, | ||||
| | | | 0xff, | ||||
| | | | CBOR_Payload : "5678" | ||||
| | | | } | ||||
| | | | <Signature> | ||||
| | | | | ||||
| | | | (P updates its cache entry | ||||
| | | | with this notification) | ||||
| | | | | ||||
|<--------------+ | Token: 0x4a | ||||
| 2.05 | | | Observe: 54123 | ||||
| | | | OSCORE: {kid: 5; piv: 502 ; ...} | ||||
| | | | <Other class U/I options> | ||||
| | | | 0xff | ||||
| | | | (Same Encrypted_payload and signature) | ||||
| | | | | ||||
| |<------+ | Token: 0x01 | ||||
| | 2.05 | | Observe: 54123 | ||||
| | | | OSCORE: {kid: 5; piv: 502 ; ...} | ||||
| | | | <Other class U/I options> | ||||
| | | | 0xff | ||||
| | | | (Same Encrypted_payload and signature) | ||||
| | | | | ||||
(*) Sent over IP multicast to GROUP_ADDR:GROUP_PORT and protected | ||||
with Group OSCORE end-to-end between the server and the clients. | ||||
Appendix H. Document Updates | ||||
RFC EDITOR: PLEASE REMOVE THIS SECTION. | ||||
H.1. Version -00 to -01 | ||||
* Simplified cancellation of the group observation, without using a | ||||
phantom cancellation request. | ||||
* Aligned parameter semantics with core-oscore-groupcomm and ace- | ||||
key-groupcomm-oscore. | ||||
* Clarifications about self-managed OSCORE group and use of | ||||
deterministic requests for cacheable OSCORE. | ||||
* New example with a proxy, Group OSCORE and a deterministic phantom | ||||
request. | ||||
* Fixes in the examples and editorial improvements. | ||||
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). | |||
skipping to change at page 68, line 4 ¶ | skipping to change at page 76, line 38 ¶ | |||
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). | |||
Authors' Addresses | Authors' Addresses | |||
Marco Tiloca | Marco Tiloca | |||
RISE AB | RISE AB | |||
Isafjordsgatan 22 | Isafjordsgatan 22 | |||
SE-16440 Stockholm Kista | SE-16440 Stockholm Kista | |||
Sweden | Sweden | |||
Email: marco.tiloca@ri.se | Email: marco.tiloca@ri.se | |||
Rikard Höglund | ||||
Rikard Hoeglund | ||||
RISE AB | RISE AB | |||
Isafjordsgatan 22 | Isafjordsgatan 22 | |||
SE-16440 Stockholm Kista | SE-16440 Stockholm Kista | |||
Sweden | Sweden | |||
Email: rikard.hoglund@ri.se | Email: rikard.hoglund@ri.se | |||
Christian Amsuess | Christian Amsüss | |||
Hollandstr. 12/4 | Hollandstr. 12/4 | |||
1020 Vienna | 1020 Vienna | |||
Austria | Austria | |||
Email: christian@amsuess.com | Email: christian@amsuess.com | |||
Francesca Palombini | Francesca Palombini | |||
Ericsson AB | Ericsson AB | |||
Torshamnsgatan 23 | Torshamnsgatan 23 | |||
SE-16440 Stockholm Kista | SE-16440 Stockholm Kista | |||
End of changes. 209 change blocks. | ||||
429 lines changed or deleted | 852 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/ |