draft-ietf-lpwan-coap-static-context-hc-15.txt   draft-ietf-lpwan-coap-static-context-hc-16.txt 
lpwan Working Group A. Minaburo lpwan Working Group A. Minaburo
Internet-Draft Acklio Internet-Draft Acklio
Intended status: Standards Track L. Toutain Intended status: Standards Track L. Toutain
Expires: January 4, 2021 Institut MINES TELECOM; IMT Atlantique Expires: April 23, 2021 Institut MINES TELECOM; IMT Atlantique
R. Andreasen R. Andreasen
Universidad de Buenos Aires Universidad de Buenos Aires
July 03, 2020 October 20, 2020
LPWAN Static Context Header Compression (SCHC) for CoAP LPWAN Static Context Header Compression (SCHC) for CoAP
draft-ietf-lpwan-coap-static-context-hc-15 draft-ietf-lpwan-coap-static-context-hc-16
Abstract Abstract
This draft defines the way Static Context Header Compression (SCHC) This draft defines how Static Context Header Compression (SCHC) can
header compression can be applied to the Constrained Application be applied to the Constrained Application Protocol (CoAP). SCHC is a
Protocol (CoAP). SCHC is a header compression mechanism adapted for header compression mechanism adapted for constrained devices. SCHC
constrained devices. SCHC uses a static description of the header to uses a static description of the header to reduce the redundancy and
reduce the redundancy and the size of the information in the header. size of the header's information. While RFC 8724 describes the SCHC
While [rfc8724] describes the SCHC compression and fragmentation compression and fragmentation framework, and its application for
framework, and its application for IPv6/UDP headers, this document IPv6/UDP headers, this document applies SCHC for CoAP headers. The
applies the use of SCHC for CoAP headers. The CoAP header structure CoAP header structure differs from IPv6 and UDP since CoAP uses a
differs from IPv6 and UDP since CoAP uses a flexible header with a flexible header with a variable number of options, themselves of
variable number of options, themselves of variable length. The CoAP variable length. The CoAP protocol messages format is asymmetric:
protocol messages format is asymmetric: the request messages have a the request messages have a header format different from the one in
header format different from the one in the response messages. This the response messages. This specification gives guidance on applying
specification gives guidance on how to apply SCHC to flexible headers SCHC to flexible headers and how to leverage the asymmetry for more
and how to leverage the asymmetry for more efficient compression efficient compression Rules.
Rules.
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 January 4, 2021. This Internet-Draft will expire on April 23, 2021.
Copyright Notice Copyright Notice
Copyright (c) 2020 IETF Trust and the persons identified as the Copyright (c) 2020 IETF Trust and the persons identified as the
document authors. All rights reserved. document authors. All rights reserved.
This document is subject to BCP 78 and the IETF Trust's Legal This document is subject to BCP 78 and the IETF Trust's Legal
Provisions Relating to IETF Documents Provisions Relating to IETF Documents
(https://trustee.ietf.org/license-info) in effect on the date of (https://trustee.ietf.org/license-info) in effect on the date of
publication of this document. Please review these documents publication of this document. Please review these documents
carefully, as they describe your rights and restrictions with respect carefully, as they describe your rights and restrictions with respect
to this document. Code Components extracted from this document must to this document. Code Components extracted from this document must
include Simplified BSD License text as described in Section 4.e of include Simplified BSD License text as described in Section 4.e of
the Trust Legal Provisions and are provided without warranty as the Trust Legal Provisions and are provided without warranty as
described in the Simplified BSD License. described in the Simplified BSD License.
Table of Contents Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3
1.1. Terminology . . . . . . . . . . . . . . . . . . . . . . . 4 1.1. Terminology . . . . . . . . . . . . . . . . . . . . . . . 4
2. Applying SCHC to CoAP headers . . . . . . . . . . . . . . . . 4 2. SCHC Applicability to CoAP . . . . . . . . . . . . . . . . . 4
3. CoAP Headers compressed with SCHC . . . . . . . . . . . . . . 6 3. CoAP Headers compressed with SCHC . . . . . . . . . . . . . . 7
3.1. Differences between CoAP and UDP/IP Compression . . . . . 7 3.1. Differences between CoAP and UDP/IP Compression . . . . . 8
4. Compression of CoAP header fields . . . . . . . . . . . . . . 8 4. Compression of CoAP header fields . . . . . . . . . . . . . . 9
4.1. CoAP version field . . . . . . . . . . . . . . . . . . . 8 4.1. CoAP version field . . . . . . . . . . . . . . . . . . . 9
4.2. CoAP type field . . . . . . . . . . . . . . . . . . . . . 8 4.2. CoAP type field . . . . . . . . . . . . . . . . . . . . . 9
4.3. CoAP code field . . . . . . . . . . . . . . . . . . . . . 8 4.3. CoAP code field . . . . . . . . . . . . . . . . . . . . . 9
4.4. CoAP Message ID field . . . . . . . . . . . . . . . . . . 9 4.4. CoAP Message ID field . . . . . . . . . . . . . . . . . . 10
4.5. CoAP Token fields . . . . . . . . . . . . . . . . . . . . 9 4.5. CoAP Token fields . . . . . . . . . . . . . . . . . . . . 10
5. CoAP options . . . . . . . . . . . . . . . . . . . . . . . . 9 5. CoAP options . . . . . . . . . . . . . . . . . . . . . . . . 10
5.1. CoAP Content and Accept options. . . . . . . . . . . . . 10 5.1. CoAP Content and Accept options. . . . . . . . . . . . . 11
5.2. CoAP option Max-Age, Uri-Host and Uri-Port fields . . . . 10 5.2. CoAP option Max-Age, Uri-Host, and Uri-Port fields . . . 11
5.3. CoAP option Uri-Path and Uri-Query fields . . . . . . . . 10 5.3. CoAP option Uri-Path and Uri-Query fields . . . . . . . . 11
5.3.1. Variable length Uri-Path and Uri-Query . . . . . . . 11 5.3.1. Variable-length Uri-Path and Uri-Query . . . . . . . 12
5.3.2. Variable number of path or query elements . . . . . . 11 5.3.2. Variable number of Path or Query elements . . . . . . 12
5.4. CoAP option Size1, Size2, Proxy-URI and Proxy-Scheme 5.4. CoAP option Size1, Size2, Proxy-URI and Proxy-Scheme
fields . . . . . . . . . . . . . . . . . . . . . . . . . 11 fields . . . . . . . . . . . . . . . . . . . . . . . . . 13
5.5. CoAP option ETag, If-Match, If-None-Match, Location-Path 5.5. CoAP option ETag, If-Match, If-None-Match, Location-Path,
and Location-Query fields . . . . . . . . . . . . . . . . 12 and Location-Query fields . . . . . . . . . . . . . . . . 13
6. SCHC compression of CoAP extension RFCs . . . . . . . . . . . 12 6. SCHC compression of CoAP extension RFCs . . . . . . . . . . . 13
6.1. Block . . . . . . . . . . . . . . . . . . . . . . . . . . 12 6.1. Block . . . . . . . . . . . . . . . . . . . . . . . . . . 13
6.2. Observe . . . . . . . . . . . . . . . . . . . . . . . . . 12 6.2. Observe . . . . . . . . . . . . . . . . . . . . . . . . . 13
6.3. No-Response . . . . . . . . . . . . . . . . . . . . . . . 12 6.3. No-Response . . . . . . . . . . . . . . . . . . . . . . . 13
6.4. OSCORE . . . . . . . . . . . . . . . . . . . . . . . . . 12 6.4. OSCORE . . . . . . . . . . . . . . . . . . . . . . . . . 14
7. Examples of CoAP header compression . . . . . . . . . . . . . 14 7. Examples of CoAP header compression . . . . . . . . . . . . . 15
7.1. Mandatory header with CON message . . . . . . . . . . . . 14 7.1. Mandatory header with CON message . . . . . . . . . . . . 15
7.2. OSCORE Compression . . . . . . . . . . . . . . . . . . . 15 7.2. OSCORE Compression . . . . . . . . . . . . . . . . . . . 16
7.3. Example OSCORE Compression . . . . . . . . . . . . . . . 18 7.3. Example OSCORE Compression . . . . . . . . . . . . . . . 19
8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 28 8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 29
9. Security considerations . . . . . . . . . . . . . . . . . . . 28 9. Security considerations . . . . . . . . . . . . . . . . . . . 29
10. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 29 10. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 30
11. Normative References . . . . . . . . . . . . . . . . . . . . 29 11. Normative References . . . . . . . . . . . . . . . . . . . . 30
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 30 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 31
1. Introduction 1. Introduction
CoAP [rfc7252] is designed to easily interop with HTTP (Hypertext CoAP [rfc7252] is a command/response protocol designed for micro-
Transfer Protocol) and is optimized for REST-based (Representational controllers with a small amount of RAM and ROM and is optimized for
state transfer) services. Although CoAP was designed for constrained REST-based (Representational state transfer) services. Although CoAP
devices, the size of a CoAP header still is too large for the was designed for Low-Power Wireless Personal Area Networks (6LoWPAN),
constraints of LPWAN (Low Power Wide Area Networks) and some a CoAP header's size is still too large for LPWAN (Low Power Wide
compression is needed to reduce the header size. Area Networks) and some compression of the CoAP header is required
either to increase performances or allow CoAP other some LPWAN
technologies.
The [rfc8724] defines SCHC, a header compression mechanism for LPWAN The [rfc8724] defines SCHC, a header compression mechanism for the
network based on a static context. Section 5 of the [rfc8724] LPWAN network based on a static context. Section 5 of the [rfc8724]
explains the architecture where compression and decompression are explains the architecture where compression and decompression are
done. The context is known by both ends before transmission. The done. The SCHC compression scheme assumes as a prerequisite that the
way the context is configured, provisioned or exchanged is out of the static context is known to both endpoints before transmission. The
scope of this document. way the context is configured, provisioned or exchanged is out of
this document's scope.
CoAP is an End-to-End protocol at the application level, so CoAP CoAP is an application protocol, so CoAP compression requires
compression requires to install common Rules between two hosts and IP installing common rules between the two SCHC instances. SCHC
Routing may be needed to allow End-to-End communication. Therefore, compression may apply at two different levels: one to compress IP and
SCHC compression may apply at two different levels, one to compress UDP in the LPWAN network and another at the application level for
IP and UDP as described in [rfc8724] in the LPWAN network and another CoAP. These two compressions may be independent. Both follow the
at the application level. These two compressions may be independent. same principle described in RFC8724. SCHC rules driving the
The Compression Rules can be set up by two independent entities and compression/decompression are different and may be managed by
are out of the scope of this document. In both cases, SCHC mechanism different entities. The [rfc8724] describes how the IP and UDP
remains the same. headers may be compressed. This document specifies how the SCHC
compression rules can be applied to CoAP traffic.
SCHC compresses and decompresses headers based on shared contexts SCHC compresses and decompresses headers based on shared contexts
between devices. Each context consists of multiple Rules. Each Rule between devices.
can match header fields and specific values or ranges of values. If Each context consists of multiple Rules. Each Rule can match header
a Rule matches, the matched header fields are substituted by the fields and specific values or ranges of values.
RuleID and optionally some residual bits. Thus, different Rules may If a Rule matches, the matched header fields are replaced by the
correspond to different types of packets that a device expects to RuleID and some residual bits. Thus, different Rules may correspond
send or receive. to divers protocols packets that a device expects to send or receive.
A Rule describes the complete header of the packet with an ordered A Rule describes the packets's entire header with an ordered list of
list of fields descriptions, see section 7 of [rfc8724], thereby each fields descriptions; see section 7 of [rfc8724]. Thereby
description contains the field ID (FID), its length (FL) and its each description contains the field ID (FID), its length (FL), and
position (FP), a direction indicator (DI) (upstream, downstream and its position (FP), a direction indicator (DI) (upstream, downstream,
bidirectional) and some associated Target Values (TV). and bidirectional), and some associated Target Values (TV). The
direction indicator is used for compression to give the best TV to
the FID when these values differ in the transmission direction. So a
field may be described several times depending on the asymmetry of
its possible TVs.
A Matching Operator (MO) is associated to each header field A Matching Operator (MO) is associated with each header field
description. The Rule is selected if all the MOs fit the TVs for all description.
fields of the incoming header. The Rule is selected if all the MOs fit the TVs for all fields of the
incoming header. A rule cannot be selected if the message contains a
field unknown to the SCHC compressor.
In that case, a Compression/Decompression Action (CDA) associated to In that case, a Compression/Decompression Action (CDA) associated
each field defines how the compressed and the decompressed values are with each field give the method to compress and decompress each
computed. Compression mainly results in one of 4 actions: field. Compression mainly results in one of 4 actions:
o send the field value, o send the field value,
o send nothing, o send nothing,
o send some least significant bits of the field or o send some least significant bits of the field or
o send an index. o send an index.
After applying the compression there may be some bits to be sent, After applying the compression, there may be some bits to be sent.
these values are called Compression Residues. These values are called Compression Residues.
SCHC is a general mechanism that can be applied to different SCHC is a general mechanism applied to different protocols, the exact
protocols, the exact Rules to be used depend on the protocol and the Rules to be used depending on the protocol and the application.
application. The section 10 of the [rfc8724] describes the Section 10 of the [rfc8724] describes the compression scheme for IPv6
compression scheme for IPv6 and UDP headers. This document targets and UDP headers.
the CoAP header compression using SCHC. This document targets the CoAP header compression using SCHC.
1.1. Terminology 1.1. Terminology
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and
"OPTIONAL" in this document are to be interpreted as described in BCP "OPTIONAL" in this document are to be interpreted as described in BCP
14 [RFC2119][rfc8174] when, and only when, they appear in all 14 [RFC2119][rfc8174] when, and only when, they appear in all
capitals, as shown here. capitals, as shown here.
2. Applying SCHC to CoAP headers 2. SCHC Applicability to CoAP
The SCHC Compression Rules can be applied to CoAP headers. SCHC The SCHC Compression Rules can be applied to CoAP headers. SCHC
Compression of the CoAP header MAY be done in conjunction with the Compression of the CoAP header MAY be done in conjunction with the
lower layers (IPv6/UDP) or independently. The SCHC adaptation layers lower layers (IPv6/UDP) or independently. The SCHC adaptation
as described in Section 5 of [rfc8724] and may be used as shown in layers, described in Section 5 of [rfc8724], may be used, as shown in
Figure 1, Figure 2 and Figure 3. Figure 1,Figure 2 and Figure 3
In the first example, Figure 1, a Rule compresses the complete header
In the first example Figure 1, a Rule compresses the complete header
stack from IPv6 to CoAP. In this case, SCHC C/D (Static Context stack from IPv6 to CoAP. In this case, SCHC C/D (Static Context
Header Compression Compressor/Decompressor) is performed at the Header Compression Compressor/Decompressor) is performed at the
Sender and at the Receiver. The host communicating with the device device and the application. The host communicating with the device
do not implement SCHC C/D. does not implement SCHC C/D.
(device) (NGW) (internet) (App) (device) (NGW) (App)
+--------+ +--------+ +--------+ +--------+
| CoAP | | CoAP | | CoAP | | CoAP |
+--------+ +--------+ +--------+ +--------+
| UDP | | UDP | | UDP | | UDP |
+--------+ +----------------+ +--------+ +--------+ +----------------+ +--------+
| IPv6 | | IPv6 | | IPv6 | | IPv6 | | IPv6 | | IPv6 |
+--------+ +--------+-------+ +--------+ +--------+ +--------+-------+ +--------+
| SCHC | | SCHC | | | | | SCHC | | SCHC | | | |
+--------+ +--------+ + + + +--------+ +--------+ + + +
| LPWAN | | LPWAN | | | | | LPWAN | | LPWAN | | | |
+--------+ +--------+-------+ +--------+ +--------+ +--------+-------+ +--------+
((((((())))))) ----- ------ ------ ----- ((((LPWAN)))) ------ Internet ------
Figure 1: Compression/decompression at the LPWAN bondary Figure 1: Compression/decompression at the LPWAN boundary
The SCHC can be viewed as a layer above layer 2. This layer received
non-encrypted packets and can apply compression rule to all the
headers. On the other end, the NGW receives the SCHC packet and
reconstructs the headers from the rule, identified by its ID and the
header residues. The result is a regular IPv6 packet that can be
forwarded toward the destination. The same process applies in the
other direction. A not encrypted packet arrived at the NGW, thanks
to IP forwarding based on the IPv6 prefix. The NGW identifies the
device and compresses headers using the device's rules.
In the second example, Figure 2, the SCHC compression is applied in In the second example, Figure 2, the SCHC compression is applied in
the CoAP layer, compressing the CoAP header independently of the the CoAP layer, compressing the CoAP header independently of the
other layers. The RuleID and the Compression Residue are encrypted other layers. The RuleID, the Compression Residue, and CoAP payload
using a mechanism such as DTLS. Only the other end can decipher the are encrypted using a mechanism such as DTLS. Only the other end
information. If needed, layers below use SCHC to compress the header (App) can decipher the information. If needed, layers below use SCHC
as defined in [rfc8724] document. This use case realizes an End-to- to compress the header as defined in [rfc8724] document (represented
End context initialization between the sender and the receiver and is in dotted lines).
out-of-scope of this document.
(device) (NGW) (internet) (App) This use case needs an end-to-end context initialization between the
device and the application and is out-of-scope of this document.
+--------+ +--------+ (device) (NGW) (App)
| CoAP | | CoAP |
+--------+ +--------+
| SCHC | | SCHC |
+--------+ +--------+
| DTLS | | DTLS |
+--------+ +--------+
. udp . . udp .
.......... .................. ..........
. ipv6 . . ipv6 . . ipv6 .
.......... .................. ..........
. schc . . schc . . . .
.......... .......... . . .
. lpwan . . lpwan . . . .
.......... .................. ..........
((((((())))))) ----- ------ ------ -----
Figure 2: Standalone CoAP ene-to-end compression/decompression +--------+ +--------+
| CoAP | | CoAP |
+--------+ +--------+
| SCHC | | SCHC |
+--------+ +--------+
| DTLS | | DTLS |
+--------+ +--------+
. udp . . udp .
.......... .................. ..........
. ipv6 . . ipv6 . . ipv6 .
.......... .................. ..........
. schc . . schc . . . .
.......... .......... . . .
. lpwan . . lpwan . . . .
.......... .................. ..........
((((LPWAN)))) ------ Internet ------
In the third example, Figure 3 the Object Security for Constrained Figure 2: Standalone CoAP end-to-end compression/decompression
In the third example, Figure 3, the Object Security for Constrained
RESTful Environments (OSCORE) [rfc8613] is used. In this case, two RESTful Environments (OSCORE) [rfc8613] is used. In this case, two
rulesets are used to compress the CoAP message. A first ruleset rulesets are used to compress the CoAP message. A first ruleset
focused on the inner header and is applied end to end by both ends. focused on the inner header compresses it. The result is encrypted
A second ruleset compresses the outer header and the layers below and using the OSCORE mechanism. A second ruleset compresses the outer
is done between the Sender and the Receiver. header, including the OSCORE Options.
(device) (NGW) (internet) (App) (device) (NGW) (App)
+--------+ +--------+ +--------+ +--------+
| CoAP | | CoAP | | CoAP | | CoAP |
| inner | | inner | | inner | | inner |
+--------+ +--------+ +--------+ +--------+
| SCHC | | SCHC | | SCHC | | SCHC |
+--------+ +--------+ | inner | | inner |
| CoAP | | CoAP | +--------+ +--------+
| outer | | outer | | CoAP | | CoAP |
+--------+ +--------+ | outer | | outer |
. udp . . udp . +--------+ +--------+
.......... .................. .......... | SCHC | | SCHC |
. ipv6 . . ipv6 . . ipv6 . | outer | | outer |
.......... .................. .......... +--------+ +--------+
. schc . . schc . . . . . udp . . udp .
.......... .......... . . . .......... .................. ..........
. lpwan . . lpwan . . . . . ipv6 . . ipv6 . . ipv6 .
.......... .................. .......... .......... .................. ..........
((((((())))))) ----- ------ ------ ----- . schc . . schc . . . .
.......... .......... . . .
. lpwan . . lpwan . . . .
.......... .................. ..........
((((LPWAN)))) ------ Internet ------
Figure 3: OSCORE compression/decompression. Figure 3: OSCORE compression/decompression.
In case of 2 rule-sets, as shown in Figure 2 and Figure 3, they may In the case of several SCHC instances, as shown in Figure 3 and
come from different provisioning domains, and that they do not Figure 3, the rulesets may come from different provisioning domains.
include the cryptography part that is done in between the two SCHC
activities. This document focuses on CoAP compression represented in This document focuses on CoAP compression represented in the dashed
the dashed boxes in the previous figures. boxes in the previous figures.
3. CoAP Headers compressed with SCHC 3. CoAP Headers compressed with SCHC
The use of SCHC over the CoAP header uses the same description and The use of SCHC over the CoAP header uses the same description and
compression/decompression techniques as the one for IP and UDP compression/decompression techniques like the one for IP and UDP
explained in the [rfc8724]. For CoAP, SCHC Rules description uses explained in the [rfc8724]. For CoAP, SCHC Rules description uses
the direction information to optimize the compression by reducing the the direction information to optimize the compression by reducing the
number of Rules needed to compress headers. The field description number of Rules needed to compress headers. The field description
MAY define both request/response headers and target values in the MAY define both request/response headers and target values in the
same Rule, using the DI (direction indicator) to make the difference. same Rule, using the DI (direction indicator) to make the difference.
As for other protocols, when the compressor does not find a correct
Rule to compress the header, the packet MUST be sent uncompressed As for other header compression protocols, when the compressor does
using the RuleID dedicated to this purpose, and the Compression not find a correct Rule to compress the header, the packet MUST be
Residue is the complete header of the packet. See section 6 of sent uncompressed using the RuleID dedicated to this purpose. Where
[rfc8724]. the Compression Residue is the complete header of the packet. See
section 6 of [rfc8724].
3.1. Differences between CoAP and UDP/IP Compression 3.1. Differences between CoAP and UDP/IP Compression
CoAP compression differs from IPv6 and UDP compression on the CoAP compression differs from IPv6 and UDP compression on the
following aspects: following aspects:
o The CoAP protocol is asymmetric, the headers are different for a o The CoAP protocol is asymmetric; the headers are different for a
request or a response. For example, the URI-path option is request or a response. For example, the URI-Path option is
mandatory in the request, and it is not present in the response, a mandatory in the request, and it may not be present in the
request may contain an Accept option, and the response may include response. A request may contain an Accept option, and the
a Content option. In comparison, IPv6 and UDP returning path swap response may include a Content-Format option. In comparison, IPv6
the value of some fields in the header. and UDP returning path swap the value of some fields in the
But all the directions have the same fields (e.g., source and header. But all the directions have the same fields (e.g., source
destination addresses fields). and destination address fields).
The [rfc8724] defines the use of a Direction Indicator (DI) in the The [rfc8724] defines the use of a Direction Indicator (DI) in the
Field Description, which allows a single Rule to process message Field Descriptor, which allows a single Rule to process a message
headers differently depending on the direction. headers differently depending on the direction.
o Even when a field is "symmetric" (i.e., found in both directions), o Even when a field is "symmetric" (i.e., found in both directions),
the values carried in each direction are different. the values carried in each direction are different.
The compression may use a matching list in the TV to limit the The compression may use a matching list in the TV to limit the
range of expected values in a particular direction and therefore range of expected values in a particular direction and therefore
reduces the size of the Compression Residue. Through the reduce the Compression Residue's size. Through the Direction
Direction Indicator (DI), a field description in the Rules splits Indicator (DI), a field description in the Rules splits the
the possible field value into two parts, one for each direction. possible field value into two parts, one for each direction. For
For instance, if a client sends only CON requests, the type can be instance, if a client sends only CON requests, the type can be
elided by compression, and the answer may use one single bit to elided by compression, and the answer may use one single bit to
carry either the ACK or RST type. The field Code have as well the carry either the ACK or RST type. The field Code has the same
same behavior, the 0.0X code format value in the request and Y.ZZ behavior, the 0.0X code format value in the request, and Y.ZZ code
code format in the response. format in the response.
o Headers in IPv6 and UDP have a fixed size. The size is not sent o Headers in IPv6 and UDP have a fixed size. The size is not sent
as part of the Compression Residue, but is defined in the Rule. as part of the Compression Residue but is defined in the Rule.
Some CoAP header fields have variable lengths, so the length is Some CoAP header fields have variable lengths, so the length is
also specified in the Field Description. For example, the Token also specified in the Field Description. For example, the Token
size may vary from 0 to 8 bytes. And the CoAP options have a size may vary from 0 to 8 bytes. And the CoAP options have a
variable length since they use the Type-Length-Value encoding variable length since they use the Type-Length-Value encoding
format, as URI-path or URI-query. format, as URI-path or URI-query.
Section 7.5.2 from [rfc8724] offers the possibility to define a Section 7.5.2 from [rfc8724] offers the possibility to define a
function for the Field length in the Field Description to have function for the Field length in the Field Description to know the
knowledge of the length before compression. When doing SCHC length before compression. When doing SCHC compression of a
compression of a variable-length field, variable-length field,
if the field size is not known, the Field Length in the Rule is if the field size is unknown, the Field Length in the Rule is set
set as variable and the size is sent with the Compression Residue. as variable, and the size is sent with the Compression Residue.
o A field can appear several time in the CoAP headers. This is o A field can appear several times in the CoAP headers. This is
typical for elements of a URI (path or queries). The SCHC typical for elements of a URI (path or queries). The SCHC
specification [rfc8724] allows a Field ID to appear several times specification [rfc8724] allows a Field ID to appear several times
in the Rule, and uses the Field Position (FP) to identify the in the Rule and uses the Field Position (FP) to identify the
correct instance, and thereby removing the ambiguity of the correct instance, and thereby removing the ambiguity of the
matching operation. matching operation.
o Field sizes defined in the CoAP protocol can be too large o Field sizes defined in the CoAP protocol can be too
regarding LPWAN traffic constraints. This is particularly true large regarding LPWAN traffic constraints. This is particularly
for the Message ID field and the Token field. SCHC uses different true for the Message-ID field and the Token field. SCHC uses
Matching operators (MO) to perform the compression, see section different Matching operators (MO) to perform the compression. See
7.4 of [rfc8724]. In this case the Most Significant Bits (MSB) MO section 7.4 of [rfc8724]. In this case, the Most Significant Bits
can be applied to reduce the information carried on LPWANs. (MSB) MO can be applied to reduce the information carried on
LPWANs.
4. Compression of CoAP header fields 4. Compression of CoAP header fields
This section discusses the compression of the different CoAP header This section discusses the compression of the different CoAP header
fields. The CoAP compression with SCHC follows the Section 7.1 of fields. The CoAP compression with SCHC follows the Section 7.1 of
[rfc8724]. [rfc8724].
4.1. CoAP version field 4.1. CoAP version field
CoAP version is bidirectional and MUST be elided during the SCHC CoAP version is bidirectional and MUST be elided during the SCHC
compression, since it always contains the same value. In the future, compression since it always contains the same value. In the future,
if new versions of CoAP are defined, new Rules will be needed to if new versions of CoAP are defined, new Rules will be needed to
avoid ambiguities between versions. avoid ambiguities between versions.
4.2. CoAP type field 4.2. CoAP type field
The CoAP Protocol [rfc7252] has four type of messages: two request The CoAP Protocol [rfc7252] has four types of messages: two requests
(CON, NON); one response (ACK) and one empty message (RST). (CON, NON), one response (ACK), and one empty message (RST).
The field SHOULD be elided if for instance a client is sending only The field SHOULD be elided if, for instance, a client is sending only
NON or only CON messages. For the RST message a dedicated Rule may NON or only CON messages. For the RST message, a dedicated Rule may
be needed. For other usages a mapping list can be used. be needed. For other usages, a mapping list can be used.
4.3. CoAP code field 4.3. CoAP code field
The code field indicates the Request Method used in CoAP, a IANA The code field indicates the Request Method used in CoAP, an IANA
registry [rfc7252]. The compression of the CoAP code field follows registry [rfc7252]. The compression of the CoAP code field follows
the same principle as that of the CoAP type field. If the device the same principle as that of the CoAP type field. If the device
plays a specific role, the set of code values can be split in two plays a specific role, the set of code values can be split into two
parts, the request codes with the 0 class and the response values. parts, the request codes with the 0 class and the response values.
If the device only implements a CoAP client, the request code can be If the device only implements a CoAP client, the request code can be
reduced to the set of requests the client is able to process. reduced to the set of requests the client can to process.
A mapping list can be used for known values. For other values the A mapping list can be used for known values. The field cannot be
field cannot be compressed an the value needs to be sent in the compressed for other values, and the value needs to be sent in the
Compression Residue. Compression Residue.
4.4. CoAP Message ID field 4.4. CoAP Message ID field
The Message ID field can be compressed with the MSB(x) MO and the The Message ID field can be compressed with the MSB(x) MO and the
Least Significant Bits (LSB) CDA, see section 7.4 of [rfc8724]. Least Significant Bits (LSB) CDA. See section 7.4 of [rfc8724].
4.5. CoAP Token fields 4.5. CoAP Token fields
Token is defined through two CoAP fields, Token Length in the A Token is defined through two CoAP fields, Token Length in the
mandatory header and Token Value directly following the mandatory mandatory header and Token Value directly following the mandatory
CoAP header. CoAP header.
Token Length is processed as any protocol field. If the value does Token Length is processed as any protocol field. If the value does
not change, the size can be stored in the TV and elided during the not change, the size can be stored in the TV and elided during the
transmission. Otherwise, it will have to be sent in the Compression transmission. Otherwise, it will have to be sent in the Compression
Residue. Residue.
Token Value MUST NOT be sent as a variable length residue to avoid Token Value MUST NOT be sent as a variable-length residue to avoid
ambiguity with Token Length. Therefore, Token Length value MUST be ambiguity with Token Length. Therefore, the Token Length value MUST
used to define the size of the Compression Residue. A specific be used to define the size of the Compression Residue. A specific
function designated as "TKL" MUST be used in the Rule. During the function designated as "TKL" MUST be used in the Rule. During the
decompression, this function returns the value contained in the Token decompression, this function returns the value contained in the Token
Length field. Length field.
5. CoAP options 5. CoAP options
CoAP defines options that are placed after the based header in Option CoAP defines options that are placed after the based header in Option
Numbers order, see [rfc7252]. Each Option instance in a message uses Numbers order, see [rfc7252]. Each Option instance in a message uses
the format Delta-Type (D-T), Length (L), Value (V). When applying the format Delta-Type (D-T), Length (L), Value (V). When applying
SCHC compression to the Option, the D-T, L, and V format serves to SCHC compression to the Option, the D-T, L, and V format serve to
make the Rule description of the Option. The SCHC compression builds make the Rule description of the Option. The SCHC compression builds
the description of the Option by using in the Field ID the Option the description of the Option by using in the Field ID the Option
Number built from D-T; in TV, the Option Value; and the Option Length Number built from D-T; in TV, the Option Value; and the Option Length
uses section 7.4 of RFC8724. When the Option Length has a wellknown uses section 7.4 of [rfc8724]. When the Option Length has a
size it can be stored in the Rule. Therefore, SCHC compression does wellknown size, it can be stored in the Rule. Therefore, SCHC
not send it. Otherwise, SCHC Compression carries the length of the compression does not send it. Otherwise, SCHC Compression carries
Compression Residue in addition to the Compression Residue value. the length of the Compression Residue, in addition to the Compression
Residue value.
CoAP request and response do not include the same options. So CoAP requests and responses do not include the same options. So
Compression Rules may reflect these assymetry by tagging the Compression Rules may reflect this asymmetry by tagging the direction
direction indicator. indicator.
Note that length coding differs between CoAP options and SCHC Note that length coding differs between CoAP options and SCHC
variable size Compression Residue. variable size Compression Residue.
The following sections present how SCHC compresses some specific CoAP The following sections present how SCHC compresses some specific CoAP
Options. options.
If a new option is introduced in CoAP, a new Field ID has to be
assigned in the Rules to allow its compression. Otherwise, if no
Rule describes this Option, the SCHC compression is not possible, and
the CoAP header is sent without compression.
5.1. CoAP Content and Accept options. 5.1. CoAP Content and Accept options.
If a single value is expected by the client, it can be stored in the If the client expects a single value, it can be stored in the TV and
TV and elided during the transmission. Otherwise, if several elided during the transmission. Otherwise, if the client expects
possible values are expected by the client, a matching-list SHOULD be several possible values, a matching-list SHOULD be used to limit the
used to limit the size of the Compression Residue. Otherwise, the Compression Residue's size. Otherwise, the value has to be sent as a
value has to be sent as a Compression Residue (fixed or variable Compression Residue (fixed or variable length).
length).
5.2. CoAP option Max-Age, Uri-Host and Uri-Port fields 5.2. CoAP option Max-Age, Uri-Host, and Uri-Port fields
If the duration is known by both ends, the value can be elided. If both ends know the value, the value can be elided.
A matching list can be used if some well-known values are defined. A matching list can be used if some well-known values are defined.
Otherwise these options can be sent as a Compression Residue (fixed Otherwise, these options can be sent as a Compression Residue.
or variable length).
5.3. CoAP option Uri-Path and Uri-Query fields 5.3. CoAP option Uri-Path and Uri-Query fields
Uri-Path and Uri-Query elements are a repeatable options, the Field Uri-Path and Uri-Query elements are repeatable options. The Field
Position (FP) gives the position in the path. Position (FP) gives the position in the path.
A Mapping list can be used to reduce the size of variable Paths or A Mapping list can be used to reduce the size of variable Paths or
Queries. In that case, to optimize the compression, several elements Queries. In that case, to optimize the compression, several elements
can be regrouped into a single entry. Numbering of elements do not can be regrouped into a single entry. The Numbering of elements do
change, MO comparison is set with the first element of the matching. not change; MO comparison is set with the first element of the
matching.
+-------------+---+--+--+--------+---------+-------------+ +-------------+---+--+--+--------+---------+-------------+
| Field |FL |FP|DI| Target | Match | CDA | | Field |FL |FP|DI| Target | Match | CDA |
| | | | | Value | Opera. | | | | | | | Value | Opera. | |
+-------------+---+--+--+--------+---------+-------------+ +-------------+---+--+--+--------+---------+-------------+
|URI-Path | | 1|up|["/a/b",|equal |not-sent | |Uri-Path | | 1|up|["/a/b",|equal |not-sent |
| | | | |"/c/d"] | | | | | | | |"/c/d"] | | |
|URI-Path |var| 3|up| |ignore |value-sent | |Uri-Path |var| 3|up| |ignore |value-sent |
+-------------+---+--+--+--------+---------+-------------+ +-------------+---+--+--+--------+---------+-------------+
Figure 4: complex path example Figure 4: complex path example
In Figure 4 a single bit residue can be used to code one of the 2 In Figure 4, a single bit residue can be used to code one of the 2
paths. If regrouping were not allowed, a 2 bits residue would be paths. If regrouping were not allowed, a 2 bits residue would be
needed. The third path element is sent as a variable size residue. needed. The third path element is sent as a variable size residue.
5.3.1. Variable length Uri-Path and Uri-Query 5.3.1. Variable-length Uri-Path and Uri-Query
When the length is not known at the Rule creation, the Field Length When the length is not known at the Rule creation, the Field Length
MUST be set to variable, and the unit is set to bytes. MUST be set to variable, and the unit is set to bytes.
The MSB MO can be applied to a Uri-Path or Uri-Query element. Since The MSB MO can be applied to a Uri-Path or Uri-Query element. Since
MSB value is given in bit, the size MUST always be a multiple of 8 MSB value is given in bit, the size MUST always be a multiple of 8
bits. bits.
The length sent at the beginning of a variable length residue The length sent at the beginning of a variable-length residue
indicates the size of the LSB in bytes. indicates the size of the LSB in bytes.
For instance for a CORECONF path /c/X6?k="eth0" the Rule can be set For instance, for a CORECONF path /c/X6?k="eth0" the Rule can be set
to: to:
+-------------+---+--+--+--------+---------+-------------+ +-------------+---+--+--+--------+---------+-------------+
| Field |FL |FP|DI| Target | Match | CDA | | Field |FL |FP|DI| Target | Match | CDA |
| | | | | Value | Opera. | | | | | | | Value | Opera. | |
+-------------+---+--+--+--------+---------+-------------+ +-------------+---+--+--+--------+---------+-------------+
|URI-Path | 8| 1|up|"c" |equal |not-sent | |Uri-Path | 8| 1|up|"c" |equal |not-sent |
|URI-Path |var| 2|up| |ignore |value-sent | |Uri-Path |var| 2|up| |ignore |value-sent |
|URI-Query |var| 1|up|"k=" |MSB(16) |LSB | |Uri-Query |var| 1|up|"k=" |MSB(16) |LSB |
+-------------+---+--+--+--------+---------+-------------+ +-------------+---+--+--+--------+---------+-------------+
Figure 5: CORECONF URI compression Figure 5: CORECONF URI compression
Figure 5 shows the parsing and the compression of the URI, where c is Figure 5 shows the parsing and the compression of the URI, where c is
not sent. The second element is sent with the length (i.e. 0x2 X 6) not sent. The second element is sent with the length (i.e., 0x2 X 6)
followed by the query option (i.e. 0x05 "eth0"). followed by the query option (i.e. 0x05 "eth0").
5.3.2. Variable number of path or query elements 5.3.2. Variable number of Path or Query elements
The number of Uri-path or Uri-Query elements in a Rule is fixed at The number of Uri-Path or Uri-Query elements in a Rule is fixed at
the Rule creation time. If the number varies, several Rules SHOULD the Rule creation time. If the number varies, several Rules SHOULD
be created to cover all the possibilities. Another possibility is to be created to cover all the possibilities. Another possibility is to
define the length of Uri-Path to variable and send a Compression define the length of Uri-Path to variable and send a Compression
Residue with a length of 0 to indicate that this Uri-Path is empty. Residue with a length of 0 to indicate that this Uri-Path is empty.
This adds 4 bits to the variable Residue size. See section 7.5.2 This adds 4 bits to the variable Residue size. See section 7.5.2
[rfc8724] [rfc8724]
5.4. CoAP option Size1, Size2, Proxy-URI and Proxy-Scheme fields 5.4. CoAP option Size1, Size2, Proxy-URI and Proxy-Scheme fields
If the field value has to be sent, TV is not set, MO is set to If the field value has to be sent, TV is not set, MO is set to
"ignore" and CDA is set to "value-sent". A mapping MAY also be used. "ignore", and CDA is set to "value-sent." A mapping MAY also be
used.
Otherwise, the TV is set to the value, MO is set to "equal" and CDA Otherwise, the TV is set to the value, MO is set to "equal", and CDA
is set to "not-sent". is set to "not-sent".
5.5. CoAP option ETag, If-Match, If-None-Match, Location-Path and 5.5. CoAP option ETag, If-Match, If-None-Match, Location-Path, and
Location-Query fields Location-Query fields
These fields values cannot be stored in a Rule entry. They MUST These fields' values cannot be stored in a Rule entry. They MUST
always be sent with the Compression Residues. always be sent with the Compression Residues.
6. SCHC compression of CoAP extension RFCs 6. SCHC compression of CoAP extension RFCs
6.1. Block 6.1. Block
Block [rfc7959] allows a fragmentation at the CoAP level. SCHC also Block [rfc7959] allows a fragmentation at the CoAP level. SCHC also
includes a fragmentation protocol. They can be both used. If a includes a fragmentation protocol. They can be both used. If a
block option is used, its content MUST be sent as a Compression block option is used, its content MUST be sent as a Compression
Residue. Residue.
6.2. Observe 6.2. Observe
The [rfc7641] defines the Observe option. The TV is not set, MO is The [rfc7641] defines the Observe option. The TV is not set, MO is
set to "ignore" and the CDA is set to "value-sent". SCHC does not set to "ignore", and the CDA is set to "value-sent". SCHC does not
limit the maximum size for this option (3 bytes). To reduce the limit the maximum size for this option (3 bytes). To reduce the
transmission size, either the device implementation MAY limit the transmission size, either the device implementation MAY limit the
delta between two consecutive values, or a proxy can modify the delta between two consecutive values, or a proxy can modify the
increment. increment.
Since an RST message may be sent to inform a server that the client Since an RST message may be sent to inform a server that the client
does not require Observe response, a Rule MUST allow the transmission does not require Observe response; a Rule SHOULD exist to allow the
of this message. message's compression with the RST type.
6.3. No-Response 6.3. No-Response
The [rfc7967] defines a No-Response option limiting the responses The [rfc7967] defines a No-Response option limiting the responses
made by a server to a request. If the value is known by both ends, made by a server to a request. If both ends know the value, then TV
then TV is set to this value, MO is set to "equal" and CDA is set to is set to this value, MO is set to "equal", and CDA is set to "not-
"not-sent". sent".
Otherwise, if the value is changing over time, TV is not set, MO is Otherwise, if the value is changing over time, TV is not set, MO is
set to "ignore" and CDA to "value-sent". A matching list can also be set to "ignore", and CDA to "value-sent". A matching list can also
used to reduce the size. be used to reduce the size.
6.4. OSCORE 6.4. OSCORE
OSCORE [rfc8613] defines end-to-end protection for CoAP messages. OSCORE [rfc8613] defines end-to-end protection for CoAP messages.
This section describes how SCHC Rules can be applied to compress This section describes how SCHC Rules can be applied to compress
OSCORE-protected messages. OSCORE-protected messages.
0 1 2 3 4 5 6 7 <--------- n bytes -------------> 0 1 2 3 4 5 6 7 <--------- n bytes ------------->
+-+-+-+-+-+-+-+-+--------------------------------- +-+-+-+-+-+-+-+-+---------------------------------
|0 0 0|h|k| n | Partial IV (if any) ... |0 0 0|h|k| n | Partial IV (if any) ...
+-+-+-+-+-+-+-+-+--------------------------------- +-+-+-+-+-+-+-+-+---------------------------------
| | | | | |
|<-- CoAP -->|<------ CoAP OSCORE_piv ------> | |<-- CoAP -->|<------ CoAP OSCORE_piv ------> |
OSCORE_flags OSCORE_flags
<- 1 byte -> <------ s bytes -----> <- 1 byte -> <------ s bytes ----->
+------------+----------------------+-----------------------+ +------------+----------------------+-----------------------+
| s (if any) | kid context (if any) | kid (if any) ... | | s (if any) | kid context (if any) | kid (if any) ... |
+------------+----------------------+-----------------------+ +------------+----------------------+-----------------------+
| | | | | |
| <------ CoAP OSCORE_kidctxt ----->|<-- CoAP OSCORE_kid -->| | <------ CoAP OSCORE_kidctx ------>|<-- CoAP OSCORE_kid -->|
Figure 6: OSCORE Option Figure 6: OSCORE Option
The encoding of the OSCORE Option Value defined in Section 6.1 of The encoding of the OSCORE Option Value defined in Section 6.1 of
[rfc8613] is repeated in Figure 6. [rfc8613] is repeated in Figure 6.
The first byte specifies the content of the OSCORE options using The first byte specifies the content of the OSCORE options using
flags. The three most significant bits of this byte are reserved and flags. The three most significant bits of this byte are reserved and
always set to 0. Bit h, when set, indicates the presence of the kid always set to 0. Bit h, when set, indicates the presence of the kid
context field in the option. Bit k, when set, indicates the presence context field in the option. Bit k, when set, indicates the presence
of a kid field. The three least significant bits n indicate the of a kid field. The three least significant bits n indicate the
length of the piv (Partial Initialization Vector) field in bytes. length of the piv (Partial Initialization Vector) field in bytes.
When n = 0, no piv is present. When n = 0, no piv is present.
The flag byte is followed by the piv field, kid context field, and The flag byte is followed by the piv field, kid context field, and
kid field in this order, and if present, the length of the kid kid field in this order, and if present, the length of the kid
context field is encoded in the first byte denoting by s the length context field is encoded in the first byte denoting by s the length
of the kid context in bytes. of the kid context in bytes.
This specification recommends identifying the OSCORE Option and the This specification recommends identifying the OSCORE Option and the
fields it contains Conceptually, it discerns up to 4 distinct pieces fields it contains. Conceptually, it discerns up to 4 distinct
of information within the OSCORE option: the flag bits, the piv, the pieces of information within the OSCORE option: the flag bits, the
kid context, and the kid. The SCHC Rule splits into four field piv, the kid context, and the kid. The SCHC Rule splits into four
descriptions the OSCORE option to compress them: field descriptions the OSCORE option to compress them:
o CoAP OSCORE_flags, o CoAP OSCORE_flags,
o CoAP OSCORE_piv, o CoAP OSCORE_piv,
o CoAP OSCORE_kidctxt, o CoAP OSCORE_kidctx,
o CoAP OSCORE_kid. o CoAP OSCORE_kid.
The OSCORE Option shows superimposed these four fields using the Figure 6 shows the OSCORE Option format with those four fields
format Figure 6, the CoAP OSCORE_kidctxt field includes the size bits superimposed on it. Note that the CoAP OSCORE_kidctx field includes
s. directly the size octet s.
7. Examples of CoAP header compression 7. Examples of CoAP header compression
7.1. Mandatory header with CON message 7.1. Mandatory header with CON message
In this first scenario, the LPWAN Compressor at the Network Gateway In this first scenario, the LPWAN Compressor at the Network Gateway
side receives from an Internet client a POST message, which is side receives from an Internet client a POST message, which is
immediately acknowledged by the Device. For this simple scenario, immediately acknowledged by the Device. For this simple scenario,
the Rules are described Figure 7. the Rules are described in Figure 7.
RuleID 1 RuleID 1
+-------------+--+--+--+------+---------+-------------++------------+ +-------------+--+--+--+------+---------+-------------++------------+
| Field |FL|FP|DI|Target| Match | CDA || Sent | | Field |FL|FP|DI|Target| Match | CDA || Sent |
| | | | |Value | Opera. | || [bits] | | | | | |Value | Opera. | || [bits] |
+-------------+--+--+--+------+---------+-------------++------------+ +-------------+--+--+--+------+---------+-------------++------------+
|CoAP version | | |bi| 01 |equal |not-sent || | |CoAP version | 2| 1|bi| 01 |equal |not-sent || |
|CoAP Type | | |dw| CON |equal |not-sent || | |CoAP Type | 2| 1|dw| CON |equal |not-sent || |
|CoAP Type | | |up|[ACK, | | || | |CoAP Type | 2| 1|up|[ACK, | | || |
| | | | | RST] |match-map|matching-sent|| T | | | | | | RST] |match-map|matching-sent|| T |
|CoAP TKL | | |bi| 0 |equal |not-sent || | |CoAP TKL | 4| 1|bi| 0 |equal |not-sent || |
|CoAP Code | | |bi|[0.00,| | || | |CoAP Code | 8| 1|bi|[0.00,| | || |
| | | | | ... | | || | | | | | | ... | | || |
| | | | | 5.05]|match-map|matching-sent|| CC CCC | | | | | | 5.05]|match-map|matching-sent|| CC CCC |
|CoAP MID | | |bi| 0000 |MSB(7 ) |LSB || M-ID| |CoAP MID |16| 1|bi| 0000 |MSB(7 ) |LSB || M-ID|
|CoAP Uri-Path| | |dw| path |equal 1 |not-sent || | |CoAP Uri-Path|var 1|dw| path |equal 1 |not-sent || |
+-------------+--+--+--+------+---------+-------------++------------+ +-------------+--+--+--+------+---------+-------------++------------+
Figure 7: CoAP Context to compress header without token Figure 7: CoAP Context to compress header without token
The version and Token Length fields are elided. The 26 method and The version and Token Length fields are elided. The 26 method and
response codes defined in [rfc7252] has been shrunk to 5 bits using a response codes defined in [rfc7252] has been shrunk to 5 bits using a
matching list. Uri-Path contains a single element indicated in the matching list. Uri-Path contains a single element indicated in the
matching operator. matching operator.
SCHC Compression reduces the header sending only the Type, a mapped SCHC Compression reduces the header sending only the Type, a mapped
skipping to change at page 15, line 13 skipping to change at page 16, line 23
matched by the Rule. matched by the Rule.
7.2. OSCORE Compression 7.2. OSCORE Compression
OSCORE aims to solve the problem of end-to-end encryption for CoAP OSCORE aims to solve the problem of end-to-end encryption for CoAP
messages. The goal, therefore, is to hide as much of the message as messages. The goal, therefore, is to hide as much of the message as
possible while still enabling proxy operation. possible while still enabling proxy operation.
Conceptually this is achieved by splitting the CoAP message into an Conceptually this is achieved by splitting the CoAP message into an
Inner Plaintext and Outer OSCORE Message. The Inner Plaintext Inner Plaintext and Outer OSCORE Message. The Inner Plaintext
contains sensitive information which is not necessary for proxy contains sensitive information that is not necessary for proxy
operation. This, in turn, is the part of the message which can be operation. This, in turn, is the part of the message which can be
encrypted until it reaches its end destination. The Outer Message encrypted until it reaches its end destination. The Outer Message
acts as a shell matching the format of a regular CoAP message, and acts as a shell matching the regular CoAP message format and includes
includes all Options and information needed for proxy operation and all Options and information needed for proxy operation and caching.
caching. This decomposition is illustrated in Figure 8. This decomposition is illustrated in Figure 8.
CoAP options are sorted into one of 3 classes, each granted a CoAP options are sorted into one of 3 classes, each granted a
specific type of protection by the protocol: specific type of protection by the protocol:
o Class E: Encrypted options moved to the Inner Plaintext, o Class E: Encrypted options moved to the Inner Plaintext,
o Class I: Integrity-protected options included in the AAD for the o Class I: Integrity-protected options included in the AAD for the
encryption of the Plaintext but otherwise left untouched in the encryption of the Plaintext but otherwise left untouched in the
Outer Message, Outer Message,
o Class U: Unprotected options left untouched in the Outer Message. o Class U: Unprotected options left untouched in the Outer Message.
Additionally, the OSCORE Option is added as an Outer option, Additionally, the OSCORE Option is added as an Outer option,
signalling that the message is OSCORE protected. This option carries signaling that the message is OSCORE protected. This option carries
the information necessary to retrieve the Security Context with which the information necessary to retrieve the Security Context with which
the message was encrypted so that it may be correctly decrypted at the message was encrypted to be correctly decrypted at the other end-
the other end-point. point.
Original CoAP Message Original CoAP Message
+-+-+---+-------+---------------+ +-+-+---+-------+---------------+
|v|t|tkl| code | Msg Id. | |v|t|tkl| code | Msg Id. |
+-+-+---+-------+---------------+....+ +-+-+---+-------+---------------+....+
| Token | | Token |
+-------------------------------.....+ +-------------------------------.....+
| Options (IEU) | | Options (IEU) |
. . . .
. . . .
skipping to change at page 16, line 44 skipping to change at page 17, line 44
+------+-------------------+ | Payload | +------+-------------------+ | Payload |
| 0xFF | | | | 0xFF | | |
+------+ +-------------------+ +------+ +-------------------+
Figure 8: A CoAP message is split into an OSCORE outer and plaintext Figure 8: A CoAP message is split into an OSCORE outer and plaintext
Figure 8 shows the message format for the OSCORE Message and Figure 8 shows the message format for the OSCORE Message and
Plaintext. Plaintext.
In the Outer Header, the original message code is hidden and replaced In the Outer Header, the original message code is hidden and replaced
by a default dummy value. As seen in Sections 4.1.3.5 and 4.2 of the by a default dummy value. As seen in Sections 4.1.3.5 and 4.2 of
[rfc8613], the message code is replaced by POST for requests and [rfc8613], the message code is replaced by POST for requests and
Changed for responses when Observe is not used. If Observe is used, Changed for responses when Observe is not used. If Observe is used,
the message code is replaced by FETCH for requests and Content for the message code is replaced by FETCH for requests and Content for
responses. responses.
The original message code is put into the first byte of the The original message code is put into the first byte of the
Plaintext. Following the message code, the class E options comes and Plaintext. Following the message code, the class E options come,
if present the original message Payload is preceded by its payload and, if present, the original message Payload is preceded by its
marker. payload marker.
The Plaintext is now encrypted by an AEAD algorithm which integrity The Plaintext is now encrypted by an AEAD algorithm which integrity
protects Security Context parameters and eventually any class I protects Security Context parameters and, eventually, any class I
options from the Outer Header. Currently no CoAP options are marked options from the Outer Header. Currently, no CoAP options are marked
class I. The resulting Ciphertext becomes the new Payload of the class I. The resulting Ciphertext becomes the new Payload of the
OSCORE message, as illustrated in Figure 9. OSCORE message, as illustrated in Figure 9.
This Ciphertext is, as defined in RFC 5116, the concatenation of the As defined in [rfc5116], this Ciphertext is the concatenation of the
encrypted Plaintext and its authentication tag. Note that Inner encrypted Plaintext and its authentication tag. Note that Inner
Compression only affects the Plaintext before encryption, thus we can Compression only affects the Plaintext before encryption. Thus only
only aim to reduce this first, variable length component of the the first variable-length of the Ciphertext can be reduced. The
Ciphertext. The authentication tag is fixed in length and considered authentication tag is fixed in length and is considered part of the
part of the cost of protection. cost of protection.
Outer Header Outer Header
+-+-+---+--------+---------------+ +-+-+---+--------+---------------+
|v|t|tkl|new code| Msg Id. | |v|t|tkl|new code| Msg Id. |
+-+-+---+--------+---------------+....+ +-+-+---+--------+---------------+....+
| Token | | Token |
+--------------------------------.....+ +--------------------------------.....+
| Options (IU) | | Options (IU) |
. . . .
. OSCORE Option . . OSCORE Option .
skipping to change at page 17, line 47 skipping to change at page 18, line 47
+----------------------------------+ +----------------------------------+
Figure 9: OSCORE message Figure 9: OSCORE message
The SCHC Compression scheme consists of compressing both the The SCHC Compression scheme consists of compressing both the
Plaintext before encryption and the resulting OSCORE message after Plaintext before encryption and the resulting OSCORE message after
encryption, see Figure 10. encryption, see Figure 10.
This translates into a segmented process where SCHC compression is This translates into a segmented process where SCHC compression is
applied independently in 2 stages, each with its corresponding set of applied independently in 2 stages, each with its corresponding set of
Rules, with the Inner SCHC Rules and the Outer SCHC Rules. This way Rules, with the Inner SCHC Rules and the Outer SCHC Rules. This way,
compression is applied to all fields of the original CoAP message. compression is applied to all fields of the original CoAP message.
Note that since the Inner part of the message can only be decrypted Note that since the corresponding end-point can only decrypt the
by the corresponding end-point, this end-point will also have to Inner part of the message, this end-point will also have to implement
implement Inner SCHC Compression/Decompression. Inner SCHC Compression/Decompression.
Outer Message OSCORE Plaintext Outer Message OSCORE Plaintext
+-+-+---+--------+---------------+ +-------+ +-+-+---+--------+---------------+ +-------+
|v|t|tkl|new code| Msg Id. | | code | |v|t|tkl|new code| Msg Id. | | code |
+-+-+---+--------+---------------+....+ +-------+-----......+ +-+-+---+--------+---------------+....+ +-------+-----......+
| Token | | Options (E) | | Token | | Options (E) |
+--------------------------------.....+ +-------+------.....+ +--------------------------------.....+ +-------+------.....+
| Options (IU) | | OxFF | | Options (IU) | | OxFF |
. . +-------+-----------+ . . +-------+-----------+
. OSCORE Option . | | . OSCORE Option . | |
skipping to change at page 19, line 41 skipping to change at page 20, line 41
Original message: Original message:
================= =================
0x6145000182ff32332043 0x6145000182ff32332043
Header: Header:
0x6145 0x6145
01 Ver 01 Ver
10 ACK 10 ACK
0001 tkl 0001 tkl
01000101 Successful Response Code 69 "2.05 Content" 01000101 Successful Response Code 69 "2.05 Content"
0x0001 = mid 0x0001 = mid
0x82 = token 0x82 = token
0xFF Payload marker 0xFF Payload marker
Payload: Payload:
0x32332043 0x32332043
Original msg length: 10 Original msg length: 10
Figure 12: CoAP CONTENT Response Figure 12: CoAP CONTENT Response
The SCHC Rules for the Inner Compression include all fields that are The SCHC Rules for the Inner Compression include all fields already
already present in a regular CoAP message. The methods described in present in a regular CoAP message. The methods described in
Section 4 applies to these fields. As an example, see Figure 13. Section 4 apply to these fields. As an example, see Figure 13.
RuleID 0 RuleID 0
+---------------+--+--+-----------+-----------+-----------++------+ +--------------+--+--+--+-----------+----------+----------++------+
| Field |FP|DI| Target | MO | CDA || Sent | | Field |FL|FP|DI| Target | MO | CDA || Sent |
| | | | Value | | ||[bits]| | | | | | Value | | ||[bits]|
+---------------+--+--+-----------+-----------+-----------++------+ +--------------+--+--+--+-----------+----------+----------++------+
|CoAP Code | |up| 1 | equal |not-sent || | |CoAP Code | 8| 1|up| 1 | equal |not-sent || |
|CoAP Code | |dw|[69,132] | match-map |match-sent || c | |CoAP Code | 8| 1|dw|[69,132] | match-map|match-sent|| c |
|CoAP Uri-Path | |up|temperature| equal |not-sent || | |CoAP Uri-Path |88| 1|up|temperature| equal |not-sent || |
|COAP Option-End| |dw| 0xFF | equal |not-sent || | +--------------+--+--+--+-----------+----------+----------++------+
+---------------+--+--+-----------+-----------+-----------++------+
Figure 13: Inner SCHC Rules Figure 13: Inner SCHC Rules
Figure 14 shows the Plaintext obtained for our example GET Request Figure 14 shows the Plaintext obtained for the example GET Request
and follows the process of Inner Compression and Encryption until we and follows the process of Inner Compression and Encryption until the
end up with the Payload to be added in the outer OSCORE Message. end up with the Payload to be added in the outer OSCORE Message.
In this case the original message has no payload and its resulting In this case, the original message has no payload, and its resulting
Plaintext can be compressed up to only 1 byte (size of the RuleID). Plaintext can be compressed up to only 1 byte (size of the RuleID).
The AEAD algorithm preserves this length in its first output, but The AEAD algorithm preserves this length in its first output and
also yields a fixed-size tag which cannot be compressed and has to be yields a fixed-size tag that cannot be compressed and has to be
included in the OSCORE message. This translates into an overhead in included in the OSCORE message. This translates into an overhead in
total message length, which limits the amount of compression that can total message length, limiting the amount of compression that can be
be achieved and plays into the cost of adding security to the achieved and plays into the cost of adding security to the exchange.
exchange.
________________________________________________________ ________________________________________________________
| | | |
| OSCORE Plaintext | | OSCORE Plaintext |
| | | |
| 0x01bb74656d7065726174757265 (13 bytes) | | 0x01bb74656d7065726174757265 (13 bytes) |
| | | |
| 0x01 Request Code GET | | 0x01 Request Code GET |
| | | |
| bb74656d7065726174757265 Option 11: URI_PATH | | bb74656d7065726174757265 Option 11: URI_PATH |
skipping to change at page 21, line 28 skipping to change at page 22, line 28
| |
| Inner SCHC Compression | Inner SCHC Compression
| |
v v
_________________________________ _________________________________
| | | |
| Compressed Plaintext | | Compressed Plaintext |
| | | |
| 0x00 | | 0x00 |
| | | |
| RuleID = 0x00 (1 byte) | | RuleID = 0x00 (1 byte) |
| (No residue) | | (No residue) |
|_________________________________| |_________________________________|
| |
| AEAD Encryption | AEAD Encryption
| (piv = 0x04) | (piv = 0x04)
v v
_________________________________________________ _________________________________________________
| | | |
| encrypted_plaintext = 0xa2 (1 byte) | | encrypted_plaintext = 0xa2 (1 byte) |
| tag = 0xc54fe1b434297b62 (8 bytes) | | tag = 0xc54fe1b434297b62 (8 bytes) |
| | | |
| ciphertext = 0xa2c54fe1b434297b62 (9 bytes) | | ciphertext = 0xa2c54fe1b434297b62 (9 bytes) |
|_________________________________________________| |_________________________________________________|
Figure 14: Plaintext compression and encryption for GET Request Figure 14: Plaintext compression and encryption for GET Request
In Figure 15 the process is repeated for the example CONTENT In Figure 15, the process is repeated for the example CONTENT
Response. The residue is 1 bit long. Note that since SCHC adds Response. The residue is 1 bit long. Note that since SCHC adds
padding after the payload, this misalignment causes the hexadecimal padding after the payload, this misalignment causes the hexadecimal
code from the payload to differ from the original, even though it has code from the payload to differ from the original, even though it has
not been compressed. not been compressed.
On top of this, the overhead from the tag bytes is incurred as On top of this, the overhead from the tag bytes is incurred as
before. before.
________________________________________________________ ________________________________________________________
| | | |
skipping to change at page 23, line 5 skipping to change at page 24, line 5
_________________________________________________________ _________________________________________________________
| | | |
| encrypted_plaintext = 0x10c6d7c26cc1 (6 bytes) | | encrypted_plaintext = 0x10c6d7c26cc1 (6 bytes) |
| tag = 0xe9aef3f2461e0c29 (8 bytes) | | tag = 0xe9aef3f2461e0c29 (8 bytes) |
| | | |
| ciphertext = 0x10c6d7c26cc1e9aef3f2461e0c29 (14 bytes) | | ciphertext = 0x10c6d7c26cc1e9aef3f2461e0c29 (14 bytes) |
|_________________________________________________________| |_________________________________________________________|
Figure 15: Plaintext compression and encryption for CONTENT Response Figure 15: Plaintext compression and encryption for CONTENT Response
The Outer SCHC Rules (Figure 18) must process the OSCORE Options The Outer SCHC Rules (Figure 18) must process the OSCORE Options
fields. In Figure 16 and Figure 17 we show a dump of the OSCORE fields. The Figure 16 and Figure 17 show a dump of the OSCORE
Messages generated from our example messages once they have been Messages generated from the example messages once they have been
provided with the Inner Compressed Ciphertext in the payload. These provided with the Inner Compressed Ciphertext in the payload. These
are the messages that have to be compressed by the Outer SCHC are the messages that have to be compressed by the Outer SCHC
Compression. Compression.
Protected message: Protected message:
================== ==================
0x4102000182d8080904636c69656e74ffa2c54fe1b434297b62 0x4102000182d8080904636c69656e74ffa2c54fe1b434297b62
(25 bytes) (25 bytes)
Header: Header:
skipping to change at page 24, line 31 skipping to change at page 25, line 31
0xd008 (2 bytes) 0xd008 (2 bytes)
Option 21: OBJECT_SECURITY Option 21: OBJECT_SECURITY
Value = b'' Value = b''
0xFF Payload marker 0xFF Payload marker
Payload: Payload:
0x10c6d7c26cc1e9aef3f2461e0c29 (14 bytes) 0x10c6d7c26cc1e9aef3f2461e0c29 (14 bytes)
Figure 17: Protected and Inner SCHC Compressed CONTENT Response Figure 17: Protected and Inner SCHC Compressed CONTENT Response
For the flag bits, a number of compression methods has been shown to For the flag bits, some SCHC compression methods are useful,
be useful depending on the application. The simplest alternative is depending on the application. The simplest alternative is to provide
to provide a fixed value for the flags, combining MO equal and CDA a fixed value for the flags, combining MO equal and CDA not- sent.
not- sent. This saves most bits but could prevent flexibility. This saves most bits but could prevent flexibility. Otherwise,
Otherwise, match-mapping could be used to choose from an interested match-mapping could be used to choose from an interesting number of
number of configurations to the exchange. Otherwise, MSB could be configurations for the exchange.
used to mask off the 3 hard-coded most significant bits. Otherwise, MSB could be used to mask off the 3 hard-coded most
significant bits.
Note that fixing a flag bit will limit the choice of CoAP Options Note that fixing a flag bit will limit CoAP Options choice that can
that can be used in the exchange, since their values are dependent on be used in the exchange since their values are dependent on certain
certain options. options.
The piv field lends itself to having a number of bits masked off with The piv field lends itself to having some bits masked off with MO MSB
MO MSB and CDA LSB. This could be useful in applications where the and CDA LSB. This could be useful in applications where the message
message frequency is low such as that found in LPWAN technologies. frequency is low such as LPWAN technologies. Note that compressing
Note that compressing the sequence numbers effectively reduces the the sequence numbers effectively reduces the maximum number of
maximum amount of sequence numbers that can be used in an exchange. sequence numbers used in an exchange. Once this amount is exceeded,
Once this amount is exceeded, the OSCORE keys need to be re- the OSCORE keys need to be re-established.
established.
The size s included in the kid context field MAY be masked off with The size s included in the kid context field MAY be masked off with
CDA MSB. The rest of the field could have additional bits masked CDA MSB. The rest of the field could have additional bits masked off
off, or have the whole field be fixed with MO equal and CDA not-sent. or have the whole field be fixed with MO equal and CDA not-sent. The
The same holds for the kid field. same holds for the kid field.
Figure 18 shows a possible set of Outer Rules to compress the Outer Figure 18 shows a possible set of Outer Rules to compress the Outer
Header. Header.
RuleID 0 RuleID 0
+-------------------+--+--+--------------+--------+---------++------+ +------------------+--+--+--+--------------+-------+--------++------+
| Field |FP|DI| Target | MO | CDA || Sent | | Field |FL|FP|DI| Target | MO | CDA || Sent |
| | | | Value | | ||[bits]| | | | | | Value | | ||[bits]|
+-------------------+--+--+--------------+--------+---------++------+ +------------------+--+--+--+--------------+-------+--------++------+
|CoAP version | |bi| 01 |equal |not-sent || | |CoAP version | 2| 1|bi| 01 |equal |not-sent|| |
|CoAP Type | |up| 0 |equal |not-sent || | |CoAP Type | 2| 1|up| 0 |equal |not-sent|| |
|CoAP Type | |dw| 2 |equal |not-sent || | |CoAP Type | 2| 1|dw| 2 |equal |not-sent|| |
|CoAP TKL | |bi| 1 |equal |not-sent || | |CoAP TKL | 4| 1|bi| 1 |equal |not-sent|| |
|CoAP Code | |up| 2 |equal |not-sent || | |CoAP Code | 8| 1|up| 2 |equal |not-sent|| |
|CoAP Code | |dw| 68 |equal |not-sent || | |CoAP Code | 8| 1|dw| 68 |equal |not-sent|| |
|CoAP MID | |bi| 0000 |MSB(12) |LSB ||MMMM | |CoAP MID |16| 1|bi| 0000 |MSB(12)|LSB ||MMMM |
|CoAP Token | |bi| 0x80 |MSB(5) |LSB ||TTT | |CoAP Token |tkl 1|bi| 0x80 |MSB(5) |LSB ||TTT |
|CoAP OSCORE_flags | |up| 0x09 |equal |not-sent || | |CoAP OSCORE_flags | 8| 1|up| 0x09 |equal |not-sent|| |
|CoAP OSCORE_piv | |up| 0x00 |MSB(4) |LSB ||PPPP | |CoAP OSCORE_piv |var 1|up| 0x00 |MSB(4) |LSB ||PPPP |
|COAP OSCORE_kid | |up|0x636c69656e70|MSB(52) |LSB ||KKKK | |COAP OSCORE_kid |var 1|up|0x636c69656e70|MSB(52)|LSB ||KKKK |
|COAP OSCORE_kidctxt| |bi| b'' |equal |not-sent || | |COAP OSCORE_kidctx|var 1|bi| b'' |equal |not-sent|| |
|CoAP OSCORE_flags | |dw| b'' |equal |not-sent || | |CoAP OSCORE_flags | 8| 1|dw| b'' |equal |not-sent|| |
|CoAP OSCORE_piv | |dw| b'' |equal |not-sent || | |CoAP OSCORE_piv |var 1|dw| b'' |equal |not-sent|| |
|CoAP OSCORE_kid | |dw| b'' |equal |not-sent || | |CoAP OSCORE_kid |var 1|dw| b'' |equal |not-sent|| |
|COAP Option-End | |dw| 0xFF |equal |not-sent || | +------------------+--+--+--+--------------+-------+--------++------+
+-------------------+--+--+--------------+--------+---------++------+
Figure 18: Outer SCHC Rules Figure 18: Outer SCHC Rules
These Outer Rules are applied to the example GET Request and CONTENT These Outer Rules are applied to the example GET Request and CONTENT
Response. The resulting messages are shown in Figure 19 and Response. The resulting messages are shown in Figure 19 and
Figure 20. Figure 20.
Compressed message: Compressed message:
================== ==================
0x001489458a9fc3686852f6c4 (12 bytes) 0x001489458a9fc3686852f6c4 (12 bytes)
skipping to change at page 26, line 40 skipping to change at page 27, line 40
0b0001 010 (7 bits -> 1 byte with padding) 0b0001 010 (7 bits -> 1 byte with padding)
mid tkn mid tkn
Payload Payload
0x10c6d7c26cc1e9aef3f2461e0c29 (14 bytes) 0x10c6d7c26cc1e9aef3f2461e0c29 (14 bytes)
Compressed msg length: 16 bytes Compressed msg length: 16 bytes
Figure 20: SCHC-OSCORE Compressed CONTENT Response Figure 20: SCHC-OSCORE Compressed CONTENT Response
For contrast, we compare these results with what would be obtained by In contrast, comparing these results with what would be obtained by
SCHC compressing the original CoAP messages without protecting them SCHC compressing the original CoAP messages without protecting them
with OSCORE. To do this, we compress the CoAP messages according to with OSCORE is done by compressing the CoAP messages according to the
the SCHC Rules in Figure 21. SCHC Rules in Figure 21.
RuleID 1 RuleID 1
+---------------+--+--+-----------+---------+-----------++--------+ +---------------+--+--+--+-----------+---------+-----------++-------+
| Field |FP|DI| Target | MO | CDA || Sent | | Field |FL|FP|DI| Target | MO | CDA || Sent |
| | | | Value | | || [bits] | | | | | | Value | | || [bits]|
+---------------+--+--+-----------+---------+-----------++--------+ +---------------+--+--+--+-----------+---------+-----------++-------+
|CoAP version | |bi| 01 |equal |not-sent || | |CoAP version | 2| 1|bi| 01 |equal |not-sent || |
|CoAP Type | |up| 0 |equal |not-sent || | |CoAP Type | 2| 1|up| 0 |equal |not-sent || |
|CoAP Type | |dw| 2 |equal |not-sent || | |CoAP Type | 2| 1|dw| 2 |equal |not-sent || |
|CoAP TKL | |bi| 1 |equal |not-sent || | |CoAP TKL | 4| 1|bi| 1 |equal |not-sent || |
|CoAP Code | |up| 2 |equal |not-sent || | |CoAP Code | 8| 1|up| 2 |equal |not-sent || |
|CoAP Code | |dw| [69,132] |match-map|map-sent ||C | |CoAP Code | 8| 1|dw| [69,132] |match-map|map-sent ||C |
|CoAP MID | |bi| 0000 |MSB(12) |LSB ||MMMM | |CoAP MID |16| 1|bi| 0000 |MSB(12) |LSB ||MMMM |
|CoAP Token | |bi| 0x80 |MSB(5) |LSB ||TTT | |CoAP Token |tkl 1|bi| 0x80 |MSB(5) |LSB ||TTT |
|CoAP Uri-Path | |up|temperature|equal |not-sent || | |CoAP Uri-Path |88| 1|up|temperature|equal |not-sent || |
|COAP Option-End| |dw| 0xFF |equal |not-sent || | +---------------+--+--+--+-----------+---------+-----------++-------+
+---------------+--+--+-----------+---------+-----------++--------+
Figure 21: SCHC-CoAP Rules (No OSCORE) Figure 21: SCHC-CoAP Rules (No OSCORE)
This yields the results in Figure 22 for the Request, and Figure 23 This yields the results in Figure 22 for the Request, and Figure 23
for the Response. for the Response.
Compressed message: Compressed message:
================== ==================
0x0114 0x0114
0x01 = RuleID 0x01 = RuleID
skipping to change at page 28, line 21 skipping to change at page 29, line 21
0b00001010 (1 byte) 0b00001010 (1 byte)
Payload Payload
0x32332043 0x32332043
Compressed msg length: 6 Compressed msg length: 6
Figure 23: CoAP CONTENT Compressed without OSCORE Figure 23: CoAP CONTENT Compressed without OSCORE
As can be seen, the difference between applying SCHC + OSCORE as As can be seen, the difference between applying SCHC + OSCORE as
compared to regular SCHC + COAP is about 10 bytes of cost. compared to regular SCHC + COAP is about 10 bytes.
8. IANA Considerations 8. IANA Considerations
This document has no request to IANA. This document has no request to IANA.
9. Security considerations 9. Security considerations
When applied to LPWAN, the Security Considerations of SCHC header When applied to LPWAN, the Security Considerations of SCHC header
compression [rfc8724] are valid for SCHC CoAP header compression. compression [rfc8724] are valid for SCHC CoAP header compression.
When CoAP uses OSCORE, the security considerations defined in When CoAP uses OSCORE, the security considerations defined in
skipping to change at page 29, line 10 skipping to change at page 30, line 10
SCHC compression returns variable-length Residues for some CoAP SCHC compression returns variable-length Residues for some CoAP
fields. In the compressed header, the length sent is not the fields. In the compressed header, the length sent is not the
original header field length but the length of the Residue. So if a original header field length but the length of the Residue. So if a
corrupted packet comes to the decompressor with a longer or shorter corrupted packet comes to the decompressor with a longer or shorter
length than the one in the original header, SCHC decompression will length than the one in the original header, SCHC decompression will
detect an error and drops the packet. detect an error and drops the packet.
OSCORE compression is also based on the same compression method OSCORE compression is also based on the same compression method
described in [rfc8724]. The size of the Initialisation Vector (IV) described in [rfc8724]. The size of the Initialisation Vector (IV)
residue must be considered carefully. A residue size obtained with residue must be considered carefully. A residue size obtained with
LSB CDA over the IV has an impact on the compression efficiency and LSB CDA over the IV impacts on the compression efficiency and the
the frequency the device will renew its key. This operation requires frequency the device will renew its key. This operation requires
several exchanges and is energy-consuming. several exchanges and is energy-consuming.
SCHC header and compression Rules MUST remain tightly coupled. SCHC header and compression Rules MUST remain tightly coupled.
Otherwise, an encrypted residue may be decompressed differently by Otherwise, an encrypted residue may be decompressed differently by
the receiver. To avoid this situation, if the Rule is modified in the receiver. To avoid this situation, if the Rule is modified in
one location, the OSCORE keys MUST be re-established. one location, the OSCORE keys MUST be re-established.
10. Acknowledgements 10. Acknowledgements
The authors would like to thank (in alphabetic order): Christian The authors would like to thank (in alphabetic order): Christian
skipping to change at page 29, line 33 skipping to change at page 30, line 33
Fossati, Klaus Hartke, Francesca Palombini, Alexander Pelov and Goran Fossati, Klaus Hartke, Francesca Palombini, Alexander Pelov and Goran
Selander. Selander.
11. Normative References 11. Normative References
[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>.
[rfc5116] McGrew, D., "An Interface and Algorithms for Authenticated
Encryption", RFC 5116, DOI 10.17487/RFC5116, January 2008,
<https://www.rfc-editor.org/info/rfc5116>.
[rfc7252] Shelby, Z., Hartke, K., and C. Bormann, "The Constrained [rfc7252] Shelby, Z., Hartke, K., and C. Bormann, "The Constrained
Application Protocol (CoAP)", RFC 7252, Application Protocol (CoAP)", RFC 7252,
DOI 10.17487/RFC7252, June 2014, DOI 10.17487/RFC7252, June 2014,
<https://www.rfc-editor.org/info/rfc7252>. <https://www.rfc-editor.org/info/rfc7252>.
[rfc7641] Hartke, K., "Observing Resources in the Constrained [rfc7641] Hartke, K., "Observing Resources in the Constrained
Application Protocol (CoAP)", RFC 7641, Application Protocol (CoAP)", RFC 7641,
DOI 10.17487/RFC7641, September 2015, DOI 10.17487/RFC7641, September 2015,
<https://www.rfc-editor.org/info/rfc7641>. <https://www.rfc-editor.org/info/rfc7641>.
 End of changes. 123 change blocks. 
395 lines changed or deleted 426 lines changed or added

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