Clarifications and Updates on using Static Context Header Compression (SCHC) for the Constrained Application Protocol (CoAP)
draft-tiloca-schc-8824-update-01
The information below is for an old version of the document.
| Document | Type |
This is an older version of an Internet-Draft whose latest revision state is "Replaced".
|
|
|---|---|---|---|
| Authors | Marco Tiloca , Laurent Toutain , Ivan Martinez , Ana Minaburo | ||
| Last updated | 2023-07-10 (Latest revision 2023-04-03) | ||
| Replaces | draft-tiloca-lpwan-8824-update | ||
| Replaced by | draft-ietf-schc-8824-update | ||
| RFC stream | (None) | ||
| Formats | |||
| Stream | Stream state | (No stream defined) | |
| Consensus boilerplate | Unknown | ||
| RFC Editor Note | (None) | ||
| IESG | IESG state | I-D Exists | |
| Telechat date | (None) | ||
| Responsible AD | (None) | ||
| Send notices to | (None) |
draft-tiloca-schc-8824-update-01
SCHC Working Group M. Tiloca
Internet-Draft RISE AB
Updates: 8824 (if approved) L. Toutain
Intended status: Standards Track IMT Atlantique
Expires: 11 January 2024 I. Martinez
Nokia Bell Labs
A. Minaburo
Consultant
10 July 2023
Clarifications and Updates on using Static Context Header Compression
(SCHC) for the Constrained Application Protocol (CoAP)
draft-tiloca-schc-8824-update-01
Abstract
This document clarifies, updates and extends the method specified in
RFC 8824 for compressing Constrained Application Protocol (CoAP)
headers using the Static Context Header Compression and fragmentation
(SCHC) framework. In particular, it considers recently defined CoAP
options and specifies how CoAP headers are compressed in the presence
of intermediaries. Therefore, this document updates RFC 8824.
Discussion Venues
This note is to be removed before publishing as an RFC.
Discussion of this document takes place on the Static Context Header
Compression Working Group mailing list (schc@ietf.org), which is
archived at https://mailarchive.ietf.org/arch/browse/schc/.
Source for this draft and an issue tracker can be found at
https://gitlab.com/crimson84/draft-tiloca-schc-8824-update.
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/.
Tiloca, et al. Expires 11 January 2024 [Page 1]
Internet-Draft Updates on using SCHC for CoAP July 2023
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 January 2024.
Copyright Notice
Copyright (c) 2023 IETF Trust and the persons identified as the
document authors. All rights reserved.
This document is subject to BCP 78 and the IETF Trust's Legal
Provisions Relating to IETF Documents (https://trustee.ietf.org/
license-info) in effect on the date of publication of this document.
Please review these documents carefully, as they describe your rights
and restrictions with respect to this document. Code Components
extracted from this document must include Revised BSD License text as
described in Section 4.e of the Trust Legal Provisions and are
provided without warranty as described in the Revised BSD License.
Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3
1.1. Terminology . . . . . . . . . . . . . . . . . . . . . . . 4
2. CoAP Options . . . . . . . . . . . . . . . . . . . . . . . . 4
2.1. CoAP Option Size1, Size2, Proxy-Uri, and Proxy-Scheme
Fields . . . . . . . . . . . . . . . . . . . . . . . . . 4
2.2. CoAP Option Hop-Limit Field . . . . . . . . . . . . . . . 4
2.3. CoAP Option Echo Field . . . . . . . . . . . . . . . . . 5
2.4. CoAP Option Request-Tag Field . . . . . . . . . . . . . . 5
2.5. CoAP Option EDHOC Field . . . . . . . . . . . . . . . . . 6
3. SCHC Compression of CoAP Extensions . . . . . . . . . . . . . 6
3.1. Block . . . . . . . . . . . . . . . . . . . . . . . . . . 6
3.2. OSCORE . . . . . . . . . . . . . . . . . . . . . . . . . 6
4. Compression of the CoAP Payload Marker . . . . . . . . . . . 10
4.1. Without End-to-End Security . . . . . . . . . . . . . . . 10
4.2. With End-to-End Security . . . . . . . . . . . . . . . . 10
5. CoAP Header Compression with Proxies . . . . . . . . . . . . 11
5.1. Without End-to-End Security . . . . . . . . . . . . . . . 11
5.2. With End-to-End Security . . . . . . . . . . . . . . . . 12
6. Examples of CoAP Header Compression with Proxies . . . . . . 13
6.1. Without End-to-End Security . . . . . . . . . . . . . . . 15
6.2. With End-to-End Security . . . . . . . . . . . . . . . . 22
7. Security Considerations . . . . . . . . . . . . . . . . . . . 36
8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 37
9. References . . . . . . . . . . . . . . . . . . . . . . . . . 37
9.1. Normative References . . . . . . . . . . . . . . . . . . 37
Tiloca, et al. Expires 11 January 2024 [Page 2]
Internet-Draft Updates on using SCHC for CoAP July 2023
9.2. Informative References . . . . . . . . . . . . . . . . . 38
Appendix A. YANG Data Model . . . . . . . . . . . . . . . . . . 39
Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . . . 39
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 39
1. Introduction
The Constrained Application Protocol (CoAP) [RFC7252] is a web-
transfer protocol intended for applications based on the REST
(Representational State Transfer) paradigm, and designed to be
affordable also for resource-constrained devices.
In order to enable the use of CoAP in LPWANs (Low-Power Wide-Area
Networks) as well as to improve performance, [RFC8824] defines how to
use the Static Context Header Compression and fragmentation (SCHC)
framework [RFC8724] for compressing CoAP headers.
This document clarifies, updates and extends the SCHC compression of
CoAP headers defined in [RFC8824] at the application level, by:
providing specific clarifications; updating specific details of the
compression processing, based on recent developments related to the
security protocol OSCORE [RFC8613] for end-to-end protection of CoAP
messages; and extending the compression processing to take into
account additional CoAP options and the presence of CoAP proxies.
In particular, this document updates [RFC8824] as follows.
* It clarifies the SCHC compression for the CoAP options Size1,
Size2, Proxy-Uri and Proxy-Scheme (see Section 2.1).
* It defines the SCHC compression for the CoAP option Hop-Limit (see
Section 2.2).
* It defines the SCHC compression for the recently defined CoAP
options Echo (see Section 2.3), Request-Tag (see Section 2.4),
EDHOC (see Section 2.5), as well as Q-Block1 and Q-Block2 (see
Section 3.1).
* It updates the SCHC compression processing for the CoAP option
OSCORE (see Section 3.2), in the light of recent developments
related to the security protocol OSCORE as defined in
[I-D.ietf-core-oscore-key-update] and
[I-D.ietf-core-oscore-groupcomm].
* It clarifies how the SCHC compression handles the CoAP payload
marker (see Section 4).
Tiloca, et al. Expires 11 January 2024 [Page 3]
Internet-Draft Updates on using SCHC for CoAP July 2023
* It defines the SCHC compression of CoAP headers in the presence of
CoAP proxies (see Section 5).
This document does not alter the core approach, design choices and
features of the SCHC compression applied to CoAP headers.
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 the SCHC framework [RFC8724], the web-transfer protocol
CoAP [RFC7252], the security protocol OSCORE [RFC8613] and the use of
SCHC for CoAP [RFC8824].
2. CoAP Options
This section updates and extends Section 5 of [RFC8824], as to how
SCHC compresses some specific CoAP options. In particular,
Section 2.1 updates Section 5.4 of [RFC8824].
2.1. CoAP Option Size1, Size2, Proxy-Uri, and Proxy-Scheme Fields
The SCHC Rule description MAY define sending some field values by not
setting the TV, while setting the MO to "ignore" and the CDA to
"value-sent". A Rule MAY also use a "match-mapping" MO when there
are different options for the same FID. Otherwise, the Rule sets the
TV to the value, the MO to "equal", and the CDA to "not-sent".
2.2. CoAP Option Hop-Limit Field
The Hop-Limit field is an option defined in [RFC8768] that can be
used to detect forwarding loops through a chain of CoAP proxies. The
first proxy in the chain that understands the option includes it in a
received request with a proper value set, before forwarding the
request. Any following proxy that understands the option decrements
the option value and forwards the request if the new value is
different than zero, or returns a 5.08 (Hop Limit Reached) error
response otherwise.
When a packet uses the Hop-Limit option, SCHC compression SHOULD send
its content in the Compression Residue. That is, in the SCHC Rule,
the TV is not set, while the MO is set to "ignore", and the CDA is
set to "value-sent". As an exception, and consistently with the
Tiloca, et al. Expires 11 January 2024 [Page 4]
Internet-Draft Updates on using SCHC for CoAP July 2023
default value 16 defined for the Hop-Limit option in Section 3 of
[RFC8768], a Rule MAY describe a TV with value 16, with the MO set to
"equal" and the CDA set to "not-sent".
2.3. CoAP Option Echo Field
The Echo field is an option defined in [RFC9175] that a server can
include in a response as a challenge to the client, and that the
client echoes back to the server in one or more requests. This
enables the server to verify the freshness of a request and to
cryptographically verify the aliveness of the client. Also, it
forces the client to demonstrate reachability at its claimed network
address.
When a packet uses the Echo option, SCHC compression SHOULD send its
content in the Compression Residue. That is, in the SCHC Rule, the
TV is not set, while the MO is set to "ignore", and the CDA is set to
"value-sent". An exception applies in case the server generates the
values to use for the Echo option by means of a persistent counter
(see Appendix A of [RFC9175]). In such a case, a Rule MAY use the
"MSB" MO and the "LSB" CDA. This would be effectively applicable
until the persistent counter at the server becomes greater than the
maximum threshold value that produces an MSB-matching.
2.4. CoAP Option Request-Tag Field
The Request-Tag field is an option defined in [RFC9175] that the
client can set in request messages of block-wise operations, with
value an ephemeral short-lived identifier of the specific block-wise
operation in question. This allows the server to match message
fragments belonging to the same request operation and, if the server
supports it, to reliably process simultaneous block-wise request
operations on a single resource. If requests are integrity
protected, this also protects against interchange of fragments
between different block-wise request operations.
When a packet uses the Request-Tag option, SCHC compression MAY send
its content in the Compression Residue. That is, in the SCHC Rule,
the TV is not set, while the MO is set to "ignore", and the CDA is
set to "value-sent". Alternatively, if a pre-defined set of Request-
Tag values used by the client is known, a Rule MAY use a "match-
mapping" MO when there are different options for the same FID.
Tiloca, et al. Expires 11 January 2024 [Page 5]
Internet-Draft Updates on using SCHC for CoAP July 2023
2.5. CoAP Option EDHOC Field
The EDHOC field is an option defined in [I-D.ietf-core-oscore-edhoc]
that a client can include in a request, in order to perform an
optimized, shortened execution of the authenticated key establishment
protocol EDHOC [I-D.ietf-lake-edhoc]. Such a request conveys both
the final EDHOC message and actual application data, where the latter
is protected with OSCORE [RFC8613] using a Security Context derived
from the result of the current EDHOC execution.
The option occurs at most once and is always empty. The SCHC Rule
MUST describe an empty TV, with the MO set to "equal" and the CDA set
to "not-sent".
3. SCHC Compression of CoAP Extensions
This section updates and extends Section 6 of [RFC8824], as to how
SCHC compresses some specific CoAP options providing protocol
extensions. In particular, Section 3.1 updates Section 6.1 of
[RFC8824], while Section 3.2 updates Section 6.4 of [RFC8824].
3.1. Block
When a packet uses a Block1 or Block2 option [RFC7959] or a Q-Block1
or Q-Block2 option [RFC9177], SCHC compression MUST send its content
in the Compression Residue. In the SCHC Rule, the TV is not set,
while the MO is set to "ignore" and the CDA is set to "value-sent".
The Block1, Block2, Q-Block1 and Q-Block2 options allow fragmentation
at the CoAP level that is compatible with SCHC fragmentation. Both
fragmentation mechanisms are complementary, and the node may use them
for the same packet as needed.
3.2. OSCORE
The security protocol OSCORE [RFC8613] provides end-to-end protection
for CoAP messages. Group OSCORE [I-D.ietf-core-oscore-groupcomm]
builds on OSCORE and defines end-to-end protection of CoAP messages
in group communication [I-D.ietf-core-groupcomm-bis]. This section
describes how SCHC Rules can be applied to compress messages
protected with OSCORE or Group OSCORE.
Figure 1 shows the OSCORE option value encoding, which was originally
defined in Section 6.1 of [RFC8613] and has been extended in
[I-D.ietf-core-oscore-key-update][I-D.ietf-core-oscore-groupcomm].
The first byte of the OSCORE option value specifies the content of
the OSCORE option using flags, as follows.
Tiloca, et al. Expires 11 January 2024 [Page 6]
Internet-Draft Updates on using SCHC for CoAP July 2023
* As defined in Section 4.1 of [I-D.ietf-core-oscore-key-update],
the eight least significant bit, when set, indicates that the
OSCORE option includes a second byte of flags. The seventh least
significant bit is currently unassigned.
* As defined in Section 5 of [I-D.ietf-core-oscore-groupcomm], the
sixth least significant bit, when set, indicates that the message
including the OSCORE option is protected with the group mode of
Group OSCORE (see Section 8 of [I-D.ietf-core-oscore-groupcomm]).
When not set, the bit indicates that the message is protected
either with OSCORE, or with the pairwise mode of Group OSCORE (see
Section 9 of [I-D.ietf-core-oscore-groupcomm]), while the specific
OSCORE Security Context used to protect the message determines
which of the two cases applies.
* As defined in Section 6.1 of [RFC8613], bit h, when set, indicates
the presence of the kid context field in the option. Also, bit k,
when set, indicates the presence of a kid field. Finally, the
three least significant bits form the field n, which indicates the
length of the piv (Partial Initialization Vector) field in bytes.
When n = 0, no piv is present.
Assuming the presence of a single flag byte, this is followed by the
piv field, the kid context field, and the kid field, in that order.
Also, if present, the kid context field's length (in bytes) is
encoded in the first byte, denoted by "s".
0 1 2 3 4 5 6 7 <--------- n bytes ------------->
+-+-+-+-+-+-+-+-+---------------------------------+
|0 0 0|h|k| n | Partial IV (if any) |
+-+-+-+-+-+-+-+-+---------------------------------+
| | |
|<-- CoAP -->|<------- CoAP OSCORE_piv ------> |
OSCORE_flags
<-- 1 byte --> <------ s bytes ----->
+--------------+----------------------+-----------------------+
| s (if any) | kid context (if any) | kid (if any) ... |
+--------------+----------------------+-----------------------+
| | |
|<-------- CoAP OSCORE_kidctx ------->|<-- CoAP OSCORE_kid -->|
Figure 1: OSCORE Option
Tiloca, et al. Expires 11 January 2024 [Page 7]
Internet-Draft Updates on using SCHC for CoAP July 2023
Figure 2 shows the OSCORE option value encoding, with the second byte
of flags also present. As defined in Section 4.1 of
[I-D.ietf-core-oscore-key-update], the least significant bit d of
this byte, when set, indicates that two additional fields are
included in the option, following the kid context field (if any).
These two fields, namely x and nonce, are used when running the key
update protocol KUDOS defined in [I-D.ietf-core-oscore-key-update],
with x specifying the length of the nonce field in bytes as well as
the specific behavior to adopt during the KUDOS execution. In
particular, the figure provides the breakdown of the x field, where
its three least significant bits form the sub-field m, which
specifies the size of nonce in bytes, minus 1.
0 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 <----- n bytes ----->
+-+-+-+-+-+-+-+-+---+---+---+---+---+---+---+---+---------------------+
|1|0|0|h|k| n | 0 | 0 | 0 | 0 | 0 | 0 | 0 | d | Partial IV (if any) |
+-+-+-+-+-+-+-+-+---+---+---+---+---+---+---+---+---------------------+
| | |
|<------------------- CoAP -------------------->|<- CoAP OSCORE_piv ->|
OSCORE_flags
<- 1 byte -> <----------- s bytes ------------> <------ 1 byte ----->
+------------+----------------------------------+---------------------+
| s (if any) | kid context (if any) | x (if any) |
+------------+----------------------------------+---------------------+
| | |
|<------------- CoAP OSCORE_kidctx ------------>|<-- CoAP OSCORE_x -->|
| |
| 0 1 2 3 4 5 6 7 |
| +-+-+-+-+-+-+-+-+ |
| |0|0|b|p| m | |
| +-+-+-+-+-+-+-+-+ |
<----- m + 1 bytes ----->
+-------------------------+-----------------------+
| nonce (if any) | kid (if any) ... |
+-------------------------+-----------------------+
| | |
|<-- CoAP OSCORE_nonce -->|<-- CoAP OSCORE_kid -->|
Figure 2: OSCORE Option during a KUDOS execution
Tiloca, et al. Expires 11 January 2024 [Page 8]
Internet-Draft Updates on using SCHC for CoAP July 2023
To better perform OSCORE SCHC compression, the Rule description needs
to identify the OSCORE option and the fields it contains.
Conceptually, it discerns up to six distinct pieces of information
within the OSCORE option: the flag bits, the piv, the kid context,
the x byte, the nonce, and the kid. The SCHC Rule splits the OSCORE
option into six Field Descriptors in order to compress them:
* CoAP OSCORE_flags
* CoAP OSCORE_piv
* CoAP OSCORE_kidctx
* CoAP OSCORE_x
* CoAP OSCORE_nonce
* CoAP OSCORE_kid
Figure 1 shows the OSCORE option format with the four fields
OSCORE_flags, OSCORE_piv, OSCORE_kidctx and OSCORE_kid superimposed
on it. Also, Figure 2 shows the OSCORE option format with all the
six fields superimposed on it, with reference to a message exchanged
during an execution of the KUDOS key update protocol.
In both cases, the CoAP OSCORE_kidctx field directly includes the
size octet, s. In the latter case, the following applies.
* For the x field, if both endpoints know the value, then the SCHC
Rule will describe a TV to this value, with the MO set to "equal"
and the CDA set to "not-sent". This models the case where the two
endpoints run KUDOS with a pre-agreed size of the nonce field, as
well as with a pre-agreed combination of its modes of operations,
as per the bits b and p of the m sub-field.
Otherwise, if the value is changing over time, the SCHC Rule will
set the MO to "ignore" and the CDA to "value-sent". The Rule may
also use a "match-mapping" MO to compress this field, in case the
two endpoints pre-agree on a set of alternative ways to run KUDOS,
with respect to the size of the nonce field and the combination of
the KUDOS modes of operation to use.
* For the nonce field, the SCHC Rule has the TV not set, while the
MO is set to "ignore" and the CDA is set to "value-sent".
In addition, for the value of the nonce field, SCHC MUST NOT send
it as variable-length data in the Compression Residue, to avoid
ambiguity with the length of the nonce field encoded in the x
Tiloca, et al. Expires 11 January 2024 [Page 9]
Internet-Draft Updates on using SCHC for CoAP July 2023
field. Therefore, SCHC MUST use the m sub-field of the x field to
define the size of the Compression Residue. SCHC designates a
specific function, "osc.x.m", that the Rule MUST use to complete
the Field Descriptor. During the decompression, this function
returns the length of the nonce field in bytes, as the value of
the three least significant bits of the m sub-field of the x
field, plus 1.
4. Compression of the CoAP Payload Marker
As originally intended in [RFC8824], the following applies with
respect to the 0xFF payload marker. A SCHC compression Rule for CoAP
includes all the expected CoAP options, therefore the payload marker
does not have to be specified.
4.1. Without End-to-End Security
If the CoAP message to compress with SCHC is not going to be
protected with OSCORE and includes a payload, then the 0xFF payload
marker MUST NOT be included in the compressed message, which is
composed of the Compression RuleID, the Compression Residue (if any),
and the CoAP payload.
After having decompressed an incoming message, the recipient endpoint
MUST prepend the 0xFF payload marker to the CoAP payload, if any was
present after the consumed Compression Residue.
4.2. With End-to-End Security
If the CoAP message has to be protected with OSCORE, the same
rationale described in Section 4.1 applies to both the Inner SCHC
Compression and the Outer SCHC Compression defined in Section 7.2 of
[RFC8824]. That is:
* After the Inner SCHC Compression of a CoAP message including a
payload, the payload marker MUST NOT be included in the input to
the AEAD Encryption, which is composed of the Inner Compression
RuleID, the Inner Compression Residue (if any), and the CoAP
payload.
* The Outer SCHC Compression takes as input the OSCORE-protected
message, which always includes a payload (i.e., the OSCORE
Ciphertext) preceded by the payload marker.
* After the Outer SCHC Compression, the payload marker MUST NOT be
included in the final compressed message, which is composed of the
Outer Compression RuleID, the Outer Compression Residue (if any),
and the OSCORE Ciphertext.
Tiloca, et al. Expires 11 January 2024 [Page 10]
Internet-Draft Updates on using SCHC for CoAP July 2023
After having completed the Outer SCHC Decompression of an incoming
message, the recipient endpoint MUST prepend the 0xFF payload marker
to the OSCORE Ciphertext.
After having completed the Inner SCHC Decompression of an incoming
message, the recipient endpoint MUST prepend the 0xFF payload marker
to the CoAP payload, if any was present after the consumed
Compression Residue.
5. CoAP Header Compression with Proxies
Building on [RFC8824], this section clarifies how SCHC Compression/
Decompression is performed when CoAP proxies are deployed. The
following refers to the origin client and origin server as
application endpoints.
Note that SCHC Compression/Decompression of CoAP headers is not
necessarily used between each pair of hops in the communication
chain. For example, if a proxy is deployed between an origin client
and an origin server, SCHC might be used on the communication leg
between the origin client and the proxy, but not on the communication
leg between the proxy and the origin server.
5.1. Without End-to-End Security
In case OSCORE is not used end-to-end between client and server, the
SCHC processing occurs hop-by-hop, by relying on SCHC Rules that are
consistently shared between two adjacent hops.
In particular, SCHC is used as defined below.
* The sender application endpoint compresses the CoAP message, by
using the SCHC Rules that it shares with the next hop towards the
recipient application endpoint. The resulting, compressed message
is sent to the next hop towards the recipient application
endpoint.
* Each proxy decompresses the incoming compressed message, by using
the SCHC Rules that it shares with the (previous hop towards the)
sender application endpoint.
Then, the proxy compresses the CoAP message to be forwarded, by
using the SCHC Rules that it shares with the (next hop towards
the) recipient application endpoint.
The resulting, compressed message is sent to the (next hop towards
the) recipient application endpoint.
Tiloca, et al. Expires 11 January 2024 [Page 11]
Internet-Draft Updates on using SCHC for CoAP July 2023
* The recipient application endpoint decompresses the incoming
compressed message, by using the SCHC Rules that it shares with
the previous hop towards the sender application endpoint.
5.2. With End-to-End Security
In case OSCORE is used end-to-end between client and server (see
Section 7.2 of [RFC8824]), the following applies.
The SCHC processing occurs end-to-end as to the Inner SCHC
Compression/Decompression, by relying on Inner SCHC Rules that are
consistently shared between the two application endpoints acting as
OSCORE endpoints and sharing the used OSCORE Security Context.
Instead, the SCHC processing occurs hop-by-hop as to the Outer SCHC
Compression/Decompression, by relying on Outer SCHC Rules that are
consistently shared between two adjacent hops.
In particular, SCHC is used as defined below.
* The sender application endpoint performs the Inner SCHC
Compression on the original CoAP message, by using the Inner SCHC
Rules that it shares with the recipient application endpoint.
Following the AEAD Encryption of the compressed input obtained
from the previous step, the sender application endpoint performs
the Outer SCHC Compression on the resulting OSCORE-protected
message, by using the Outer SCHC Rules that it shares with the
next hop towards the recipient application endpoint.
The resulting, compressed message is sent to the next hop towards
the recipient application endpoint.
* Each proxy performs the Outer SCHC Decompression on the incoming
compressed message, by using the SCHC Rules that it shares with
the (previous hop towards the) sender application endpoint.
Then, the proxy performs the Outer SCHC Compression of the OSCORE-
protected message to be forwarded, by using the SCHC Rules that it
shares with the (next hop towards the) recipient application
endpoint.
The resulting, compressed message is sent to the (next hop towards
the) recipient application endpoint.
Tiloca, et al. Expires 11 January 2024 [Page 12]
Internet-Draft Updates on using SCHC for CoAP July 2023
* The recipient application endpoint performs the Outer SCHC
Decompression on the incoming compressed message, by using the
Outer SCHC Rules that it shares with the previous hop towards the
sender application endpoint.
Then, the recipient application endpoint performs the AEAD
Decryption of the OSCORE-protected message obtained from the
previous step.
Finally, the recipient application endpoint performs the Inner
SCHC Decompression on the compressed input obtained from the
previous step, by using the Inner SCHC Rules that it shares with
the sender application endpoint. The result is the original CoAP
message produced by the sender application endpoint.
6. Examples of CoAP Header Compression with Proxies
This section provides examples of SCHC Compression/Decompression in
the presence of a CoAP proxy.
The presented examples refer to the same deployment considered in
Section 2 of [RFC8824], including a Device communicating over LPWAN
with a Network Gateway (NGW), which in turn communicates with an
Application Server over the Internet. The Application Server and the
Device exchange CoAP messages through the NGW.
In addition, the following also applies in the presented examples.
* CoAP request messages are sent only by the Device as targeting the
Application Server (uplink traffic), which replies to the Device
with corresponding CoAP response messages (downlink traffic).
That is, the Device acts as CoAP client, while the Application
Server acts as CoAP server.
* A CoAP proxy is co-located on the Network Gateway (NGW) deployed
between the Application Server and the Device.
* SCHC is used also on the communication leg between the Application
Server and the proxy.
Like [RFC8824], the presented examples focus on SCHC Compression/
Decompression of CoAP headers, i.e., irrespective of possible SCHC
Compression/Decompression applied to further protocol headers.
The example in Section 6.1 considers an exchange of two unprotected
messages, while the example in Section 6.2 considers an exchange of
two messages protected end-to-end with OSCORE. In the examples, the
character | denotes bit concatenation.
Tiloca, et al. Expires 11 January 2024 [Page 13]
Internet-Draft Updates on using SCHC for CoAP July 2023
Figure 3 and Figure 4 show the two CoAP messages exchanged between
the Device and the Application Server, via the proxy. The figures
show the two messages as originally generated by the application at
the two origin endpoints, i.e., before they are possibly protected
end-to-end with OSCORE as considered by the example in Section 6.2.
In particular, note that:
* On the communication leg between the Device and the proxy, the
CoAP Message ID has value 0x0001 and the CoAP Token has value
0x82.
* On the communication leg between the proxy and the Application
Server, the CoAP Message ID has value 0x0004 and the CoAP Token
has value 0x75.
Original message:
=================
0x41010001823b6578616d706c652e636f6d
8b74656d7065726174757265d40f636f6170
Header:
0x4101
01 Ver
00 CON
0001 TKL
00000001 Request Code 1 "GET"
0x0001 = mid
0x82 = token
Options:
0x3b6578616d706c652e636f6d
Option 3: Uri-Host
Value = example.com
0x8b74656d7065726174757265
Option 11: Uri-Path
Value = temperature
0xd40f636f6170
Option 39: Proxy-Scheme
Value = coap
Original message length: 35 bytes
Figure 3: CoAP GET Request
Tiloca, et al. Expires 11 January 2024 [Page 14]
Internet-Draft Updates on using SCHC for CoAP July 2023
Original message:
=================
0x6145000475ff32332043
Header:
0x6145
01 Ver
10 ACK
0001 TKL
01000101 Successful Response Code 69 "2.05 Content"
0x0004 = mid
0x75 = token
0xFF Payload marker
Payload:
0x32332043
Original message length: 10 bytes
Figure 4: CoAP Content Response
6.1. Without End-to-End Security
In case OSCORE is not used end-to-end between the Device and the
Application Server, the following SCHC Rules are shared between the
different entities. Based on those Rules, the SCHC Compression/
Decompression is performed as per Section 5.1.
The Device and the proxy share the SCHC Rule shown in Figure 5, with
RuleID 0.
Tiloca, et al. Expires 11 January 2024 [Page 15]
Internet-Draft Updates on using SCHC for CoAP July 2023
+=====================================================================+
| RuleID 0 |
+==========+=====+===+===+=============+=========+===========+========+
| Field | FL | FP| DI| TV | MO | CDA | Sent |
| | | | | | | | [bits] |
+==========+=====+===+===+=============+=========+===========+========+
| CoAP | 2 | 1 | Bi| 01 | equal | not-sent | |
| version | | | | | | | |
+----------+-----+---+---+-------------+---------+-----------+--------+
| CoAP | 2 | 1 | Up| 0 | equal | not-sent | |
| Type | | | | | | | |
+----------+-----+---+---+-------------+---------+-----------+--------+
| CoAP | 2 | 1 | Dw| [0, 2] | match | matching- | T |
| Type | | | | | mapping | sent | |
+----------+-----+---+---+-------------+---------+-----------+--------+
| CoAP | 4 | 1 | Bi| 1 | equal | not-sent | |
| TKL | | | | | | | |
+----------+-----+---+---+-------------+---------+-----------+--------+
| CoAP | 8 | 1 | Up| [1, 2, | match- | matching- | CC |
| Code | | | | 3, 4] | mapping | sent | |
+----------+-----+---+---+-------------+---------+-----------+--------+
| CoAP | 8 | 1 | Dw| [65, 68, | match- | matching- | CC |
| Code | | | | 69, 132] | mapping | sent | |
+----------+-----+---+---+-------------+---------+-----------+--------+
| CoAP | 16 | 1 | Bi| 0x00 | MSB(12) | LSB | MMMM |
| MID | | | | | | | |
+----------+-----+---+---+-------------+---------+-----------+--------+
| CoAP | tkl | 1 | Bi| 0x80 | MSB(5) | LSB | TTT |
| Token | | | | | | | |
+----------+-----+---+---+-------------+---------+-----------+--------+
| CoAP | var | 1 | Up| | ignore | value- | |
| Uri-Host | (B) | | | | | sent | |
+----------+-----+---+---+-------------+---------+-----------+--------+
| CoAP | var | 1 | Up| temperature | equal | not-sent | |
| Uri-Path | | | | | | | |
+----------+-----+---+---+-------------+---------+-----------+--------+
| CoAP | var | 1 | Up| coap | equal | not-sent | |
| Proxy- | | | | | | | |
| Scheme | | | | | | | |
+----------+-----+---+---+-------------+---------+-----------+--------+
Figure 5: SCHC Rule between the Device and the Proxy
Instead, the proxy and the Application Server share the SCHC Rule
shown in Figure 6, with RuleID 1.
Tiloca, et al. Expires 11 January 2024 [Page 16]
Internet-Draft Updates on using SCHC for CoAP July 2023
+=====================================================================+
| RuleID 1 |
+==========+=====+===+===+=============+=========+===========+========+
| Field | FL | FP| DI| TV | MO | CDA | Sent |
| | | | | | | | [bits] |
+==========+=====+===+===+=============+=========+===========+========+
| CoAP | 2 | 1 | Bi| 01 | equal | not-sent | |
| version | | | | | | | |
+----------+-----+---+---+-------------+---------+-----------+--------+
| CoAP | 2 | 1 | Up| 0 | equal | not-sent | |
| Type | | | | | | | |
+----------+-----+---+---+-------------+---------+-----------+--------+
| CoAP | 2 | 1 | Dw| [0, 2] | match | matching- | T |
| Type | | | | | mapping | sent | |
+----------+-----+---+---+-------------+---------+-----------+--------+
| CoAP | 4 | 1 | Bi| 1 | equal | not-sent | |
| TKL | | | | | | | |
+----------+-----+---+---+-------------+---------+-----------+--------+
| CoAP | 8 | 1 | Up| [1, 2, | match- | matching- | CC |
| Code | | | | 3, 4] | mapping | sent | |
+----------+-----+---+---+-------------+---------+-----------+--------+
| CoAP | 8 | 1 | Dw| [65, 68, | match- | matching- | CC |
| Code | | | | 69, 132] | mapping | sent | |
+----------+-----+---+---+-------------+---------+-----------+--------+
| CoAP | 16 | 1 | Bi| 0x00 | MSB(12) | LSB | MMMM |
| MID | | | | | | | |
+----------+-----+---+---+-------------+---------+-----------+--------+
| CoAP | tkl | 1 | Bi| 0x70 | MSB(5) | LSB | TTT |
| Token | | | | | | | |
+----------+-----+---+---+-------------+---------+-----------+--------+
| CoAP | var | 1 | Up| | ignore | value- | |
| Uri-Host | (B) | | | | | sent | |
+----------+-----+---+---+-------------+---------+-----------+--------+
| CoAP | var | 1 | Up| temperature | equal | not-sent | |
| Uri-Path | | | | | | | |
+----------+-----+---+---+-------------+---------+-----------+--------+
Figure 6: SCHC Rule between the Proxy and the Application Server
First, the Device applies the Rule in Figure 5 shared with the proxy
to the CoAP request in Figure 3. The result is the compressed CoAP
request in Figure 7, which the Device sends to the proxy.
Tiloca, et al. Expires 11 January 2024 [Page 17]
Internet-Draft Updates on using SCHC for CoAP July 2023
Compressed message:
=================
0x00055b2bc30b6b836329731b7b68 (14 bytes)
0x00 RuleID
055b2bc30b6b836329731b7b68 compression residue
and padded payload
Compression Residue (101 bits -> 13 bytes with padding)
0b 00 0001 010 1011 | 0x6578616d706c652e636f6d
code mid tkn Uri-Host (residue size and residue)
Compressed message length: 14 bytes
Figure 7: CoAP GET Request Compressed for the Proxy
Upon receiving the message in Figure 7, the proxy decompresses it
with the Rule in Figure 5 shared with the Device, and obtains the
same CoAP request in Figure 3.
After that, the proxy removes the Proxy-Scheme Option from the
decompressed CoAP request. Also, the proxy replaces the values of
the CoAP Message ID and of the CoAP Token to 0x0004 and 0x75,
respectively. The result is the CoAP request shown in Figure 8.
Tiloca, et al. Expires 11 January 2024 [Page 18]
Internet-Draft Updates on using SCHC for CoAP July 2023
Message to forward:
=================
0x41010004753b6578616d706c652e636f6d
8b74656d7065726174757265
Header:
0x4101
01 Ver
00 CON
0001 TKL
00000001 Request Code 1 "GET"
0x0004 = mid
0x75 = token
Options:
0x3b6578616d706c652e636f6d
Option 3: Uri-Host
Value = example.com
0x8b74656d7065726174757265
Option 11: Uri-Path
Value = temperature
Original message length: 29 bytes
Figure 8: CoAP GET Request to be Compressed by the Proxy
Then, the proxy applies the Rule in Figure 6 shared with the
Application Server to the CoAP request in Figure 8.
The result is the compressed CoAP request in Figure 9, which the
proxy forwards to the Application Server.
Compressed message to forward:
=================
0x0112db2bc30b6b836329731b7b68 (14 bytes)
0x01 RuleID
12db2bc30b6b836329731b7b68 compression residue
and padded payload
Compression Residue (101 bits -> 13 bytes with padding)
0b 00 0100 101 1011 | 0x6578616d706c652e636f6d
code mid tkn Uri-Host (residue size and residue)
Compressed message length: 14 bytes
Tiloca, et al. Expires 11 January 2024 [Page 19]
Internet-Draft Updates on using SCHC for CoAP July 2023
Figure 9: CoAP GET Request Forwarded by the Proxy
Upon receiving the message in Figure 9, the Application Server
decompresses it using the Rule in Figure 6 shared with the proxy.
The result is the same CoAP request in Figure 8, which the
Application Server delivers to the application.
After that, the Application Server produces the CoAP response in
Figure 4, and compresses it using the Rule in Figure 6 shared with
the proxy. The result is the compressed CoAP response shown in
Figure 10, which the Application Server sends to the proxy.
Compressed message:
=================
0x01c94c8cc810c0 (7 bytes)
0x01 RuleID
c94c8cc810c0 compression residue
and padded payload
Compression Residue (10 bits -> 2 bytes with padding)
0b 1 10 0100 101
type code mid tkn
Payload
0x32332043 (4 bytes)
Compressed message length: 7 bytes
Figure 10: CoAP Content Response Compressed for the Proxy
Upon receiving the message in Figure 10, the proxy decompresses it
using the Rule in Figure 6 shared with the Application Server. The
result is the same CoAP response in Figure 4.
Then, the proxy replaces the values of the CoAP Message ID and of the
CoAP Token to 0x0001 and 0x82, respectively. The result is the CoAP
response shown in Figure 11.
Tiloca, et al. Expires 11 January 2024 [Page 20]
Internet-Draft Updates on using SCHC for CoAP July 2023
Message to forward:
=================
0x6145000182ff32332043
Header:
0x6145
01 Ver
10 ACK
0001 TKL
01000101 Successful Response Code 69 "2.05 Content"
0x0001 = mid
0x82 = token
0xFF Payload marker
Payload:
0x32332043
Original message length: 10 bytes
Figure 11: CoAP Content Response to be Compressed by the Proxy
Then, the proxy compresses the CoAP response in Figure 11 with the
Rule in Figure 5 shared with the Device. The result is the
compressed CoAP response shown in Figure 12, which the proxy forwards
to the Device.
Compressed message:
=================
0x00c28c8cc810c0 (7 bytes)
0x00 RuleID
c28c8cc810c0 compression residue
and padded payload
Compression Residue (10 bits -> 2 bytes with padding)
0b 1 10 0001 010
type code mid tkn
Payload
0x32332043 (4 bytes)
Compressed message length: 7 bytes
Figure 12: CoAP Content Response Forwarded by the Proxy
Tiloca, et al. Expires 11 January 2024 [Page 21]
Internet-Draft Updates on using SCHC for CoAP July 2023
Upon receiving the message in Figure 12, the Device decompresses it
using the Rule in Figure 5 shared with the proxy. The result is the
same CoAP request in Figure 11, which the Device delivers to the
application.
6.2. With End-to-End Security
In case OSCORE is used end-to-end between the Device and the
Application Server, the following SCHC Rules are shared between the
different entities. Based on those Rules, the SCHC Compression/
Decompression is performed as per Section 5.2.
The Device and the Application Server share the SCHC Rule shown in
Figure 13, with RuleID 2. The Device and the Application Server use
this Rule to perform the Inner SCHC Compression/Decompression end-to-
end.
+=====================================================================+
| RuleID 2 |
+==========+=====+===+===+=============+=========+===========+========+
| Field | FL | FP| DI| TV | MO | CDA | Sent |
| | | | | | | | [bits] |
+==========+=====+===+===+=============+=========+===========+========+
| CoAP | 8 | 1 | Up| [1, 2, | match- | matching- | CC |
| Code | | | | 3, 4] | mapping | sent | |
+----------+-----+---+---+-------------+---------+-----------+--------+
| CoAP | 8 | 1 | Dw| [65, 68, | match- | matching- | CC |
| Code | | | | 69, 132] | mapping | sent | |
+----------+-----+---+---+-------------+---------+-----------+--------+
| CoAP | var | 1 | Up| temperature | equal | not-sent | |
| Uri-Path | | | | | | | |
+----------+-----+---+---+-------------+---------+-----------+--------+
Figure 13: Inner SCHC Rule between the Device and the Application
Server
The Device and the proxy share the SCHC Rule shown in Figure 14, with
RuleID 3. The Device and the proxy use this Rule to perform the
Outer SCHC Compression/Decompression hop-by-hop on their
communication leg.
+=====================================================================+
| RuleID 3 |
+==========+=====+===+===+=============+=========+===========+========+
| Field | FL | FP| DI| TV | MO | CDA | Sent |
| | | | | | | | [bits] |
+==========+=====+===+===+=============+=========+===========+========+
| CoAP | 2 | 1 | Bi| 01 | equal | not-sent | |
Tiloca, et al. Expires 11 January 2024 [Page 22]
Internet-Draft Updates on using SCHC for CoAP July 2023
| version | | | | | | | |
+----------+-----+---+---+-------------+---------+-----------+--------+
| CoAP | 2 | 1 | Up| 0 | equal | not-sent | |
| Type | | | | | | | |
+----------+-----+---+---+-------------+---------+-----------+--------+
| CoAP | 2 | 1 | Dw| [0, 2] | match | matching- | T |
| Type | | | | | mapping | sent | |
+----------+-----+---+---+-------------+---------+-----------+--------+
| CoAP | 4 | 1 | Bi| 1 | equal | not-sent | |
| TKL | | | | | | | |
+----------+-----+---+---+-------------+---------+-----------+--------+
| CoAP | 8 | 1 | Up| 2 | equal | not-sent | |
| Code | | | | | | | |
+----------+-----+---+---+-------------+---------+-----------+--------+
| CoAP | 8 | 1 | Dw| 68 | equal | not-sent | |
| Code | | | | | | | |
+----------+-----+---+---+-------------+---------+-----------+--------+
| CoAP | 16 | 1 | Bi| 0x00 | MSB(12) | LSB | MMMM |
| MID | | | | | | | |
+----------+-----+---+---+-------------+---------+-----------+--------+
| CoAP | tkl | 1 | Bi| 0x80 | MSB(5) | LSB | TTT |
| Token | | | | | | | |
+----------+-----+---+---+-------------+---------+-----------+--------+
| CoAP | var | 1 | Up| | ignore | value- | |
| Uri-Host | (B) | | | | | sent | |
+----------+-----+---+---+-------------+---------+-----------+--------+
| CoAP | 8 | 1 | Up| 0x09 | equal | not-sent | |
| OSCORE_ | | | | | | | |
| flags | | | | | | | |
+----------+-----+---+---+-------------+---------+-----------+--------+
| CoAP | var | 1 | Up| 0x00 | MSB(4) | LSB | PPPP |
| OSCORE | | | | | | | |
| piv | | | | | | | |
+----------+-----+---+---+-------------+---------+-----------+--------+
| CoAP | var | 1 | Up| 0x0000 | MSB(12) | LSB | KKKK |
| OSCORE_ | | | | | | | |
| kid | | | | | | | |
+----------+-----+---+---+-------------+---------+-----------+--------+
| CoAP | var | 1 | Bi| b'' | equal | not-sent | |
| OSCORE_ | | | | | | | |
| kidctx | | | | | | | |
+----------+-----+---+---+-------------+---------+-----------+--------+
| CoAP | 8 | 1 | Dw| b'' | equal | not-sent | |
| OSCORE_ | | | | | | | |
| flags | | | | | | | |
+----------+-----+---+---+-------------+---------+-----------+--------+
| CoAP | var | 1 | Dw| b'' | equal | not-sent | |
| OSCORE_ | | | | | | | |
Tiloca, et al. Expires 11 January 2024 [Page 23]
Internet-Draft Updates on using SCHC for CoAP July 2023
| piv | | | | | | | |
+----------+-----+---+---+-------------+---------+-----------+--------+
| CoAP | var | 1 | Dw| b'' | equal | not-sent | |
| OSCORE_ | | | | | | | |
| kid | | | | | | | |
+----------+-----+---+---+-------------+---------+-----------+--------+
| CoAP | var | 1 | Up| coap | equal | not-sent | |
| Proxy- | | | | | | | |
| Scheme | | | | | | | |
+----------+-----+---+---+-------------+---------+-----------+--------+
Figure 14: Outer SCHC Rule between the Device and the Proxy
The proxy and the Application Server share the SCHC Rule shown in
Figure 15, with RuleID 4. The proxy and the Application Server use
this Rule to perform the Outer SCHC Compression/Decompression hop-by-
hop on their communication leg.
+=====================================================================+
| RuleID 4 |
+==========+=====+===+===+=============+=========+===========+========+
| Field | FL | FP| DI| TV | MO | CDA | Sent |
| | | | | | | | [bits] |
+==========+=====+===+===+=============+=========+===========+========+
| CoAP | 2 | 1 | Bi| 01 | equal | not-sent | |
| version | | | | | | | |
+----------+-----+---+---+-------------+---------+-----------+--------+
| CoAP | 2 | 1 | Up| 0 | equal | not-sent | |
| Type | | | | | | | |
+----------+-----+---+---+-------------+---------+-----------+--------+
| CoAP | 2 | 1 | Dw| [0, 2] | match | matching- | T |
| Type | | | | | mapping | sent | |
+----------+-----+---+---+-------------+---------+-----------+--------+
| CoAP | 4 | 1 | Bi| 1 | equal | not-sent | |
| TKL | | | | | | | |
+----------+-----+---+---+-------------+---------+-----------+--------+
| CoAP | 8 | 1 | Up| 2 | equal | not-sent | |
| Code | | | | | | | |
+----------+-----+---+---+-------------+---------+-----------+--------+
| CoAP | 8 | 1 | Dw| 68 | equal | not-sent | |
| Code | | | | | | | |
+----------+-----+---+---+-------------+---------+-----------+--------+
| CoAP | 16 | 1 | Bi| 0x00 | MSB(12) | LSB | MMMM |
| MID | | | | | | | |
+----------+-----+---+---+-------------+---------+-----------+--------+
| CoAP | tkl | 1 | Bi| 0x70 | MSB(5) | LSB | TTT |
| Token | | | | | | | |
+----------+-----+---+---+-------------+---------+-----------+--------+
Tiloca, et al. Expires 11 January 2024 [Page 24]
Internet-Draft Updates on using SCHC for CoAP July 2023
| CoAP | var | 1 | Up| | ignore | value- | |
| Uri-Host | (B) | | | | | sent | |
+----------+-----+---+---+-------------+---------+-----------+--------+
| CoAP | 8 | 1 | Up| 0x09 | equal | not-sent | |
| OSCORE_ | | | | | | | |
| flags | | | | | | | |
+----------+-----+---+---+-------------+---------+-----------+--------+
| CoAP | var | 1 | Up| 0x00 | MSB(4) | LSB | PPPP |
| OSCORE | | | | | | | |
| piv | | | | | | | |
+----------+-----+---+---+-------------+---------+-----------+--------+
| CoAP | var | 1 | Up| 0x0000 | MSB(12) | LSB | KKKK |
| OSCORE_ | | | | | | | |
| kid | | | | | | | |
+----------+-----+---+---+-------------+---------+-----------+--------+
| CoAP | var | 1 | Bi| b'' | equal | not-sent | |
| OSCORE_ | | | | | | | |
| kidctx | | | | | | | |
+----------+-----+---+---+-------------+---------+-----------+--------+
| CoAP | 8 | 1 | Dw| b'' | equal | not-sent | |
| OSCORE_ | | | | | | | |
| flags | | | | | | | |
+----------+-----+---+---+-------------+---------+-----------+--------+
| CoAP | var | 1 | Dw| b'' | equal | not-sent | |
| OSCORE_ | | | | | | | |
| piv | | | | | | | |
+----------+-----+---+---+-------------+---------+-----------+--------+
| CoAP | var | 1 | Dw| b'' | equal | not-sent | |
| OSCORE_ | | | | | | | |
| kid | | | | | | | |
+----------+-----+---+---+-------------+---------+-----------+--------+
Figure 15: Outer SCHC Rule between the Proxy and the Application
Server
When the Device applies the Rule in Figure 13 shared with the
Application Server to the CoAP request in Figure 3, this results in
the Compressed Plaintext shown in Figure 16.
As per Section 7.2 of [RFC8824], the message follows the process of
SCHC Inner Compression and encryption until the payload (if any).
The ciphertext resulting from the overall Inner process is used as
payload of the Outer OSCORE message.
Tiloca, et al. Expires 11 January 2024 [Page 25]
Internet-Draft Updates on using SCHC for CoAP July 2023
_____________________________________________________
| |
| OSCORE Plaintext |
| |
| 0x01bb74656d7065726174757265 (13 bytes) |
| |
| 0x01 Request Code GET |
| |
| 0xbb74656d7065726174757265 Option 11: URI_PATH |
| Value = temperature |
|_____________________________________________________|
|
| Inner SCHC Compression
|
v
_________________________________________________
| |
| Compressed Plaintext |
| |
| 0x0200 (2 bytes) |
| |
| |
| RuleID = 0x02 (1 byte) |
| |
| |
| Compression residue |
| and padded payload = 0x00 (1 byte) |
| |
| 0b00 (2 bits match-mapping Compression Residue) |
| 0b000000 (6 bit padding) |
|_________________________________________________|
|
| AEAD Encryption
| (piv = 0x04)
|
v
________________________________________________
| |
| encrypted_plaintext = 0xa2cf (2 bytes) |
| tag = 0xc54fe1b434297b62 (8 bytes) |
| |
| ciphertext = 0xa2cfc54fe1b434297b62 (10 bytes) |
|________________________________________________|
Figure 16: Plaintext Compression and Encryption for the GET Request
Tiloca, et al. Expires 11 January 2024 [Page 26]
Internet-Draft Updates on using SCHC for CoAP July 2023
When the Application Server applies the Rule in Figure 13 shared with
the Device to the CoAP response in Figure 4, this results in the
Compressed Plaintext shown in Figure 17.
As per Section 7.2 of [RFC8824], the message follows the process of
SCHC Inner Compression and encryption until the payload (if any).
The ciphertext resulting from the overall Inner process is used as
payload of the Outer OSCORE message.
Tiloca, et al. Expires 11 January 2024 [Page 27]
Internet-Draft Updates on using SCHC for CoAP July 2023
_________________________________________________
| |
| OSCORE Plaintext |
| |
| 0x45ff32332043 (6 bytes) |
| |
| 0x45 Successful Response Code 69 "2.05 Content" |
| |
| 0xff Payload marker |
| |
| 0x32332043 Payload |
|_________________________________________________|
|
| Inner SCHC Compression
|
v
_________________________________________________
| |
| Compressed Plaintext |
| |
| 0x028c8cc810c0 (6 bytes) |
| |
| |
| RuleID = 0x02 |
| |
| |
| Compression residue |
| and padded payload = 0x8c8cc810c0 (5 bytes) |
| |
| 0b10 (2 bits match-mapping Compression Residue) |
| 0x32332043 >> 2 (shifted payload) |
| 0b000000 Padding |
|_________________________________________________|
|
| AEAD Encryption
| (piv = 0x04)
|
v
_________________________________________________________
| |
| encrypted_plaintext = 0x10c6d7c26cc1 (6 bytes) |
| tag = 0xe9aef3f2461e0c29 (8 bytes) |
| |
| ciphertext = 0x10c6d7c26cc1e9aef3f2461e0c29 (14 bytes) |
|_________________________________________________________|
Tiloca, et al. Expires 11 January 2024 [Page 28]
Internet-Draft Updates on using SCHC for CoAP July 2023
Figure 17: Plaintext Compression and Encryption for the Content
Response
After having performed the SCHC Inner Compression of the CoAP request
in Figure 3, the Device protects it with OSCORE by considering the
Compressed Plaintext in Figure 16. The result is the OSCORE-
protected CoAP request shown in Figure 18.
Protected message:
==================
0x41020001823b6578616d706c652e636f6d
6409040005d411636f6170ffa2cfc54fe1b434297b62
(39 bytes)
Header:
0x4102
01 Ver
00 CON
0001 TKL
00000010 Request Code 2 "POST"
0x0001 = mid
0x82 = token
Options:
0x3b6578616d706c652e636f6d
Option 3: Uri-Host
Value = example.com
0x6409040005
Option 9: OSCORE
Value = 0x09040005
09 = 000 0 1 001 flag byte
h k n
04 piv
0005 kid
0xd411636f6170
Option 39: Proxy-Scheme
Value = coap
0xFF Payload marker
Payload:
0xa2cfc54fe1b434297b62 (10 bytes)
Tiloca, et al. Expires 11 January 2024 [Page 29]
Internet-Draft Updates on using SCHC for CoAP July 2023
Figure 18: Protected and Inner SCHC Compressed CoAP GET Request
Then, the Device applies the Rule in Figure 14 shared with the proxy
to the OSCORE-protected CoAP request in Figure 18, thus performing
the SCHC Outer Compression of such request. The result is the
OSCORE-protected and Outer Compressed CoAP request shown in
Figure 19, which the Device sends to the proxy.
Compressed message:
=================
0x03156caf0c2dae0d8ca5cc6deda8b459f8a9fc3686852f6c40 (25 bytes)
0x03 RuleID
156caf0c2dae0d8ca5cc6deda8b459f8a9fc3686852f6c40 compression
residue and
padded payload
Compression Residue (107 bits -> 14 bytes with padding)
0b 0001 010 1011 | 0x6578616d706c652e636f6d | 0b 0100 0101
mid tkn Uri-Host (residue size and residue) piv kid
Payload
0xa2cfc54fe1b434297b62 (10 bytes)
Compressed message length: 25 bytes
Figure 19: SCHC-OSCORE CoAP GET Request Compressed for the Proxy
Upon receiving the message in Figure 19, the proxy decompresses it
with the Rule in Figure 14 shared with the Device, thus performing
the SCHC Outer Decompression. The result is the same OSCORE-
protected CoAP request in Figure 18.
After that, the proxy removes the Proxy-Scheme Option from the
decompressed OSCORE-protected CoAP request. Also, the proxy replaces
the values of the CoAP Message ID and of the CoAP Token to 0x0004 and
0x75, respectively. The result is the OSCORE-protected CoAP request
shown in Figure 20.
Tiloca, et al. Expires 11 January 2024 [Page 30]
Internet-Draft Updates on using SCHC for CoAP July 2023
Protected message:
==================
0x41020004753b6578616d706c652e636f6d
6409040005ffa2cfc54fe1b434297b62
(33 bytes)
Header:
0x4102
01 Ver
00 CON
0001 TKL
00000010 Request Code 2 "POST"
0x0004 = mid
0x75 = token
Options:
0x3b6578616d706c652e636f6d
Option 3: Uri-Host
Value = example.com
0x6409040005
Option 9: OSCORE
Value = 0x09040005
09 = 000 0 1 001 flag byte
h k n
04 piv
0005 kid
0xFF Payload marker
Payload:
0xa2cfc54fe1b434297b62 (10 bytes)
Figure 20: SCHC-OSCORE CoAP GET Request to be Compressed by the Proxy
Then, the proxy applies the Rule in Figure 15 shared with the
Application Server to the OSCORE-protected CoAP request in Figure 20,
thus performing the SCHC Outer Compression of such request. The
result is the OSCORE-protected and Outer Compressed CoAP request
shown in Figure 21, which the proxy forwards to the Application
Server.
Tiloca, et al. Expires 11 January 2024 [Page 31]
Internet-Draft Updates on using SCHC for CoAP July 2023
Compressed message:
=================
0x044b6caf0c2dae0d8ca5cc6deda8b459f8a9fc3686852f6c40 (25 bytes)
0x04 RuleID
4b6caf0c2dae0d8ca5cc6deda8b459f8a9fc3686852f6c40 compression
residue and
padded payload
Compression Residue (107 bits -> 14 bytes with padding)
0b 0100 101 1011 | 0x6578616d706c652e636f6d | 0b 0100 0101
mid tkn Uri-Host (residue size and residue) piv kid
Payload
0xa2cfc54fe1b434297b62 (10 bytes)
Compressed message length: 25 bytes
Figure 21: SCHC-OSCORE CoAP GET Request Forwarded by the Proxy
Upon receiving the message in Figure 21, the Application Server
decompresses it using the Rule in Figure 15 shared with the proxy,
thus performing the SCHC Outer Decompression. The result is the same
OSCORE-protected CoAP request in Figure 20.
The Application Server decrypts and verifies such a request, which
results in the same Compressed Plaintext in Figure 16. Then, the
Application Server applies the Rule in Figure 13 shared with the
Device to such a Compressed Plaintext, thus performing the SCHC Inner
Decompression. The result is used to rebuild the same CoAP request
in Figure 3, which the Application Server delivers to the
application.
After having performed the SCHC Inner Compression of the CoAP
response in Figure 4, the Application Server protects it with OSCORE
by considering the Compressed Plaintext in Figure 17. The result is
the OSCORE-protected CoAP response shown in Figure 22.
Tiloca, et al. Expires 11 January 2024 [Page 32]
Internet-Draft Updates on using SCHC for CoAP July 2023
Protected message:
==================
0x614400047590ff10c6d7c26cc1e9aef3f2461e0c29
(21 bytes)
Header:
0x6144
01 Ver
10 ACK
0001 TKL
01000100 Successful Response Code 68 "2.04 Changed"
0x0004 = mid
0x75 = token
Options:
0x90
Option 9: OSCORE
Value = b''
0xFF Payload marker
Payload:
0x10c6d7c26cc1e9aef3f2461e0c29 (14 bytes)
Figure 22: Protected and Inner SCHC Compressed CoAP Content Response
Then, the Application Server applies the Rule in Figure 15 shared
with the proxy to the OSCORE-protected CoAP response in Figure 22,
thus performing the SCHC Outer Compression of such response. The
result is the OSCORE-protected and Outer Compressed CoAP response
shown in Figure 23, which the Application Server sends to the proxy.
Tiloca, et al. Expires 11 January 2024 [Page 33]
Internet-Draft Updates on using SCHC for CoAP July 2023
Compressed message:
=================
0x04a510c6d7c26cc1e9aef3f2461e0c29 (16 bytes)
0x04 RuleID
a510c6d7c26cc1e9aef3f2461e0c29 compression residue
and padded payload
Compression Residue (8 bits -> 1 byte with padding)
0b 1 0100 101
type mid tkn
Payload
0x10c6d7c26cc1e9aef3f2461e0c29 (14 bytes)
Compressed message length: 16 bytes
Figure 23: SCHC-OSCORE CoAP Content Response Compressed for the Proxy
Upon receiving the message in Figure 23, the proxy decompresses it
with the Rule in Figure 15 shared with the Application Server, thus
performing the SCHC Outer Decompression. The result is the same
OSCORE-protected CoAP response in Figure 22.
After that, the proxy replaces the values of the CoAP Message ID and
of the CoAP Token to 0x0001 and 0x82, respectively. The result is
the OSCORE-protected CoAP response shown in Figure 24.
Tiloca, et al. Expires 11 January 2024 [Page 34]
Internet-Draft Updates on using SCHC for CoAP July 2023
Protected message:
==================
0x614400018290ff10c6d7c26cc1e9aef3f2461e0c29
(21 bytes)
Header:
0x6144
01 Ver
10 ACK
0001 TKL
01000100 Successful Response Code 68 "2.04 Changed"
0x0001 = mid
0x82 = token
Options:
0x90
Option 9: OSCORE
Value = b''
0xFF Payload marker
Payload:
0x10c6d7c26cc1e9aef3f2461e0c29 (14 bytes)
Figure 24: SCHC-OSCORE CoAP Content Response to be Compressed by
the Proxy
Then, the proxy applies the Rule in Figure 14 shared with the Device
to the OSCORE-protected CoAP response in Figure 24, thus performing
the SCHC Outer Compression of such response. The result is the
OSCORE-protected and Outer Compressed CoAP response shown in
Figure 25, which the proxy forwards to the Device.
Tiloca, et al. Expires 11 January 2024 [Page 35]
Internet-Draft Updates on using SCHC for CoAP July 2023
Compressed message:
=================
0x038a10c6d7c26cc1e9aef3f2461e0c29 (16 bytes)
0x03 RuleID
8a10c6d7c26cc1e9aef3f2461e0c29 compression residue
and padded payload
Compression Residue (8 bits -> 1 byte with padding)
0b 1 0001 010
type mid tkn
Payload
0x10c6d7c26cc1e9aef3f2461e0c29 (14 bytes)
Compressed message length: 15 bytes
Figure 25: SCHC-OSCORE CoAP Content Response Forwarded by the Proxy
Upon receiving the message in Figure 25, the Device decompresses it
using the Rule in Figure 14 shared with the proxy, thus performing
the SCHC Outer Decompression. The result is the same OSCORE-
protected CoAP response in Figure 24.
The Device decrypts and verifies such a response, which results in
the same Compressed Plaintext in Figure 17. Then, the Device applies
the Rule in Figure 13 shared with the Application Server to such a
Compressed Plaintext, thus performing the SCHC Inner Decompression.
The result is used to rebuild the same CoAP response in Figure 4,
which the Device delivers to the application.
7. Security Considerations
The security considerations discussed in [RFC8724] and [RFC8824]
continue to apply. When SCHC is used in the presence of CoAP
proxies, the security considerations discussed in Section 11.2 of
[RFC7252] continue to apply. When SCHC is used with OSCORE, the
security considerations discussed in [RFC8613] continue to apply.
The security considerations in [RFC8824] specifically discuss how the
use of SCHC for CoAP when OSCORE is also used may result in (more
frequently) triggering key-renewal operations for the two endpoints.
This can be due to an earlier exhaustion of the OSCORE Sender
Sequence Number space, or to the installation of new compression
Rules on one of the endpoints.
Tiloca, et al. Expires 11 January 2024 [Page 36]
Internet-Draft Updates on using SCHC for CoAP July 2023
In either case, the two endpoints can run the key update protocol
KUDOS defined in [I-D.ietf-core-oscore-key-update], as the
recommended method to update their shared OSCORE Security Context.
8. IANA Considerations
This document has no actions for IANA.
9. References
9.1. Normative References
[I-D.ietf-core-oscore-edhoc]
Palombini, F., Tiloca, M., Höglund, R., Hristozov, S., and
G. Selander, "Using EDHOC with CoAP and OSCORE", Work in
Progress, Internet-Draft, draft-ietf-core-oscore-edhoc-07,
13 March 2023, <https://datatracker.ietf.org/doc/html/
draft-ietf-core-oscore-edhoc-07>.
[I-D.ietf-core-oscore-groupcomm]
Tiloca, M., Selander, G., Palombini, F., Mattsson, J. P.,
and J. Park, "Group Object Security for Constrained
RESTful Environments (Group OSCORE)", Work in Progress,
Internet-Draft, draft-ietf-core-oscore-groupcomm-18, 22
June 2023, <https://datatracker.ietf.org/doc/html/draft-
ietf-core-oscore-groupcomm-18>.
[I-D.ietf-core-oscore-key-update]
Höglund, R. and M. Tiloca, "Key Update for OSCORE
(KUDOS)", Work in Progress, Internet-Draft, draft-ietf-
core-oscore-key-update-04, 13 March 2023,
<https://datatracker.ietf.org/doc/html/draft-ietf-core-
oscore-key-update-04>.
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119,
DOI 10.17487/RFC2119, March 1997,
<https://www.rfc-editor.org/rfc/rfc2119>.
[RFC7252] Shelby, Z., Hartke, K., and C. Bormann, "The Constrained
Application Protocol (CoAP)", RFC 7252,
DOI 10.17487/RFC7252, June 2014,
<https://www.rfc-editor.org/rfc/rfc7252>.
[RFC7959] Bormann, C. and Z. Shelby, Ed., "Block-Wise Transfers in
the Constrained Application Protocol (CoAP)", RFC 7959,
DOI 10.17487/RFC7959, August 2016,
<https://www.rfc-editor.org/rfc/rfc7959>.
Tiloca, et al. Expires 11 January 2024 [Page 37]
Internet-Draft Updates on using SCHC for CoAP July 2023
[RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC
2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174,
May 2017, <https://www.rfc-editor.org/rfc/rfc8174>.
[RFC8613] Selander, G., Mattsson, J., Palombini, F., and L. Seitz,
"Object Security for Constrained RESTful Environments
(OSCORE)", RFC 8613, DOI 10.17487/RFC8613, July 2019,
<https://www.rfc-editor.org/rfc/rfc8613>.
[RFC8724] Minaburo, A., Toutain, L., Gomez, C., Barthel, D., and JC.
Zuniga, "SCHC: Generic Framework for Static Context Header
Compression and Fragmentation", RFC 8724,
DOI 10.17487/RFC8724, April 2020,
<https://www.rfc-editor.org/rfc/rfc8724>.
[RFC8768] Boucadair, M., Reddy.K, T., and J. Shallow, "Constrained
Application Protocol (CoAP) Hop-Limit Option", RFC 8768,
DOI 10.17487/RFC8768, March 2020,
<https://www.rfc-editor.org/rfc/rfc8768>.
[RFC8824] Minaburo, A., Toutain, L., and R. Andreasen, "Static
Context Header Compression (SCHC) for the Constrained
Application Protocol (CoAP)", RFC 8824,
DOI 10.17487/RFC8824, June 2021,
<https://www.rfc-editor.org/rfc/rfc8824>.
[RFC9175] Amsüss, C., Preuß Mattsson, J., and G. Selander,
"Constrained Application Protocol (CoAP): Echo, Request-
Tag, and Token Processing", RFC 9175,
DOI 10.17487/RFC9175, February 2022,
<https://www.rfc-editor.org/rfc/rfc9175>.
[RFC9177] Boucadair, M. and J. Shallow, "Constrained Application
Protocol (CoAP) Block-Wise Transfer Options Supporting
Robust Transmission", RFC 9177, DOI 10.17487/RFC9177,
March 2022, <https://www.rfc-editor.org/rfc/rfc9177>.
9.2. Informative References
[I-D.ietf-core-groupcomm-bis]
Dijk, E., Wang, C., and M. Tiloca, "Group Communication
for the Constrained Application Protocol (CoAP)", Work in
Progress, Internet-Draft, draft-ietf-core-groupcomm-bis-
08, 11 January 2023,
<https://datatracker.ietf.org/doc/html/draft-ietf-core-
groupcomm-bis-08>.
Tiloca, et al. Expires 11 January 2024 [Page 38]
Internet-Draft Updates on using SCHC for CoAP July 2023
[I-D.ietf-lake-edhoc]
Selander, G., Mattsson, J. P., and F. Palombini,
"Ephemeral Diffie-Hellman Over COSE (EDHOC)", Work in
Progress, Internet-Draft, draft-ietf-lake-edhoc-20, 7 July
2023, <https://datatracker.ietf.org/doc/html/draft-ietf-
lake-edhoc-20>.
Appendix A. YANG Data Model
TBD
Acknowledgments
The authors sincerely thank Christian Amsüss, Quentin Lampin, John
Preuß Mattsson, Carles Gomez Montenegro, Göran Selander, Pascal
Thubert, and Éric Vyncke for their comments and feedback.
The work on this document has been partly supported by the H2020
projects SIFIS-Home (Grant agreement 952652) and ARCADIAN-IoT (Grant
agreement 101020259).
Authors' Addresses
Marco Tiloca
RISE AB
Isafjordsgatan 22
SE-16440 Kista
Sweden
Email: marco.tiloca@ri.se
Laurent Toutain
IMT Atlantique
CS 17607, 2 rue de la Chataigneraie
35576 Cesson-Sevigne Cedex
France
Email: Laurent.Toutain@imt-atlantique.fr
Ivan Martinez
Nokia Bell Labs
12 Rue Jean Bart
91300 Massy
France
Email: ivan.martinez_bolivar@nokia-bell-labs.com
Tiloca, et al. Expires 11 January 2024 [Page 39]
Internet-Draft Updates on using SCHC for CoAP July 2023
Ana Minaburo
Consultant
Rue de Rennes
35510 Cesson-Sevigne
France
Email: anaminaburo@gmail.com
Tiloca, et al. Expires 11 January 2024 [Page 40]