Internet-Draft SW Update with CoAP Group communication January 2026
Tiloca Expires 11 July 2026 [Page]
Workgroup:
Thing-to-Thing Research Group
Internet-Draft:
draft-tiloca-t2trg-sw-update-groupcomm-01
Published:
Intended Status:
Experimental
Expires:
Author:
M. Tiloca
RISE AB

Distribution of Software Updates with End-to-End Secure Group Communication and Block-Wise Transfer for CoAP

Abstract

This document defines a method for efficiently distributing a software update to multiple target devices, by using end-to-end secure group communication over UDP and IP multicast. To this end, the defined method relies on a number of building blocks developed in the Constrained RESTful Environments (CoRE) Working Group of the IETF. Those especially include the Constrained Application Protocol (CoAP), Block-wise transfers for CoAP, and the end-to-end security protocol Group Object Security for Constrained RESTful Environments (Group OSCORE). The method defined in this document is compatible with (but not dependent on) the architecture for software and firmware update developed in the Software Updates for Internet of Things (SUIT) Working Group of the IETF.

Discussion Venues

This note is to be removed before publishing as an RFC.

Discussion of this document takes place on the Thing-to-Thing Research Group mailing list (t2trg@irtf.org), which is archived at https://mailarchive.ietf.org/arch/browse/t2trg/.

Source for this draft and an issue tracker can be found at https://gitlab.com/crimson84/draft-tiloca-t2trg-sw-update-groupcomm.

Status of This Memo

This Internet-Draft is submitted in full conformance with the provisions of BCP 78 and BCP 79.

Internet-Drafts are working documents of the Internet Engineering Task Force (IETF). Note that other groups may also distribute working documents as Internet-Drafts. The list of current Internet-Drafts is at https://datatracker.ietf.org/drafts/current/.

Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as "work in progress."

This Internet-Draft will expire on 11 July 2026.

▲

Table of Contents

1. Introduction

Throughout the operational phase of their lifecycle, it is vital that devices can effectively receive and install required software (SW) updates. This is important not only in order to add and extend features or to improve performance, but also and especially in order to address and prevent security vulnerabilities. In turn, the distribution of SW updates in itself has to be a secure and efficient process that scales well with the size of the software update and with the number of target devices.

This document defines a method for efficiently distributing a SW update to multiple target devices, by using end-to-end secure group communication over UDP and IP multicast. To this end, the defined method relies on a number of building blocks developed in the Constrained RESTful Environments (CoRE) Working Group of the IETF. Those especially include the Constrained Application Protocol (CoAP) [RFC7252], Block-wise transfers for CoAP [RFC7959], and the end-to-end security protocol Group Object Security for Constrained RESTful Environments (Group OSCORE) [I-D.ietf-core-oscore-groupcomm].

The defined method leverages a CoAP-to-CoAP proxy deployed between the CoAP target devices to update and a CoAP server acting as Distributor of the SW update. The proxy communicates with the Distributor using CoAP over TCP [RFC8323] and retrieves the next-in-line "inner chunk" of the SW update from the Distributor, by using Block-wise Extension for Reliable Transport (BERT) [RFC8323]. A CoAP response originated by the Distributor and conveying an inner chunk is protected end-to-end between the Distributor and the target devices, by using Group OSCORE.

When a target device contacts the proxy for obtaining the latest SW update, the proxy relies on the use of Group OSCORE defined in [I-D.ietf-core-cacheable-oscore]. That is, it retrieves the next-in-line inner chunk from the Distributor if not already available in its cache, and then caches the response that conveys the inner chunk. After that, building on concepts from [I-D.ietf-core-observe-multicast-notifications], the proxy replies to the target device with an error response, informing about the time when it is going to distribute the inner chunk and providing transport-specific information for receiving that inner chunk.

When that time comes, the proxy transmits the inner chunk to all the target devices by further splitting it into smaller "outer chunks", each of which is conveyed by a CoAP response over UDP and IP multicast using Block-wise transfer [RFC7959]. At the end of such transfer, the target devices are allowed to selectively request outer chunks that they have missed for the current inner chunk.

After the proxy declares the transfer of the current inner chunk completed, the process is repeated for the next inner chunk, which the proxy retrieves from the Distributor and transmits to the target devices as above. Eventually, the proxy completes the transfer of the last inner chunk. After that, as a new request comes from a target device to retrieve the latest SW update, the proxy restarts the process by retrieving the first inner chunk and providing it to the target devices.

This document also defines how to counteract an attack against availability that an active adversary could easily perform by manipulating the CoAP responses sent by the proxy to the target devices and conveying the small outer chunks. The attack is neutralized by having a short checksum value computed by the proxy and included in such responses. By recomputing and verifying the checksum, target devices can thus promptly detect a possible manipulation of an outer chunk and discard the response conveying it as invalid.

The method defined in this document is compatible with (but not dependent on) the architecture for SW and firmware update specified in [RFC9019] and developed in the Software Updates for Internet of Things (SUIT) Working Group of the IETF.

1.1. Terminology

The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in BCP 14 [RFC2119] [RFC8174] when, and only when, they appear in all capitals, as shown here.

Readers are expected to be familiar with the terms and concepts related to:

This document also relies on the following terminology:

  • Image: a binary that can contain the complete SW of a device, or part of it. The image might be in turn structured in multiple images, and the corresponding SW might specifically be a firmware. Also, it might consist of a differential update in the interest of performance.

  • Manifest: a collection of metadata about the image and author. The manifest is generated by the author and protected against modifications.

  • Author: the entity that generates the image and the associated manifest.

  • Device: target of a SW update as intended to obtain and consume an image.

  • Distributor: the entity that distributes the image and the associated manifest on behalf of the author.

  • Manifest resource: a resource hosted at the Distributor, with a manifest as its representation. This resource is observable [RFC7641].

  • Image resource: a resource hosted at the Distributor, with an image as its representation.

2. Building Blocks

The distribution method defined in this document largely relies on a number of building blocks that are summarized in the following subsections.

2.1. CoAP

CoAP is a web-transfer protocol specified in [RFC7252]. It relies on the client-server message exchange model and builds on the Representational State Transfer (REST) paradigm for accessing and manipulating resource representations hosted at a server. CoAP messages can be very compact and, besides a payload and a mandatory header, can include CoAP options that indicate the additional use of protocol extensions and optional features. The mandatory header includes a variable-length Token field whose value is used to associate a response with a corresponding request. CoAP is typically transported over UDP, but it can also be used over reliable transports such as TCP and WebSockets [RFC8323].

CoAP natively supports proxies deployed between origin client endpoints and origin server endpoints. Main reasons to deploy proxies include: relaying messages between origin endpoints that cannot directly interact with one another; caching response messages to serve requests from origin clients more efficiently and avoiding repeatedly interacting with origin servers; and performing protocol translation across different communication legs. Proxy operations for CoAP are detailed in Section 5.7 of [RFC7252].

CoAP also natively supports group communication [I-D.ietf-core-groupcomm-bis]. That is, an origin client can send a single group request targeting multiple recipient servers at once, e.g., over UDP and IP multicast. The servers can individually reply to that group request by sending their unicast responses, each of which is associated by Token value with the same group request.

2.2. CoAP Observe

Observe is an extension for CoAP specified in [RFC7641]. When using Observe, a client accesses a resource at a server by additionally requesting to be registered as an observer for that resource. A successful response from the server can confirm the client to have become a registered observer. In such a case, following updates in the resource representation will result in the server sending notification responses to the client. Each of such notification responses conveys the current resource representation and is associated by Token value with the request originally sent by the client to start the observation. This extension relies on the CoAP Observe option included in the original observation request and in each notification response.

2.3. CoAP Block-wise Transfer

Block-wise is an extension for CoAP specified in [RFC7959]. With the intent to avoid message fragmentation at lower layers, Block-wise enables message senders to split their large-size application data to transmit (body) into multiple, smaller data units referred to as blocks. This process occurs at the CoAP layer and results in sequentially sending each block of the same body as the payload of a different CoAP message. The message recipient can re-assemble the original body once all the corresponding blocks are received. This extension relies on the CoAP Block1 and Block2 options. Those are appropriately included in request and response messages to either describe the block conveyed in the present message or to control the Block-wise transfer process.

For the case where CoAP is transported over reliable transports such as TCP, [RFC8323] also specifies Block-wise Extension for Reliable Transport (BERT). This still relies on the same CoAP Block1 and Block2 options as also explicitly indicating the use of BERT. In practice, a BERT message conveys in its payload one or more blocks of size 1024 bytes, with the possible exception of the BERT message conveying the last block that can have a smaller size.

2.4. OSCORE

Object Security for Constrained RESTful Environments (OSCORE) is a security protocol specified in [RFC8613]. OSCORE protects CoAP messages end-to-end between the origin endpoint producing application data and the other origin endpoint consuming that data.

To this end, it takes as input an outgoing CoAP message and produces as output an OSCORE-protected CoAP message that includes the CoAP OSCORE option. When receiving the OSCORE-protected message, the recipient endpoint relies on the information in the OSCORE option to attempt decrypting and verifying the message. By using CBOR [RFC8949] for data encoding and COSE [RFC9052] for security operations, OSCORE has a lightweight impact on message sizes and performance.

OSCORE ensures end-to-end confidentiality, integrity, and source authentication of messages, as well as replay protection. Each OSCORE-protected response is cryptographically bound to the corresponding request, also when Observe [RFC7641] is used and thus multiple notification responses are bound to the same observation request.

These security properties hold also in the presence of (untrusted) proxies deployed between the two OSCORE endpoints. Since OSCORE selectively protects different parts of a CoAP message, it hides as much as possible from possibly deployed proxies, while keeping the proxies able to perform their intended tasks. Furthermore, since the OSCORE processing of a CoAP message results in another CoAP message, OSCORE is independent of the specific transport underlying CoAP and used to transport CoAP messages (e.g., UDP or TCP). Therefore, OSCORE works wherever CoAP works.

In order to use OSCORE, two CoAP endpoints have to first establish an OSCORE Security Context including the necessary parameters and keying material. OSCORE is agnostic of how exactly the Security Context is established. A possible way is the lightweight authenticated key exchange protocol Ephemeral Diffie-Hellman Over COSE (EDHOC) [RFC9528].

2.5. Group OSCORE

Group OSCORE is a security protocol specified in [I-D.ietf-core-oscore-groupcomm]. By building on OSCORE [RFC8613] and extending its construct, Group OSCORE protects CoAP messages end-to-end between endpoints that use CoAP in a group communication setup [I-D.ietf-core-groupcomm-bis].

Also by relying on CBOR [RFC8949] and COSE [RFC9052], Group OSCORE ensures end-to-end confidentiality, integrity, and source authentication of messages, as well as replay protection. All the protected responses originated by different servers and corresponding to the same group request are cryptographically bound to such request.

Messages protected with Group OSCORE also include a CoAP OSCORE option that indicates the recipient endpoint how to attempt decrypting and verifying an incoming message. Like OSCORE, Group OSCORE works wherever CoAP works, also in the presence of proxies.

Group OSCORE provides two modes for protecting messages, allowing to choose the mode to use on a per-message basis. The main difference between the two modes is about the way used to ensure source authentication of the protected message:

  • When using the group mode (see Section 7 of [I-D.ietf-core-oscore-groupcomm]), the message is first encrypted with keying material that every group member can derive, and then is signed by using the private key of the sender endpoint. The resulting signature is placed at the end of the CoAP payload of the protected message and then separately encrypted in order to contrast tracking of endpoints across different groups. As a result, all group members are able to decrypt the message and to verify that the message sender is the alleged group member. The group mode is typically used to protect requests that are sent to the whole group, i.e., that are intended to all CoAP servers in the group.

  • When using the pairwise mode (see Section 8 of [I-D.ietf-core-oscore-groupcomm]), the message is protected by using an authenticated encryption algorithm. The encryption key to use is derived from the asymmetric authentication credentials of the sender endpoint and the single recipient endpoint, by means of a static-static Diffie-Hellman key derivation performed locally. As a result, only the intended recipient is able to decrypt the message and to verify that the message sender is the alleged group member. The pairwise mode is typically used to protect a response that is individually sent by a server in the group.

In order to use Group OSCORE, a CoAP endpoint has to join an OSCORE group and effectively become a member. The join process is typically assisted by a Group Manager entity that is responsible for the OSCORE group and that might enforce access control when deciding whether to admit new endpoints requesting to join the group. As a result of a successful join process, a CoAP endpoint obtains the necessary parameters and keying material to set up a Group OSCORE Security Context and consequently use Group OSCORE with the other group members. A possible realization of Group Manager is specified in [I-D.ietf-ace-key-groupcomm-oscore], where the join process is based on the ACE framework for authentication and authorization in constrained environments [RFC9200].

2.6. Observe multicast notifications

According to the original use of CoAP Observe [RFC7641], two CoAP clients interested in registering a resource observation at a server will yield two distinct observations.

However, some applications involve multiple clients that are all interested in observing the same resource at the same server. While the original approach remains usable, an alternative and more scalable approach is specified in [I-D.ietf-core-observe-multicast-notifications].

This second approach takes advantage of group communication for CoAP and relies on the CoAP server to initiate a group observation at itself, e.g., upon receiving a first traditional observation request from a client. To this end, the server composes a cosmetic phantom observation request and sends it to itself without hitting the wire, in order to start the corresponding group observation.

When a client sends a traditional observation request targeting that resource, the server replies with an informative error response conveying: i) the phantom observation request associated with the group observation; and ii) transport-specific information that is needed for receiving the notification responses in the group observation. That information includes the CoAP Token value used for the phantom observation request and the multicast address where observe notifications will be sent to. This effectively aligns all the interested clients to the same common knowledge required for participating in the group observation and receiving the multicast notification responses.

Consequently, when the representation of the observed resource at the server changes, the server sends a single observe notification response over UDP and IP multicast, thus targeting all the clients that are taking part in the group observation. All such observe multicast notifications include the same CoAP Token value used in the phantom observation request. The recipient clients have been instructed on how to receive such observe multicast notifications when obtaining the individual informative error response from the server.

The observe multicast notifications can be protected end-to-end between the server and the clients, by using Group OSCORE in group mode [I-D.ietf-core-oscore-groupcomm]. Since the server uses Group OSCORE also to protect the phantom observation request that started the group observation, all the observe notifications in the group observation are cryptographically bound to such phantom observation request, and thereby verifiable to pertain to the group observation in question.

2.7. Cacheable OSCORE

It is typically possible to rely on a deployed proxy to store in its cache some classes of CoAP responses received from origin servers. That allows the proxy to quicker serve later requests from CoAP clients that produce a cache hit, by replying with the cached response instead of obtaining a new response from the origin server.

If CoAP messages are protected with OSCORE [RFC8613] or Group OSCORE [I-D.ietf-core-oscore-groupcomm], effective caching of responses is not achievable anymore. That is, even if two clients wish to send the same plain CoAP request, the two resulting protected requests will be different and thus will not result in a cache hit at the proxy. Therefore, separately for each of the two clients, the proxy has to retrieve a new response from the origin server. The same holds also when considering the same client that wishes to send the same plain CoAP request at different points in time.

In order to overcome this limitation, the approach defined in [I-D.ietf-core-cacheable-oscore] builds on Group OSCORE and restores the effective cacheability of protected responses.

According to this approach, any client in the OSCORE group can also act as a specific "Deterministic Client" and use the corresponding keying material known to all the group members. When acting as Deterministic Client, any two clients in the group that protect the same plain CoAP request will produce the same protected "Deterministic Request", which is thereby usable to produce a cache hit at a caching proxy.

The construct that makes this possible relies on the following design points: i) Deterministic Requests are computed by using a variation of the pairwise mode of Group OSCORE; ii) responses to a Deterministic Request are protected by using the group mode of Group OSCORE.

This approach restores cacheability of protected responses while sacrificing some security properties of the protected Deterministic Requests, which in fact are replays and have no source authentication. However, this is deemed acceptable and harmless for the particular, narrow scope targeted by this approach, whose applicability is limited to content retrieval through read-only requests that are safe in the REST sense. Servers that want to be even more conservative can additionally limit themselves to accept only Deterministic Requests that target specific resources, or even that match byte-by-byte with Deterministic Requests that are known in advance.

3. Architecture

This section describes the architecture considered in the rest of this document when defining the method for distributing SW updates.