< 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.48. The latest version is available from http://tools.ietf.org/tools/rfcdiff/