Static Context Header Compression (SCHC) for the Constrained Application Protocol (CoAP)
Extracted elements (29)
Because SCHC fixes the number of Uri-Path/Uri-Query elements at Rule creation time, variable-length paths are handled by either creating multiple Rules for each possible element count or by using a zero-length Compression Residue entry to signal an absent Uri-Path element, at a cost of 4 additional bits per empty entry.
CoAP's asymmetric message format—where requests and responses carry different options (e.g., Uri-Path in requests only, Content-Format in responses only)—required introducing the Direction Indicator (DI) in SCHC Field Descriptors, allowing a single Rule to process upstream and downstream headers differently rather than requiring separate Rules per direction.
CoAP's repeatable options (e.g., Uri-Path) can appear multiple times in a single header. SCHC uses the Field Position (FP) to identify each instance within a Rule, removing the ambiguity that would otherwise exist in the Matching Operator evaluation.
OSCORE compression is split into Inner and Outer stages to compress all fields of the original CoAP message while preserving end-to-end encryption. Inner compression reduces the plaintext before encryption; Outer compression reduces the OSCORE envelope including ciphertext as opaque payload, enabling proxy operation without decryption.
Unlike IPv6/UDP where all fields are fixed-length, CoAP headers include variable-length fields such as Token (0–8 bytes) and options using TLV encoding. SCHC handles this by allowing Field Length to be specified as a variable in the Rule, with the compressed field's length then carried in the Compression Residue.
CoAP Block-level fragmentation (RFC 7959) and SCHC fragmentation are complementary mechanisms; a node may use both for the same packet as needed, and Block option content must always be sent as a Compression Residue.
SCHC compression for CoAP MAY be performed independently of lower-layer (IPv6/UDP) SCHC compression, or in conjunction with it. The two compression techniques are independent and follow the same SCHC principles defined in RFC 8724.
Any time the context Rules are updated on an OSCORE endpoint, that endpoint MUST trigger OSCORE key re-establishment to prevent mismatched decompression of protected messages.
For ETag, If-Match, If-None-Match, Location-Path, and Location-Query options, the Rule description MUST always send these values in the Compression Residue; a Rule entry cannot store these fields' values.
For the Token Value field, the Rule MUST use the specific function 'tkl' to complete the Field Descriptor. During decompression, this function returns the value contained in the Token Length field.
If CoAP introduces a new option, the new FID description MUST be assigned to allow its compression; otherwise SCHC sends the CoAP header without compression.
SCHC compression SHOULD elide the CoAP Type field if a client is sending only Non-confirmable or only Confirmable messages. For RST messages, SCHC may use a dedicated Rule.
SCHC header compression Rules MUST remain tightly coupled between the compressor and the decompressor. If Rules get out of sync, a Compression Residue might be decompressed differently than the original message submitted to compression.
SCHC MUST NOT send the Token Value as variable-length data in the Compression Residue, to avoid ambiguity with the Token Length field. Instead, SCHC MUST use the Token Length value to define the size of the Compression Residue for the Token Value.
SCHC MUST set the Field Length for Uri-Path and Uri-Query options to a variable value, regardless of whether the length is known when the Rule is defined. The Compression Residue size is expressed in bytes.
The CoAP Version field is bidirectional and MUST be elided during SCHC compression, since it always contains the same value. If a new CoAP version is defined, new Rules will be needed.
When a packet uses a Block option, SCHC compression MUST send its content in the Compression Residue. The SCHC Rule describes an empty TV with MO set to 'ignore' and CDA set to 'value-sent'.
When the SCHC compressor does not find a matching Rule to compress a CoAP header, the packet MUST be sent uncompressed using the RuleID dedicated to that purpose, with the Compression Residue being the complete header of the packet.
When using a Layer 2 protocol other than LPWAN, the use of a cryptographic integrity-protection mechanism to protect SCHC headers is REQUIRED, in order to continue to provide the properties that RFC 8724 relies upon.
For OSCORE-protected messages, SCHC applies compression in two independent stages: Inner SCHC compression is applied to the OSCORE Plaintext before encryption, and Outer SCHC compression is applied to the resulting OSCORE message (including ciphertext as payload) after encryption.
The OSCORE option is split by SCHC into four distinct Field Descriptors for compression: CoAP OSCORE_flags (the flag byte), CoAP OSCORE_piv (Partial Initialization Vector), CoAP OSCORE_kidctx (kid context, including size octet s), and CoAP OSCORE_kid (the key identifier).
The 'tkl' function is a designated SCHC function used in the Field Descriptor for the Token Value. At decompression time it returns the value from the Token Length field, resolving the size of the Token Value Compression Residue without ambiguity.
Three deployment architectures are defined: (1) SCHC at the LPWAN boundary compressing the full IPv6/UDP/CoAP stack at the NGW; (2) end-to-end standalone CoAP SCHC compression with DTLS protection; (3) two-level OSCORE compression with separate Inner and Outer SCHC Rules and contexts.
Variable-length CoAP options (e.g., Uri-Path, Uri-Query) use SCHC's Field Position (FP) to distinguish multiple instances of the same option in a single header, and may be grouped in a 'match-mapping' MO for more efficient compression.
An attacker able to inject corrupted SCHC-compressed packets can mount DoS attacks by causing excessive resource consumption at the decompressor. If a corrupted packet arrives with an incorrect length, SCHC decompression procedures detect the error and drop the packet.
SCHC header compression for CoAP does not increase or decrease the overall security level of the communication. When no higher-level security protocol (OSCORE, DTLS, etc.) is used, a Layer 2 security mechanism must protect the SCHC messages.
When compressing OSCORE Outer headers, the Initialization Vector (IV) size in the Compression Residue involves a trade-off: a longer MSB prefix improves compression efficiency but reduces the key lifetime, as the Device must re-establish keys before the IV grows beyond the compressed range.
CoAP options use Delta-Type (D-T), Length (L), Value (V) encoding. In SCHC Rules, the option number is derived from the D-T field and placed in the FID, the option value goes in the TV, and option length handling follows RFC 8724 Sections 7.4.1 and 7.4.2. Length coding differs between CoAP options and SCHC variable-size Compression Residue.
The OSCORE option value begins with a 1-byte flag field (bits: 000|h|k|nnn) where h indicates kid context presence, k indicates kid presence, and n (3 bits) encodes the length of the piv field. This is followed by piv (n bytes), a 1-byte length s and kid context (if h=1), and kid (if k=1).