draft-ietf-lpwan-coap-static-context-hc-11.txt   draft-ietf-lpwan-coap-static-context-hc-12.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: April 11, 2020 Institut MINES TELECOM; IMT Atlantique Expires: June 12, 2020 Institut MINES TELECOM; IMT Atlantique
R. Andreasen R. Andreasen
Universidad de Buenos Aires Universidad de Buenos Aires
October 09, 2019 December 10, 2019
LPWAN Static Context Header Compression (SCHC) for CoAP LPWAN Static Context Header Compression (SCHC) for CoAP
draft-ietf-lpwan-coap-static-context-hc-11 draft-ietf-lpwan-coap-static-context-hc-12
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 messages options, themselves of variable length. The CoAP protocol messages
format is asymmetric: the request messages have a header format format is asymmetric: the request messages have a header format
different from the one in the response messages. This document different from the one in the response messages. This document
explains how to use the SCHC compression mechanism for CoAP. explains how to use the SCHC compression mechanism for CoAP.
skipping to change at page 1, line 39 skipping to change at page 1, line 39
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 April 11, 2020. This Internet-Draft will expire on June 12, 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
skipping to change at page 2, line 20 skipping to change at page 2, line 20
Table of Contents Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2
1.1. Terminology . . . . . . . . . . . . . . . . . . . . . . . 3 1.1. Terminology . . . . . . . . . . . . . . . . . . . . . . . 3
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 . . . . . . . . . . . . . . . . . . 7
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 . . . . 8 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 . . . . . . . 9 5.3.1. Variable length Uri-Path and Uri-Query . . . . . . . 9
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 . . . . . . . . . . . . . . . . 10 and Location-Query fields . . . . . . . . . . . . . . . . 10
6. Other RFCs . . . . . . . . . . . . . . . . . . . . . . . . . 10 6. Other RFCs . . . . . . . . . . . . . . . . . . . . . . . . . 10
6.1. Block . . . . . . . . . . . . . . . . . . . . . . . . . . 10 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 . . . . . . . . . . . . . . . . . . . . . . . . . 11
7. Examples of CoAP header compression . . . . . . . . . . . . . 12 7. Examples of CoAP header compression . . . . . . . . . . . . . 12
7.1. Mandatory header with CON message . . . . . . . . . . . . 12 7.1. Mandatory header with CON message . . . . . . . . . . . . 12
7.2. OSCORE Compression . . . . . . . . . . . . . . . . . . . 13 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
skipping to change at page 3, line 34 skipping to change at page 3, line 34
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. After applying the significant bits of the field or send an index. After applying the
compression there may be some bits to be sent, these values are compression there may be some bits to be sent, these values are
called Compression Residues and are transmitted after the Rule ID in called Compression Residues and are transmitted after the Rule ID in
the compressed messages. 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.
particular version of CoAP.
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. SCHC Compression Process 2. SCHC Compression Process
skipping to change at page 4, line 21 skipping to change at page 4, line 21
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 the complete header stack In the first example, a rule compresses the complete header stack
from IPv6 to CoAP. In this case, SCHC C/D is performed at the device from IPv6 to CoAP. In this case, SCHC C/D (Static Context Header
and at the LPWAN boundary. Compression Compressor/Decompressor) is performed at the device 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. The SCHC compression is between the device and the application. The SCHC compression is
applied in the CoAP layer compressing the CoAP header independently applied in the CoAP layer compressing the CoAP header independently
of the other layers. The rule ID and the compression residue are of the other layers. The rule ID and the compression residue are
encrypted using a mechanism such as DTLS. Only the other end can encrypted using a mechanism such as DTLS. Only the other end can
decipher the information. Layers below may also be compressed using decipher the information. Layers below may also be compressed using
other SCHC rules (this is out of the scope of this document) as 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. defined in the SCHC [I-D.ietf-lpwan-ipv6-static-context-hc] document.
skipping to change at page 6, line 7 skipping to change at page 6, line 7
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 never modifies the The SCHC compression-decompression process never modifies the
Values it only reduces their sizes. Nevertheless, a proxy placed Values it only reduces their sizes. Nevertheless, a proxy placed
before the compressor may change some field values to allow SCHC before the compressor may change some field values to allow SCHC
achieving a better compression ratio, while maintaining the achieving a better compression ratio, while maintaining the
necessary context for interoperability with existing CoAP necessary context for interoperability with existing CoAP
implementations. implementations.
o If no valid Rule was found, then the packet MUST be sent
uncompressed using the RuleID dedicated to this purpose and the
Compression Residue is the complete header of the packet. See
section 6 of [I-D.ietf-lpwan-ipv6-static-context-hc].
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
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
skipping to change at page 13, line 15 skipping to change at page 13, 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 sensible information which is not necessary for proxy contains sensitive information which 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 format of a regular CoAP message, and
includes all Options and information needed for proxy operation and includes all Options and information needed for proxy operation and
caching. This decomposition is illustrated in Figure 6. caching. This decomposition is illustrated in Figure 6.
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,
skipping to change at page 26, line 44 skipping to change at page 26, line 44
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-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-21 (work in progress), ietf-lpwan-ipv6-static-context-hc-24 (work in progress),
July 2019. December 2019.
[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>.
[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>.
 End of changes. 11 change blocks. 
13 lines changed or deleted 18 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/