draft-ietf-lpwan-coap-static-context-hc-09.txt   draft-ietf-lpwan-coap-static-context-hc-10.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 7, 2020 Institut MINES TELECOM; IMT Atlantique Expires: April 10, 2020 Institut MINES TELECOM; IMT Atlantique
R. Andreasen R. Andreasen
Universidad de Buenos Aires Universidad de Buenos Aires
July 06, 2019 October 08, 2019
LPWAN Static Context Header Compression (SCHC) for CoAP LPWAN Static Context Header Compression (SCHC) for CoAP
draft-ietf-lpwan-coap-static-context-hc-09 draft-ietf-lpwan-coap-static-context-hc-10
Abstract Abstract
This draft defines the way SCHC header compression can be applied to This draft defines the way SCHC header compression can be applied to
CoAP headers. The CoAP header structure differs from IPv6 and UDP CoAP headers. The CoAP header structure differs from IPv6 and UDP
protocols since CoAP uses a flexible header with a variable number of protocols since CoAP uses a flexible header with a variable number of
options, themselves of variable length. The CoAP protocol is options, themselves of variable length. The CoAP protocol messages
asymmetric in its message format: the format of the packet header in format is asymmetric: the request messages have a header format
the request messages is different from that in the response messages. different from the one in the response messages. This document
Most of the compression mechanisms have been introduced in explains how to use the SCHC compression mechanism described in
[I-D.ietf-lpwan-ipv6-static-context-hc], this document explains how [I-D.ietf-lpwan-ipv6-static-context-hc] for CoAP.
to use the SCHC compression for CoAP.
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 7, 2020. This Internet-Draft will expire on April 10, 2020.
Copyright Notice Copyright Notice
Copyright (c) 2019 IETF Trust and the persons identified as the Copyright (c) 2019 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 . . . . . . . . . . . . . . . . . . . . . . . . 2
2. SCHC Compression Process . . . . . . . . . . . . . . . . . . 3 2. SCHC Compression Process . . . . . . . . . . . . . . . . . . 3
3. CoAP Compression with SCHC . . . . . . . . . . . . . . . . . 4 3. CoAP Compression with SCHC . . . . . . . . . . . . . . . . . 4
4. Compression of CoAP header fields . . . . . . . . . . . . . . 6 4. Compression of CoAP header fields . . . . . . . . . . . . . . 6
4.1. CoAP version field . . . . . . . . . . . . . . . . . . . 6 4.1. CoAP version field . . . . . . . . . . . . . . . . . . . 6
4.2. CoAP type field . . . . . . . . . . . . . . . . . . . . . 6 4.2. CoAP type field . . . . . . . . . . . . . . . . . . . . . 6
4.3. CoAP code field . . . . . . . . . . . . . . . . . . . . . 6 4.3. CoAP code field . . . . . . . . . . . . . . . . . . . . . 6
4.4. CoAP Message ID field . . . . . . . . . . . . . . . . . . 6 4.4. CoAP Message ID field . . . . . . . . . . . . . . . . . . 6
4.5. CoAP Token fields . . . . . . . . . . . . . . . . . . . . 7 4.5. CoAP Token fields . . . . . . . . . . . . . . . . . . . . 7
5. CoAP options . . . . . . . . . . . . . . . . . . . . . . . . 7 5. CoAP options . . . . . . . . . . . . . . . . . . . . . . . . 7
5.1. CoAP Content and Accept options. . . . . . . . . . . . . 7 5.1. CoAP Content and Accept options. . . . . . . . . . . . . 7
5.2. CoAP option Max-Age, Uri-Host and Uri-Port fields . . . . 7 5.2. CoAP option Max-Age, Uri-Host and Uri-Port fields . . . . 8
5.3. CoAP option Uri-Path and Uri-Query fields . . . . . . . . 8 5.3. CoAP option Uri-Path and Uri-Query fields . . . . . . . . 8
5.3.1. Variable length Uri-Path and Uri-Query . . . . . . . 8 5.3.1. Variable length Uri-Path and Uri-Query . . . . . . . 8
5.3.2. Variable number of path or query elements . . . . . . 9 5.3.2. Variable number of path or query elements . . . . . . 9
5.4. CoAP option Size1, Size2, Proxy-URI and Proxy-Scheme 5.4. CoAP option Size1, Size2, Proxy-URI and Proxy-Scheme
fields . . . . . . . . . . . . . . . . . . . . . . . . . 9 fields . . . . . . . . . . . . . . . . . . . . . . . . . 9
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 . . . . . . . . . . . . . . . . 9 and Location-Query fields . . . . . . . . . . . . . . . . 9
6. Other RFCs . . . . . . . . . . . . . . . . . . . . . . . . . 9 6. Other RFCs . . . . . . . . . . . . . . . . . . . . . . . . . 10
6.1. Block . . . . . . . . . . . . . . . . . . . . . . . . . . 9 6.1. Block . . . . . . . . . . . . . . . . . . . . . . . . . . 10
6.2. Observe . . . . . . . . . . . . . . . . . . . . . . . . . 10 6.2. Observe . . . . . . . . . . . . . . . . . . . . . . . . . 10
6.3. No-Response . . . . . . . . . . . . . . . . . . . . . . . 10 6.3. No-Response . . . . . . . . . . . . . . . . . . . . . . . 10
6.4. OSCORE . . . . . . . . . . . . . . . . . . . . . . . . . 10 6.4. OSCORE . . . . . . . . . . . . . . . . . . . . . . . . . 10
7. Examples of CoAP header compression . . . . . . . . . . . . . 11 7. Examples of CoAP header compression . . . . . . . . . . . . . 12
7.1. Mandatory header with CON message . . . . . . . . . . . . 11 7.1. Mandatory header with CON message . . . . . . . . . . . . 12
7.2. OSCORE Compression . . . . . . . . . . . . . . . . . . . 12 7.2. OSCORE Compression . . . . . . . . . . . . . . . . . . . 13
7.3. Example OSCORE Compression . . . . . . . . . . . . . . . 16 7.3. Example OSCORE Compression . . . . . . . . . . . . . . . 16
8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 26 8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 26
9. Security considerations . . . . . . . . . . . . . . . . . . . 26 9. Security considerations . . . . . . . . . . . . . . . . . . . 26
10. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 26 10. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 26
11. Normative References . . . . . . . . . . . . . . . . . . . . 26 11. Normative References . . . . . . . . . . . . . . . . . . . . 26
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 27 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 27
1. Introduction 1. Introduction
CoAP [rfc7252] is an implementation of the REST architecture for CoAP [rfc7252] is an implementation of the REST architecture for
constrained devices. Although CoAP was designed for constrained constrained devices. Although CoAP was designed for constrained
devices, the size of a CoAP header may still be too large for the devices, the size of a CoAP header still is too large for the
constraints of Low Power Wide Area Networks (LPWAN) and some constraints of Low Power Wide Area Networks (LPWAN) and some
compression may be needed to reduce the header size. compression is needed to reduce the header size.
[I-D.ietf-lpwan-ipv6-static-context-hc] defines a header compression [I-D.ietf-lpwan-ipv6-static-context-hc] defines a header compression
mechanism for LPWAN network based on a static context. The context mechanism for LPWAN network based on a static context. The context
is said static since the field description composing the Rules are is said static since the field description composing the Rules are
not learned during the packet exchanges but are previously defined. not learned during the packet exchanges but are previously defined.
The context(s) is(are) known by both ends before transmission. The context(s) is(are) known by both ends before transmission.
A context is composed of a set of rules that are referenced by Rule A context is composed of a set of rules that are referenced by Rule
IDs (identifiers). A rule contains an ordered list of the fields IDs (identifiers). A rule contains an ordered list of the fields
descriptions containing a field ID (FID), its length (FL) and its descriptions containing a field ID (FID), its length (FL) and its
position (FP), a direction indicator (DI) (upstream, downstream and position (FP), a direction indicator (DI) (upstream, downstream and
bidirectional) and some associated Target Values (TV). Target Value bidirectional) and some associated Target Values (TV). Target Value
indicates the value that can be expected. TV can also be a list of indicates the value that can be expected. TV can also be a list of
values. A Matching Operator (MO) is associated to each header field values. A Matching Operator (MO) is associated to each header field
description. The rule is selected if all the MOs fit the TVs for all description. The rule is selected if all the MOs fit the TVs for all
fields of the incoming packet. In that case, a Compression/ fields of the incoming packet. In that case, a Compression/
Decompression Action (CDA) associated to each field defines how the Decompression Action (CDA) associated to each field defines how the
compressed and the decompressed values are computed out of each compressed and the decompressed values are computed out of each
other, for each of the header fields. Compression mainly results in other, for each of the header fields. Compression mainly results in
one of 4 actions: send the field value, send nothing, send some least one of 4 actions: send the field value, send nothing, send some least
significant bits of the field or send an index. Values sent are significant bits of the field or send an index. After applying the
called Compression Residues and follow the rule ID in the transmitted compression there may be some bits to be sent, these values are
message. called Compression Residues and are transmitted after the Rule ID in
the compressed messages.
The compression rules define a generic way to compress and decompress The compression rules define a generic way to compress and decompress
the fields. If the device is modified, for example, to introduce new the fields. If the device is modified, for example, to introduce new
functionalities or new CoAP options, the rules must be updated to functionalities or new CoAP options, the rules must be updated to
reflect the evolution. There is no risk to lock a device in a reflect the evolution. There is no risk to lock a device in a
particular version of CoAP. particular version of CoAP.
2. SCHC Compression Process 2. SCHC Compression Process
The SCHC Compression rules can be applied to CoAP flows. SCHC The SCHC Compression rules can be applied to CoAP flows. SCHC
skipping to change at page 4, line 20 skipping to change at page 4, line 20
| | IPv6 | | UDP | | +------------+ | | IPv6 | | UDP | | +------------+
v +------------+ +------------+ | | IPv6 | v +------------+ +------------+ | | IPv6 |
| IPv6 | v +------------+ | IPv6 | v +------------+
+------------+ +------------+
Figure 1: rule scope for CoAP Figure 1: rule scope for CoAP
Figure 1 shows some examples for CoAP architecture and the SCHC Figure 1 shows some examples for CoAP architecture and the SCHC
rule's scope. rule's scope.
In the first example, a rule compresses all headers from IPv6 to In the first example, a rule compresses the complete header stack
CoAP. In this case, SCHC C/D is performed at the device and at the from IPv6 to CoAP. In this case, SCHC C/D is performed at the device
LPWAN boundary. and at the LPWAN boundary.
In the second example, an end-to-end encryption mechanisms is used In the second example, an end-to-end encryption mechanisms is used
between the device and the application. CoAP is compressed between the device and the application. The SCHC compression is
independently of the other layers. The rule ID and the compression applied in the CoAP layer compressing the CoAP header independently
residue are encrypted using a mechanism such as DTLS. Only the other of the other layers. The rule ID and the compression residue are
end can decipher the information. encrypted using a mechanism such as DTLS. Only the other end can
Layers below may also be compressed using other SCHC rules (this is decipher the information. Layers below may also be compressed using
out of the scope of this document). other SCHC rules (this is out of the scope of this document) as
defined in the SCHC [I-D.ietf-lpwan-ipv6-static-context-hc] document.
In the third example, OSCORE [I-D.ietf-core-object-security] is used. In the third example, OSCORE [rfc8613] is used. In this case, two
2 rulesets are used to compress the CoAP message. A first ruleset rulesets are used to compress the CoAP message. A first ruleset
focuses on the inner header and is end to end, a second ruleset focused on the inner header and is applied end to end by both ends.
compresses the outer header and the layers below. SCHC C/D for inner A second ruleset compresses the outer header and the layers below and
header is done by both ends, and SCHC C/D for outer header and other is done between the device and the LPWAN boundary.
headers is done between the device and the LPWAN boundary.
3. CoAP Compression with SCHC 3. CoAP Compression with SCHC
CoAP differs from IPv6 and UDP protocols on the following aspects: CoAP differs from IPv6 and UDP protocols on the following aspects:
o IPv6 and UDP are symmetrical protocols. The same fields are found o IPv6 and UDP are symmetrical protocols. The same fields are found
in the request and in the response, with the value of some fields in the request and in the response, with the value of some fields
being swapped on the return path (e.g. source and destination being swapped on the return path (e.g. source and destination
fields). A CoAP request is intrinsically different from a fields). A CoAP request is intrinsically different from a
response. For example, the URI-path option is mandatory in the response. For example, the URI-path option is mandatory in the
skipping to change at page 5, line 17 skipping to change at page 5, line 17
single Rule to process message headers differently depending of single Rule to process message headers differently depending of
the direction. 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. Combined with the values carried in each direction are different. Combined with
a matching list in the TV, this allows reducing the range of a matching list in the TV, this allows reducing the range of
expected values in a particular direction and therefore reduce the expected values in a particular direction and therefore reduce the
size of the compression residue. For instance, if a client sends size of the compression residue. For instance, if a client sends
only CON request, the type can be elided by compression and the only CON request, the type can be elided by compression and the
answer may use one single bit to carry either the ACK or RST type. answer may use one single bit to carry either the ACK or RST type.
The same behavior can be applied to the CoAP Code field (0.0X code The same behavior can be applied to the CoAP Code field 0.0X code
are present in the request and Y.ZZ in the answer). The direction Format is found in the request and Y.ZZ code format in the answer.
allows splitting in two parts the possible values for each The direction allows splitting in two parts the possible values
direction. for each direction in the same Rule.
o In IPv6 and UDP, header fields have a fixed size. In CoAP, Token o In IPv6 and UDP, header fields have a fixed size and it is not
size may vary from 0 to 8 bytes, the length being given by a field sent. In CoAP, some fields in the header have a varying size, for
in the header. More systematically, the CoAP options are example the Token size may vary from 0 to 8 bytes, the length is
described using the Type-Length-Value. given by a field in the header. More systematically, the CoAP
options are described using the Type-Length-Value.
[I-D.ietf-lpwan-ipv6-static-context-hc] offers the possibility to [I-D.ietf-lpwan-ipv6-static-context-hc] offers the possibility to
define a function for the Field Length in the Field Description. define a function for the Field Length in the Field Description.
o In CoAP headers, a field can appear several times. This is o In CoAP headers, a field can appear several times. This is
typical for elements of a URI (path or queries). typical for elements of a URI (path or queries). The SCHC
[I-D.ietf-lpwan-ipv6-static-context-hc] allows a Field ID to specification [I-D.ietf-lpwan-ipv6-static-context-hc] allows a
appears several times in the rule, the Field Position (FP) Field ID to appears several times in the rule, and uses the Field
identifies the proper instance, thereby removing the ambiguity of Position (FP) to identify the correct instance, and thereby
the matching operation. removing the ambiguity of the 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 large
regarding LPWAN traffic constraints. This is particularly true regarding LPWAN traffic constraints. This is particularly true
for the message ID field or Token field. The MSB MO can be used for the Message ID field and the Token field. The MSB MO can be
to reduce the information carried on LPWANs. applied to reduce the information carried on LPWANs.
o CoAP also obeys the client/server paradigm and the compression o CoAP also obeys the client/server paradigm and the compression
ratio can be different if the request is issued from an LPWAN ratio can be different if the request is issued from an LPWAN
device or from a non LPWAN device. For instance a Device (Dev) device or from a non LPWAN device. For instance, a Device (Dev)
aware of LPWAN constraints can generate a 1 byte token, but a aware of LPWAN constraints can generate a 1-byte token, but a
regular CoAP client will certainly send a larger token to the Dev. regular CoAP client will certainly send a larger token to the Dev.
The SCHC compression-decompression process does not modify the The SCHC compression-decompression process never modifies the
values. Nevertheless, a proxy placed before the compressor may Values it only reduces their sizes. Nevertheless, a proxy placed
change some field values to allow SCHC achieving a better before the compressor may change some field values to allow SCHC
compression ratio, while maintaining the necessary context for achieving a better compression ratio, while maintaining the
interoperability with existing CoAP implementations. necessary context for interoperability with existing CoAP
implementations.
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. fields.
4.1. CoAP version field 4.1. CoAP version field
This field 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 defined 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
[rfc7252] defines 4 types of messages: CON, NON, ACK and RST. The CoAP Protocol [rfc7252] defines 4 types of messages: CON, NON, ACK
last two are a response to the first two. If the device plays a and RST. ACK and RST are a response to the CON and NON. If the
specific client or server role, a rule can exploit these properties device plays a specific client or server role, a rule can take
with the mapping list: [CON, NON] for one direction and [ACK, RST] advantage of these properties with the mapping list: [CON, NON] for
for the other direction. The compression residue is reduced to 1 one direction and [ACK, RST] for the other direction and so, the
bit. compression residue is reduced to 1 bit.
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. NON or only CON messages.
In any case, a rule MUST be defined to carry RST to a client. In any case, a rule MUST be defined to carry RST to a client.
4.3. CoAP code field 4.3. CoAP code field
The compression of the CoAP code field follows the same principle as The compression of the CoAP code field follows the same principle as
that of the CoAP type field. If the device plays a specific role, that of the CoAP type field. If the device plays a specific role,
the set of code values can be split in two parts, the request codes the set of code values can be split in two parts, the request codes
with the 0 class and the response values. 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 is able to process.
All the response codes MUST be compressed with a SCHC rule. All the response codes MUST be compressed with a SCHC rule.
4.4. CoAP Message ID field 4.4. CoAP Message ID field
This field is bidirectional and is used to manage acknowledgments. The Message ID field is bidirectional and is used to manage
The server memorizes the value for a EXCHANGE_LIFETIME period (by acknowledgments. The server memorizes the value for an
default 247 seconds) for CON messages and a NON_LIFETIME period (by EXCHANGE_LIFETIME period (by default 247 seconds) for CON messages
default 145 seconds) for NON messages. During that period, a server and a NON_LIFETIME period (by default 145 seconds) for NON messages.
receiving the same Message ID value will process the message as a During that period, a server receiving the same Message ID value will
retransmission. After this period, it will be processed as a new process the message as a retransmission. After this period, it will
message. be processed as a new message.
In case the Device is a client, the size of the message ID field may In case where the Device is a client, the size of the Message ID
be too large regarding the number of messages sent. The client field may be too large regarding the number of messages sent. The
SHOULD use only small message ID values, for instance 4 bit long. client SHOULD use only small Message ID values, for instance 4 bit
Therefore, a MSB can be used to limit the size of the compression long. Therefore, an MSB can be used to limit the size of the
residue. compression residue.
In case the Device is a server, the client may be located outside of In case where the Device is a server, the client may be located
the LPWAN area and view the Device as a regular device connected to outside of the LPWAN area and it views the Device as a regular device
the internet. The client will generate Message ID using the 16 bits connected to the Internet. The client will generate Message ID using
space offered by this field. A CoAP proxy can be set before the SCHC the 16 bits space offered by this field. A CoAP proxy can be set
C/D to reduce the value of the Message ID, to allow its compression before the SCHC C/D to reduce the value of the Message ID, to allow
with the MSB matching operator and LSB CDA. its compression with the MSB matching operator and LSB CDA.
4.5. CoAP Token fields 4.5. CoAP Token fields
Token is defined through two CoAP fields, Token Length in the 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 Token Length is processed as any protocol field. If the value
remains the same during all the transaction, the size can be stored remains the same during all the transaction, the size can be stored
in the context and elided during the transmission. Otherwise, it in the context and elided during the transmission. Otherwise, it
will have to the sent as a compression residue. will have to be sent as a compression residue.
Token Value size cannot be defined directly in the rule in the Field Token Value size cannot be defined directly in the rule in the Field
Length (FL). Instead, a specific function designated as "TKL" MUST Length (FL). Instead, a specific function designated as "TKL" MUST
be used and length does not have to the sent with the residue. be used and length does not have to be sent with the residue. During
During the decompression, this function returns the value contained the decompression, this function returns the value contained in the
in the Token Length field. Token Length field.
5. CoAP options 5. CoAP options
5.1. CoAP Content and Accept options. 5.1. CoAP Content and Accept options.
These fields are both unidirectional and MUST NOT be set to These fields are both unidirectional and MUST NOT be set to
bidirectional in a rule entry. bidirectional in a rule entry.
If a single value is expected by the client, it can be stored in the If a single value is expected by the client, it can be stored in the
TV and elided during the transmission. Otherwise, if several TV and elided during the transmission. Otherwise, if several
possible values are expected by the client, a matching-list SHOULD be possible values are expected by the client, a matching-list SHOULD be
used to limit the size of the residue. If is not possible, the value used to limit the size of the residue. Otherwise, the value has to
has to be sent as a residue (fixed or variable length). be sent as a residue (fixed or variable 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
These fields are unidirectional and MUST NOT be set to bidirectional These fields are unidirectional and MUST NOT be set to bidirectional
in a rule entry. They are used only by the server to inform of the in a rule entry. They are used only by the server to inform of the
caching duration and is never found in client requests. caching duration and is never found in client requests.
If the duration is known by both ends, the value can be elided on the If the duration is known by both ends, the value can be elided on the
LPWAN. LPWAN.
skipping to change at page 10, line 7 skipping to change at page 10, line 15
6. Other RFCs 6. Other 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 are compatible. If a block includes a fragmentation protocol. They are compatible. If a block
option is used, its content MUST be sent as a compression residue. option is used, its content MUST be sent as a compression residue.
6.2. Observe 6.2. Observe
[rfc7641] defines the Observe option. The TV is not set, MO is set The [rfc7641] defines the Observe option. The TV is not set, MO is
to "ignore" and the CDA is set to "value-sent". SCHC does not limit set to "ignore" and the CDA is set to "value-sent". SCHC does not
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 MUST allow the transmission
of this message. of this message.
6.3. No-Response 6.3. No-Response
[rfc7967] defines a No-Response option limiting the responses made by The [rfc7967] defines a No-Response option limiting the responses
a server to a request. If the value is known by both ends, then TV made by a server to a request. If the value is known by both ends,
is set to this value, MO is set to "equal" and CDA is set to "not- then TV is set to this value, MO is set to "equal" and CDA is set to
sent". "not-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 be
used to reduce the size. used to reduce the size.
6.4. OSCORE 6.4. OSCORE
OSCORE [I-D.ietf-core-object-security] defines end-to-end protection OSCORE [rfc8613] defines end-to-end protection for CoAP messages.
for CoAP messages. This section describes how SCHC rules can be This section describes how SCHC rules can be applied to compress
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_kidctxt ----->|<-- CoAP OSCORE_kid -->|
Figure 4: OSCORE Option Figure 4: 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
[I-D.ietf-core-object-security] is repeated in Figure 4. [rfc8613] is repeated in Figure 4.
The first byte is used for flags that specify the contents of the The first byte is used for flags that specify the contents of the
OSCORE option. The 3 most significant bits are reserved and always OSCORE option. The 3 most significant bits of this byte are reserved
set to 0. Bit h, when set, indicates the presence of the kid context and always set to 0. Bit h, when set, indicates the presence of the
field in the option. Bit k, when set, indicates the presence of a kid context field in the option. Bit k, when set, indicates the
kid field. The 3 least significant bits n indicate the length of the presence of a kid field. The 3 least significant bits n indicate the
piv field in bytes. When n = 0, no piv is present. length of the piv (Partial Initialization Vector) field in bytes.
When n = 0, no piv is present.
After the flag byte follow the piv field, kid context field and kid The flag byte is followed by the piv field, kid context field and kid
field in order and if present; the length of the kid context field is field in this order and if present; the length of the kid context
encoded in the first byte denoting by s the length of the kid context field is encoded in the first byte denoting by s the length of the
in bytes. kid context in bytes.
This draft recommends to implement a parser that is able to identify This draft recommends to implement a parser that is able to identify
the OSCORE Option and the fields it contains. the OSCORE Option and the fields it contains.
Conceptually, it discerns up to 4 distinct pieces of information Conceptually, it discerns up to 4 distinct pieces of information
within the OSCORE option: the flag bits, the piv, the kid context, within the OSCORE option: the flag bits, the piv, the kid context,
and the kid. It is thus recommended that the parser split the OSCORE and the kid. It is thus recommended that the parser split the OSCORE
option into the 4 subsequent fields: option into the 4 subsequent fields:
o CoAP OSCORE_flags, o CoAP OSCORE_flags,
skipping to change at page 11, line 45 skipping to change at page 12, line 15
These fields are shown superimposed on the OSCORE Option format in These fields are shown superimposed on the OSCORE Option format in
Figure 4, the CoAP OSCORE_kidctxt field including the size bits s. Figure 4, the CoAP OSCORE_kidctxt field including the size bits s.
Their size SHOULD be reduced using SCHC compression. Their size SHOULD be reduced using SCHC compression.
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 a client on the Internet 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 5. the rules are described Figure 5.
Rule ID 1 Rule ID 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 | | |bi| 01 |equal |not-sent || |
|CoAP Type | | |dw| CON |equal |not-sent || | |CoAP Type | | |dw| CON |equal |not-sent || |
skipping to change at page 12, line 33 skipping to change at page 12, line 47
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
code and the least significant bits of Message ID (9 bits in the code and the least significant bits of Message ID (9 bits in the
example above). example above).
Note that a request sent by a client located an Application Server to Note that a request sent by a client located in an Application Server
a server in the device, may not be compressed through this rule since to a server located in the device, may not be compressed through this
the MID will not start with 7 bits equal to 0. A CoAP proxy, before rule since the MID will not start with 7 bits equal to 0. A CoAP
the core SCHC C/D can rewrite the message ID to a value matched by proxy, before the core SCHC C/D can rewrite the message ID to a value
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 sensible information which is not necessary for proxy contains sensible information which is not necessary for proxy
skipping to change at page 13, line 19 skipping to change at page 13, line 34
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,
signaling that the message is OSCORE protected. This option carries signalling 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 so that it may be correctly decrypted at
the other end-point. the other end-point.
Original CoAP Message Original CoAP Message
+-+-+---+-------+---------------+ +-+-+---+-------+---------------+
|v|t|tkl| code | Msg Id. | |v|t|tkl| code | Msg Id. |
+-+-+---+-------+---------------+....+ +-+-+---+-------+---------------+....+
| Token | | Token |
+-------------------------------.....+ +-------------------------------.....+
skipping to change at page 14, line 44 skipping to change at page 14, line 44
+------+-------------------+ | Payload | +------+-------------------+ | Payload |
| 0xFF | | | | 0xFF | | |
+------+ +-------------------+ +------+ +-------------------+
Figure 6: A CoAP message is split into an OSCORE outer and plaintext Figure 6: A CoAP message is split into an OSCORE outer and plaintext
Figure 6 shows the message format for the OSCORE Message and Figure 6 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 by a default dummy value. As seen in sections 4.1.3.5 and 4.2 of the
[I-D.ietf-core-object-security], the message code is replaced by POST [rfc8613], the message code is replaced by POST for requests and
for requests and Changed for responses when Observe is not used. If Changed for responses when Observe is not used. If Observe is used,
Observe is used, the message code is replaced by FETCH for requests the message code is replaced by FETCH for requests and Content for
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 comes and
if present the original message Payload is preceded by its payload if present the original message Payload is preceded by its payload
marker. 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
skipping to change at page 18, line 6 skipping to change at page 18, line 6
0xFF Payload marker 0xFF Payload marker
Payload: Payload:
0x32332043 0x32332043
Original msg length: 10 Original msg length: 10
Figure 10: CoAP CONTENT Response Figure 10: 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 that are
already present in a regular CoAP message, what is important is the already present in a regular CoAP message, what is important is their
order of appearance and inclusion of only those CoAP fields that go order and the definition of only those CoAP fields are into
into the Plaintext, Figure 11. Plaintext, Figure 11.
Rule ID 0 Rule ID 0
+---------------+--+--+-----------+-----------+-----------++------+ +---------------+--+--+-----------+-----------+-----------++------+
| Field |FP|DI| Target | MO | CDA || Sent | | Field |FP|DI| Target | MO | CDA || Sent |
| | | | Value | | ||[bits]| | | | | Value | | ||[bits]|
+---------------+--+--+-----------+-----------+-----------++------+ +---------------+--+--+-----------+-----------+-----------++------+
|CoAP Code | |up| 1 | equal |not-sent || | |CoAP Code | |up| 1 | equal |not-sent || |
|CoAP Code | |dw|[69,132] | match-map |match-sent || c | |CoAP Code | |dw|[69,132] | match-map |match-sent || c |
|CoAP Uri-Path | |up|temperature| equal |not-sent || | |CoAP Uri-Path | |up|temperature| equal |not-sent || |
|COAP Option-End| |dw| 0xFF | equal |not-sent || | |COAP Option-End| |dw| 0xFF | equal |not-sent || |
skipping to change at page 21, line 8 skipping to change at page 21, line 8
| tag = 0xe9aef3f2461e0c29 (8 bytes) | | tag = 0xe9aef3f2461e0c29 (8 bytes) |
| | | |
| ciphertext = 0x10c6d7c26cc1e9aef3f2461e0c29 (14 bytes) | | ciphertext = 0x10c6d7c26cc1e9aef3f2461e0c29 (14 bytes) |
|_________________________________________________________| |_________________________________________________________|
Figure 13: Plaintext compression and encryption for CONTENT Response Figure 13: Plaintext compression and encryption for CONTENT Response
The Outer SCHC Rules (Figure 16) MUST process the OSCORE Options The Outer SCHC Rules (Figure 16) MUST process the OSCORE Options
fields. In Figure 14 and Figure 15 we show a dump of the OSCORE fields. In Figure 14 and Figure 15 we show a dump of the OSCORE
Messages generated from our example messages once they have been Messages generated from our 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 are to go through Outer SCHC Compression. are the messages that have to be compressed by the Outer SCHC
Compression.
Protected message: Protected message:
================== ==================
0x4102000182d7080904636c69656e74ffa2c54fe1b434297b62 0x4102000182d7080904636c69656e74ffa2c54fe1b434297b62
(25 bytes) (25 bytes)
Header: Header:
0x4102 0x4102
01 Ver 01 Ver
00 CON 00 CON
skipping to change at page 22, line 31 skipping to change at page 22, 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 15: Protected and Inner SCHC Compressed CONTENT Response Figure 15: Protected and Inner SCHC Compressed CONTENT Response
For the flag bits, a number of compression methods could prove to be For the flag bits, a number of compression methods has been shown to
useful depending on the application. The simplest alternative is to be useful depending on the application. The simplest alternative is
provide a fixed value for the flags, combining MO equal and CDA not- to provide a fixed value for the flags, combining MO equal and CDA
sent. This saves most bits but could hinder flexibility. Otherwise, not- sent. This saves most bits but could prevent flexibility.
match-mapping could allow to choose from a number of configurations Otherwise, match-mapping could be used to choose from an interested
of interest to the exchange. If neither of these alternatives is number of configurations to the exchange. Otherwise, MSB could be
desirable, MSB could be used to mask off the 3 hard-coded most used to mask off the 3 hard-coded most significant bits.
significant bits.
Note that fixing a flag bit will limit the choice of CoAP Options Note that fixing a flag bit will limit the choice of CoAP Options
that can be used in the exchange, since their values are dependent on that can be used in the exchange, since their values are dependent on
certain options. certain options.
The piv field lends itself to having a number of bits masked off with The piv field lends itself to having a number of bits masked off with
MO MSB and CDA LSB. This could prove useful in applications where MO MSB and CDA LSB. This could be useful in applications where the
the message frequency is low such as that found in LPWAN message frequency is low such as that found in LPWAN technologies.
technologies. Note that compressing the sequence numbers effectively Note that compressing the sequence numbers effectively reduces the
reduces the maximum amount of sequence numbers that can be used in an maximum amount of sequence numbers that can be used in an exchange.
exchange. Once this amount is exceeded, the SCHC Context would need Once this amount is exceeded, the SCHC Context would need to be re-
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, or have the whole field be fixed with MO equal and CDA not-sent. off, or have the whole field be fixed with MO equal and CDA not-sent.
The same holds for the kid field. The same holds for the kid field.
Figure 16 shows a possible set of Outer Rules to compress the Outer Figure 16 shows a possible set of Outer Rules to compress the Outer
Header. Header.
Rule ID 0 Rule ID 0
skipping to change at page 26, line 40 skipping to change at page 26, line 40
ones already raised on [I-D.ietf-lpwan-ipv6-static-context-hc] ones already raised on [I-D.ietf-lpwan-ipv6-static-context-hc]
10. Acknowledgements 10. Acknowledgements
The authors would like to thank Dominique Barthel, Carsten Bormann, The authors would like to thank Dominique Barthel, Carsten Bormann,
Thomas Fossati, Klaus Hartke, Francesca Palombini, Alexander Pelov, Thomas Fossati, Klaus Hartke, Francesca Palombini, Alexander Pelov,
Goran Selander. Goran Selander.
11. Normative References 11. Normative References
[I-D.ietf-core-object-security]
Selander, G., Mattsson, J., Palombini, F., and L. Seitz,
"Object Security for Constrained RESTful Environments
(OSCORE)", draft-ietf-core-object-security-16 (work in
progress), March 2019.
[I-D.ietf-lpwan-ipv6-static-context-hc] [I-D.ietf-lpwan-ipv6-static-context-hc]
Minaburo, A., Toutain, L., Gomez, C., Barthel, D., and J. Minaburo, A., Toutain, L., Gomez, C., Barthel, D., and J.
Zuniga, "Static Context Header Compression (SCHC) and Zuniga, "Static Context Header Compression (SCHC) and
fragmentation for LPWAN, application to UDP/IPv6", draft- fragmentation for LPWAN, application to UDP/IPv6", draft-
ietf-lpwan-ipv6-static-context-hc-19 (work in progress), ietf-lpwan-ipv6-static-context-hc-21 (work in progress),
July 2019. July 2019.
[I-D.toutain-core-time-scale]
Minaburo, A. and L. Toutain, "CoAP Time Scale Option",
draft-toutain-core-time-scale-00 (work in progress),
October 2017.
[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>.
[rfc7959] Bormann, C. and Z. Shelby, Ed., "Block-Wise Transfers in [rfc7959] Bormann, C. and Z. Shelby, Ed., "Block-Wise Transfers in
the Constrained Application Protocol (CoAP)", RFC 7959, the Constrained Application Protocol (CoAP)", RFC 7959,
DOI 10.17487/RFC7959, August 2016, DOI 10.17487/RFC7959, August 2016,
<https://www.rfc-editor.org/info/rfc7959>. <https://www.rfc-editor.org/info/rfc7959>.
[rfc7967] Bhattacharyya, A., Bandyopadhyay, S., Pal, A., and T. [rfc7967] Bhattacharyya, A., Bandyopadhyay, S., Pal, A., and T.
Bose, "Constrained Application Protocol (CoAP) Option for Bose, "Constrained Application Protocol (CoAP) Option for
No Server Response", RFC 7967, DOI 10.17487/RFC7967, No Server Response", RFC 7967, DOI 10.17487/RFC7967,
August 2016, <https://www.rfc-editor.org/info/rfc7967>. August 2016, <https://www.rfc-editor.org/info/rfc7967>.
[rfc8613] Selander, G., Mattsson, J., Palombini, F., and L. Seitz,
"Object Security for Constrained RESTful Environments
(OSCORE)", RFC 8613, DOI 10.17487/RFC8613, July 2019,
<https://www.rfc-editor.org/info/rfc8613>.
Authors' Addresses Authors' Addresses
Ana Minaburo Ana Minaburo
Acklio Acklio
1137A avenue des Champs Blancs 1137A avenue des Champs Blancs
35510 Cesson-Sevigne Cedex 35510 Cesson-Sevigne Cedex
France France
Email: ana@ackl.io Email: ana@ackl.io
Laurent Toutain Laurent Toutain
Institut MINES TELECOM; IMT Atlantique Institut MINES TELECOM; IMT Atlantique
2 rue de la Chataigneraie 2 rue de la Chataigneraie
CS 17607 CS 17607
35576 Cesson-Sevigne Cedex 35576 Cesson-Sevigne Cedex
France France
Email: Laurent.Toutain@imt-atlantique.fr Email: Laurent.Toutain@imt-atlantique.fr
Ricardo Andreasen Ricardo Andreasen
 End of changes. 49 change blocks. 
153 lines changed or deleted 151 lines changed or added

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