idnits 2.17.00 (12 Aug 2021) /tmp/idnits8580/draft-ietf-lpwan-coap-static-context-hc-04.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- ** The document seems to lack a Security Considerations section. ** The document seems to lack an IANA Considerations section. (See Section 2.2 of https://www.ietf.org/id-info/checklist for how to handle the case when there are no actions for IANA.) ** There are 17 instances of too long lines in the document, the longest one being 2 characters in excess of 72. ** The abstract seems to contain references ([I-D.ietf-lpwan-ipv6-static-context-hc]), which it shouldn't. Please replace those with straight textual mentions of the documents in question. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year == Line 338 has weird spacing: '... equal not...' == Line 340 has weird spacing: '... ignore valu...' == Line 364 has weird spacing: '... ignore val...' == Line 839 has weird spacing: '... mid tkn p...' == Line 855 has weird spacing: '... mid tkn...' -- The document date (July 02, 2018) is 1419 days in the past. Is this intentional? Checking references for intended status: Informational ---------------------------------------------------------------------------- == Missing Reference: 'CON' is mentioned on line 237, but not defined == Missing Reference: 'NON' is mentioned on line 237, but not defined == Missing Reference: 'ACK' is mentioned on line 237, but not defined == Missing Reference: 'RST' is mentioned on line 237, but not defined -- Looks like a reference, but probably isn't: '69' on line 879 -- Looks like a reference, but probably isn't: '132' on line 879 == Outdated reference: draft-ietf-core-object-security has been published as RFC 8613 == Outdated reference: draft-ietf-lpwan-ipv6-static-context-hc has been published as RFC 8724 Summary: 4 errors (**), 0 flaws (~~), 12 warnings (==), 3 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 lpwan Working Group A. Minaburo 3 Internet-Draft Acklio 4 Intended status: Informational L. Toutain 5 Expires: January 3, 2019 Institut MINES TELECOM; IMT Atlantique 6 R. Andreasen 7 Universidad de Buenos Aires 8 July 02, 2018 10 LPWAN Static Context Header Compression (SCHC) for CoAP 11 draft-ietf-lpwan-coap-static-context-hc-04 13 Abstract 15 This draft defines the way SCHC header compression can be applied to 16 CoAP headers. CoAP header structure differs from IPv6 and UDP 17 protocols since the CoAP 18 use a flexible header with a variable number of options themself of a 19 variable length. Another important difference is the asymmetry in 20 the header format used in request and response messages. Most of the 21 compression mechanisms have been introduced in 22 [I-D.ietf-lpwan-ipv6-static-context-hc], this document explains how 23 to use the SCHC compression for CoAP. 25 Status of This Memo 27 This Internet-Draft is submitted in full conformance with the 28 provisions of BCP 78 and BCP 79. 30 Internet-Drafts are working documents of the Internet Engineering 31 Task Force (IETF). Note that other groups may also distribute 32 working documents as Internet-Drafts. The list of current Internet- 33 Drafts is at https://datatracker.ietf.org/drafts/current/. 35 Internet-Drafts are draft documents valid for a maximum of six months 36 and may be updated, replaced, or obsoleted by other documents at any 37 time. It is inappropriate to use Internet-Drafts as reference 38 material or to cite them other than as "work in progress." 40 This Internet-Draft will expire on January 3, 2019. 42 Copyright Notice 44 Copyright (c) 2018 IETF Trust and the persons identified as the 45 document authors. All rights reserved. 47 This document is subject to BCP 78 and the IETF Trust's Legal 48 Provisions Relating to IETF Documents 49 (https://trustee.ietf.org/license-info) in effect on the date of 50 publication of this document. Please review these documents 51 carefully, as they describe your rights and restrictions with respect 52 to this document. Code Components extracted from this document must 53 include Simplified BSD License text as described in Section 4.e of 54 the Trust Legal Provisions and are provided without warranty as 55 described in the Simplified BSD License. 57 Table of Contents 59 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3 60 2. SCHC Compression Process . . . . . . . . . . . . . . . . . . 3 61 3. CoAP Compression with SCHC . . . . . . . . . . . . . . . . . 4 62 4. Compression of CoAP header fields . . . . . . . . . . . . . . 6 63 4.1. CoAP version field . . . . . . . . . . . . . . . . . . . 6 64 4.2. CoAP type field . . . . . . . . . . . . . . . . . . . . . 6 65 4.3. CoAP code field . . . . . . . . . . . . . . . . . . . . . 6 66 4.4. CoAP Message ID field . . . . . . . . . . . . . . . . . . 6 67 4.5. CoAP Token fields . . . . . . . . . . . . . . . . . . . . 7 68 5. CoAP options . . . . . . . . . . . . . . . . . . . . . . . . 7 69 5.1. CoAP Content and Accept options. . . . . . . . . . . . . 7 70 5.2. CoAP option Max-Age field, CoAP option Uri-Host and Uri- 71 Port fields . . . . . . . . . . . . . . . . . . . . . . . 7 72 5.3. CoAP option Uri-Path and Uri-Query fields . . . . . . . . 8 73 5.3.1. Variable length Uri-Path and Uri-Query . . . . . . . 8 74 5.3.2. Variable number of path or query elements . . . . . . 9 75 5.4. CoAP option Size1, Size2, Proxy-URI and Proxy-Scheme 76 fields . . . . . . . . . . . . . . . . . . . . . . . . . 9 77 5.5. CoAP option ETag, If-Match, If-None-Match, Location-Path 78 and Location-Query fields . . . . . . . . . . . . . . . . 9 79 6. Other RFCs . . . . . . . . . . . . . . . . . . . . . . . . . 9 80 6.1. Block . . . . . . . . . . . . . . . . . . . . . . . . . . 9 81 6.2. Observe . . . . . . . . . . . . . . . . . . . . . . . . . 10 82 6.3. No-Response . . . . . . . . . . . . . . . . . . . . . . . 10 83 6.4. Time Scale . . . . . . . . . . . . . . . . . . . . . . . 10 84 6.5. OSCORE . . . . . . . . . . . . . . . . . . . . . . . . . 10 85 7. Examples of CoAP header compression . . . . . . . . . . . . . 12 86 7.1. Mandatory header with CON message . . . . . . . . . . . . 12 87 7.2. Complete exchange . . . . . . . . . . . . . . . . . . . . 13 88 7.3. OSCORE Compression . . . . . . . . . . . . . . . . . . . 14 89 7.4. Example OSCORE Compression . . . . . . . . . . . . . . . 17 90 8. Normative References . . . . . . . . . . . . . . . . . . . . 22 91 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 22 93 1. Introduction 95 CoAP [rfc7252] is an implementation of the REST architecture for 96 constrained devices. Nevertheless, if limited, the size of a CoAP 97 header may be too large for LPWAN constraints and some compression 98 may be needed to reduce the header size. 100 [I-D.ietf-lpwan-ipv6-static-context-hc] defines a header compression 101 mechanism for LPWAN network based on a static context. The context 102 is said static since the field description composing the Rules and 103 the context are not learned during the packet exchanges but are 104 previously defined. The context(s) is(are) known by both ends before 105 transmission. 107 A context is composed of a set of rules that are referenced by Rule 108 IDs (identifiers). A rule contains an ordered list of the fields 109 descriptions containing a field ID (FID), its length (FL) and its 110 position (FP), a direction indicator (DI) (upstream, downstream and 111 bidirectional) and some associated Target Values (TV). Target Value 112 indicates the value that can be expected. TV can also be a list of 113 values. A Matching Operator (MO) is associated to each header field 114 description. The rule is selected if all the MOs fit the TVs for all 115 fields. In that case, a Compression/Decompression Action (CDA) 116 associated to each field defines the link between the compressed and 117 decompressed value for each of the header fields. Compression 118 results mainly in 4 actions: send the field value, send nothing, send 119 less significant bits of a field, send an index. Values sent are 120 called Compression Residues and follows the rule ID. 122 2. SCHC Compression Process 124 The SCHC Compression rules can be applied to CoAP flows. SCHC 125 Compression of the CoAP header may be done in conjunction with the 126 above layers (IPv6/UDP) or independently. The SCHC adaptation layers 127 as described in [I-D.ietf-lpwan-ipv6-static-context-hc] may be used 128 as as shown in the Figure 1. 130 ^ +------------+ ^ +------------+ ^ +------------+ 131 | | CoAP | | | CoAP | inner | | CoAP | 132 | +------------+ v +------------+ x | OSCORE | 133 | | UDP | | DTLS | outer | +------------+ 134 | +------------+ +------------+ | | UDP | 135 | | IPv6 | | UDP | | +------------+ 136 v +------------+ +------------+ | | IPv6 | 137 | IPv6 | v +------------+ 138 +------------+ 140 Figure 1: rule scope for CoAP 142 Figure 1 shows some examples for CoAP architecture and the SCHC 143 rule's scope. A rule can covers all headers from IPv6 to CoAP, SCHC 144 C/D is done in the device and at the LPWAN boundary. If an end-to- 145 end encryption mechanisms is used between the device and the 146 application. CoAP must be compressed independently of the other 147 layers. The rule ID and the compression residue are encrypted using 148 a mechanism such as DTLS. Only the other end can decipher the 149 information. 150 Layers below may also be compressed using other SCHC rules (this is 151 out of the scope of this document). OSCORE 152 [I-D.ietf-core-object-security] can also define 2 rules to compress 153 the CoAP message. A first rule focuses on the inner header and is 154 end to end, a second rule may compress the outer header and the layer 155 above. SCHC C/D for inner header is done by both ends, SCHC C/D for 156 outer header and other headers is done between the device and the 157 LPWAN boundary. 159 3. CoAP Compression with SCHC 161 CoAP differs from IPv6 and UDP protocols on the following aspects: 163 o IPv6 and UDP are symmetrical protocols. The same fields are found 164 in the request and in the response, only the location in the 165 header may vary (e.g. source and destination fields). A CoAP 166 request is different from a response. For example, the URI-path 167 option is mandatory in the request and is not found in the 168 response, a request may contain an Accept option and the response 169 a Content option. 171 [I-D.ietf-lpwan-ipv6-static-context-hc] defines the use of a 172 message direction (DI) when processing the rule which allows the 173 description of message header format in both directions. 175 o Even when a field is "symmetric" (i.e. found in both directions) 176 the values carried in each direction are different. Combined with 177 a matching list in the TV, this will allow to reduce the range of 178 expected values in a particular direction and therefore reduce the 179 size of a compression residue. For instance, if a client sends 180 only CON request, the type can be elided by compression and the 181 answer may use one bit to carry either the ACK or RST type. Same 182 behavior can be applied to the CoAP Code field (0.0X code are 183 present in the request and Y.ZZ in the answer). The direction 184 allows to split in two parts the possible values for each 185 direction. 187 o In IPv6 and UDP header fields have a fixed size. In CoAP, Token 188 size may vary from 0 to 8 bytes, length is given by a field in the 189 header. More systematically, the CoAP options are described using 190 the Type-Length-Value. 192 [I-D.ietf-lpwan-ipv6-static-context-hc] offers the possibility to 193 define a function for the Field Length in the Field Description. 195 o In CoAP headers, a field can be duplicated several times, for 196 instances, elements of an URI (path or queries). The position 197 defined in a rule, associated to a Field ID, can be used to 198 identify the proper element. 200 [I-D.ietf-lpwan-ipv6-static-context-hc] allows a Field id to 201 appears several times in the rule, the Field Position (FP) removes 202 ambiguities for the matching operation. 204 o Field size defined in the CoAP protocol can be to large regarding 205 LPWAN traffic constraints. This is particularly true for the 206 message ID field or Token field. The use of MSB MO can be used to 207 reduce the information carried on LPWANs. 209 o CoAP also obeys to the client/server paradigm and the compression 210 rate can be different if the request is issued from an LPWAN node 211 or from an non LPWAN device. For instance a Device (Dev) aware of 212 LPWAN constraints can generate a 1 byte token, but a regular CoAP 213 client will certainly send a larger token to the Thing. SCHC 214 compression will not modify the values to offer a better 215 compression rate. Nevertheless a proxy placed before the 216 compressor may change some field values to offer a better 217 compression rate and maintain the necessary context for 218 interoperability with existing CoAP implementations. 220 4. Compression of CoAP header fields 222 This section discusses of the compression of the different CoAP 223 header fields. 225 4.1. CoAP version field 227 This field is bidirectional and must be elided during the SCHC 228 compression, since it always contains the same value. In the future, 229 if new version of CoAP are defined, new rules ID will be defined 230 avoiding ambiguities between versions. 232 4.2. CoAP type field 234 [rfc7252] defines 4 types of messages: CON, NON, ACK and RST. The 235 latter two ones are a response of the two first ones. If the device 236 plays a specific role, a rule can exploit these property with the 237 mapping list: [CON, NON] for one direction and [ACK, RST] for the 238 other direction. Compression residue is reduced to 1 bit. 240 The field must be elided if for instance a client is sending only NON 241 or CON messages. 243 In any case, a rule must be defined to carry RST to a client. 245 4.3. CoAP code field 247 The compression of the CoAP code field follows the same principle as 248 for the CoAP type field. If the device plays a specific role, the 249 set of code values can be split in two parts, the request codes with 250 the 0 class and the response values. 252 If the device implement only a CoAP client, the request code can be 253 reduced to the set of request the client is able to process. 255 All the response codes should be compressed with a SCHC rule. 257 4.4. CoAP Message ID field 259 This field is bidirectional and is used to manage acknowledgments. 260 Server memorizes the value for a EXCHANGE_LIFETIME period (by default 261 247 seconds) for CON messages and a NON_LIFETIME period (by default 262 145 seconds) for NON messages. During that period, a server 263 receiving the same Message ID value will process the message has a 264 retransmission. After this period, it will be processed as a new 265 messages. 267 In case the Device is a client, the size of the message ID field may 268 the too large regarding the number of messages sent. Client may use 269 only small message ID values, for instance 4 bit long. Therefore a 270 MSB can be used to limit the size of the compression residue. 272 In case the Device is a server, client may be located outside of the 273 LPWAN area and view the device as a regular device connected to the 274 internet. The client will generate Message ID using the 16 bits 275 space offered by this field. A CoAP proxy can be set before the SCHC 276 C/D to reduce the value of the Message ID, to allow its compression 277 with the MSB matching operator and LSB CDA. 279 4.5. CoAP Token fields 281 Token is defined through two CoAP fields, Token Length in the 282 mandatory header and Token Value directly following the mandatory 283 CoAP header. 285 Token Length is processed as a tradition protocol field. If the 286 value remains the same during all the transaction, the size can be 287 stored in the context and elided during the transmission. Otherwise 288 it will have to the send as a compression residue. 290 Token Value size should not be defined directly in the rule in the 291 Field Length (FL). Instead a specific function designed as "TKL" 292 must be used. This function informs the SCHC C/D that the length of 293 this field has to be read from the Token Length field. 295 5. CoAP options 297 5.1. CoAP Content and Accept options. 299 These field are both unidirectional and must not be set to 300 bidirectional in a rule entry. 302 If single value is expected by the client, it can be stored in the TV 303 and elided during the transmission. Otherwise, if several possible 304 values are expected by the client, a matching-list should be used to 305 limit the size of the residue. If not the possible, the value as to 306 be sent as a residue (fixed or variable length). 308 5.2. CoAP option Max-Age field, CoAP option Uri-Host and Uri-Port 309 fields 311 This field is unidirectional and must not be set to bidirectional in 312 a rule entry. It is used only by the server to inform of the caching 313 duration and is never found in client requests. 315 If the duration is known by both ends, value can be elided on the 316 LPWAN. 318 A matching list can be used if some well-known values are defined. 320 Otherwise these options should be sent as a residue (fixed or 321 variable length). 323 5.3. CoAP option Uri-Path and Uri-Query fields 325 This fields are unidirectional and must not be set to bidirectional 326 in a rule entry. They are used only by the client to access to a 327 specific resource and are never found in server responses. 329 Uri-Path and Uri-Query elements are a repeatable options, the Field 330 Position (FP) gives the position in the path. 332 A Mapping list can be used to reduce size of variable Paths or 333 Queries. In that case, to optimize the compression, several elements 334 can be regrouped into a single entry. Numbering of elements do not 335 change, MO comparison is set with the first element of the matching. 337 FID FL FP DI TV MO CDA 338 URI-Path 1 up ["/a/b", equal not-sent 339 "/c/d"] 340 URI-Path 3 up ignore value-sent 342 Figure 2: complex path example 344 In Figure 2 a single bit residue can be used to code one of the 2 345 paths. If regrouping was not allowed, a 2 bits residue whould have 346 been needed. 348 5.3.1. Variable length Uri-Path and Uri-Query 350 When the length is known at the rule creation, the Field Length must 351 be set to variable, and the unit is set to bytes. 353 The MSB MO can be apply to a Uri-Path or Uri-Query element. Since 354 MSB value is given in bit, the size must always be a multiple of 8 355 bits and the LSB CDA must not carry any value. 357 The length sent at the beginning of a variable length residue 358 indicates the size of the LSB in bytes. 360 For instance for a CoMi path /c/X6?k="eth0" the rule can be set to: 362 FID FL FP DI TV MO CDA 363 URI-Path 1 up "c" equal not-sent 364 URI-Path 2 up ignore value-sent 365 URI-Query 1 up "k=" MSB (16) LSB 367 Figure 3: CoMi URI compression 369 Figure 3 shows the parsing and the compression of the URI. where c is 370 not sent. The second element is sent with the length (i.e. 0x2 X 6) 371 followed by the query option (i.e. 0x05 "eth0"). 373 5.3.2. Variable number of path or query elements 375 The number of Uri-path or Uri-Query element in a rule is fixed at the 376 rule creation time. If the number varies, several rules should be 377 created to cover all the possibilities. Another possibilities is to 378 define the length of Uri-Path to variable and send a compression 379 residue with a length of 0 to indicate that this Uri-Path is empty. 380 This add 4 bits to the compression residue. 382 5.4. CoAP option Size1, Size2, Proxy-URI and Proxy-Scheme fields 384 These fields are unidirectional and must not be set to bidirectional 385 in a rule entry. They are used only by the client to access to a 386 specific resource and are never found in server response. 388 If the field value must be sent, TV is not set, MO is set to "ignore" 389 and CDF is set to "value-sent. A mapping can also be used. 391 Otherwise the TV is set to the value, MO is set to "equal" and CDF is 392 set to "not-sent" 394 5.5. CoAP option ETag, If-Match, If-None-Match, Location-Path and 395 Location-Query fields 397 These fields are unidirectional. 399 These fields values cannot be stored in a rule entry. They must 400 always be sent with the compression residues. 402 6. Other RFCs 404 6.1. Block 406 Block [rfc7959] allows a fragmentation at the CoAP level. SCHC 407 includes also a fragmentation protocol. They are compatible. If a 408 block option is used, its content must be sent as a compression 409 residue. 411 6.2. Observe 413 [rfc7641] defines the Observe option. The TV is not set, MO is set 414 to "ignore" and the CDF is set to "value-sent". SCHC does not limit 415 the maximum size for this option (3 bytes). To reduce the 416 transmission size either the device implementation should limit the 417 value increase or a proxy can modify the incrementation. 419 Since RST message may be sent to inform a server that the client do 420 not require Observe response, a rule must allow the transmission of 421 this message. 423 6.3. No-Response 425 [rfc7967] defines an No-Response option limiting the responses made 426 by a server to a request. If the value is not known by both ends, 427 then TV is set to this value, MO is set to "equal" and CDF is set to 428 "not-sent". 430 Otherwise, if the value is changing over time, TV is not set, MO is 431 set to "ignore" and CDA to "value-sent". A matching list can also be 432 used to reduce the size. 434 6.4. Time Scale 436 Time scale [I-D.toutain-core-time-scale] option allows a client to 437 inform the server that it is in a slow network and that message ID 438 should be kept for a duration given by the option. 440 If the value is not known by both ends, then TV is set to this value, 441 MO is set to "equal" and CDA is set to "not-sent". 443 Otherwise, if the value is changing over time, TV is not set, MO is 444 set to "ignore" and CDA to "value-sent". A matching list can also be 445 used to reduce the size. 447 6.5. OSCORE 449 OSCORE [I-D.ietf-core-object-security] defines end-to-end protection 450 for CoAP messages. This section describes how SCHC rules can be 451 applied to compress OSCORE-protected messages. 453 0 1 2 3 4 5 6 7 <--------- n bytes -------------> 454 +-+-+-+-+-+-+-+-+--------------------------------- 455 |0 0 0|h|k| n | Partial IV (if any) ... 456 +-+-+-+-+-+-+-+-+--------------------------------- 457 | | 458 | <--------- CoAP OSCORE_piv ------------------> | 460 <- 1 byte -> <------ s bytes -----> 461 +------------+----------------------+-----------------------+ 462 | s (if any) | kid context (if any) | kid (if any) ... | 463 +------------+----------------------+-----------------------+ 464 | | | 465 | <------ CoAP OSCORE_kidctxt ----->|<-- CoAP OSCORE_kid -->| 467 Figure 4: OSCORE Option 469 The encoding of the OSCORE Option Value defined in Section 6.1 of 470 [I-D.ietf-core-object-security] is repeated in Figure 4. 472 The first byte is used for flags that specify the contents of the 473 OSCORE option. The 3 most significant bits are reserved and always 474 set to 0. Bit h, when set, indicates the presence of the kid context 475 field in the option. Bit k, when set, indicates the presence of a 476 kid field. The 3 least significant bits n indicate to length of the 477 piv field in bytes, n = 0 taken to mean that no piv is present. 479 After the flag byte follow the piv field, kid context field and kid 480 field in order and if present; the length of the kid context field is 481 encoded in the first byte denoting by s the length of the kid context 482 in bytes. 484 This draft recommends to implement a parser that is able to identify 485 the OSCORE Option and the fields it contains - this makes it possible 486 to do a preliminary processing of the message in preparation for 487 regular SCHC compression. 489 Conceptually, the OSCORE option can transmit up to 3 distinct pieces 490 of information at a time: the piv, the kid context, and the kid. 491 This draft proposes that the SCHC Parser split the contents of this 492 option into 3 SCHC fields: 494 o CoAP OSCORE_piv, 496 o CoAP OSCORE_ctxt, 498 o CoAP OSCORE_kid. 500 These fields are superposed on the OSCORE Option format in Figure 4, 501 and include the corresponding flag and size bits for each part of the 502 option. Both the flag and size bits can be omitted by use of the MSB 503 matching operator on each field. 505 7. Examples of CoAP header compression 507 7.1. Mandatory header with CON message 509 In this first scenario, the LPWAN compressor receives from outside 510 client a POST message, which is immediately acknowledged by the 511 Device. For this simple scenario, the rules are described Figure 5. 513 Rule ID 1 514 +-------------+--+--+--+------+---------+-------------++------------+ 515 | Field |FL|FP|DI|Target| Match | CDA || Sent | 516 | | | | |Value | Opera. | || [bits] | 517 +-------------+--+--+--+------+---------+-------------++------------+ 518 |CoAP version | | |bi| 01 |equal |not-sent || | 519 |CoAP version | | |bi| 01 |equal |not-sent || | 520 |CoAP Type | | |dw| CON |equal |not-sent || | 521 |CoAP Type | | |up|[ACK, | | || | 522 | | | | | RST] |match-map|matching-sent|| T | 523 |CoAP TKL | | |bi| 0 |equal |not-sent || | 524 |CoAP Code | | |bi| ML1 |match-map|matching-sent|| CC CCC | 525 |CoAP MID | | |bi| 0000 |MSB(7 ) |LSB(9) || M-ID| 526 |CoAP Uri-Path| | |dw| path |equal 1 |not-sent || | 527 +-------------+--+--+--+------+---------+-------------++------------+ 529 Figure 5: CoAP Context to compress header without token 531 The version and Token Length fields are elided. Code has shrunk to 5 532 bits using a matching list. Uri-Path contains a single element 533 indicated in the matching operator. 535 Figure 6 shows the time diagram of the exchange. A client in the 536 Application Server sends a CON request. It can go through a proxy 537 which reduces the message ID to a smallest value, with at least the 9 538 most significant bits equal to 0. SCHC Compression reduces the 539 header sending only the Type, a mapped code and the least 9 540 significant bits of Message ID. 542 Device LPWAN SCHC C/D 543 | | 544 | rule id=1 |<-------------------- 545 |<-------------------| +-+-+--+----+------+ 546 <------------------- | CCCCCMMMMMMMMM | |1|0| 4|0.01|0x0034| 547 +-+-+--+----+-------+ | 00001000110100 | | 0xb4 p a t| 548 |1|0| 1|0.01|0x0034 | | | | h | 549 | 0xb4 p a t | | | +------+ 550 | h | | | 551 +------+ | | 552 | | 553 | | 554 ---------------------->| rule id=1 | 555 +-+-+--+----+--------+ |------------------->| 556 |1|2| 0|2.05| 0x0034 | | TCCCCCMMMMMMMMM |---------------------> 557 +-+-+--+----+--------+ | 001100000110100 | +-+-+--+----+------+ 558 | | |1|2| 0|2.05|0x0034| 559 v v +-+-+--+----+------+ 561 Figure 6: Compression with global addresses 563 7.2. Complete exchange 565 In that example, the Thing is using CoMi and sends queries for 2 SID. 567 CON 568 MID=0x0012 | | 569 POST | | 570 Accept X | | 571 /c/k=AS |------------------------>| 572 | | 573 | | 574 |<------------------------| ACK MID=0x0012 575 | | 0.00 576 | | 577 | | 578 |<------------------------| CON 579 | | MID=0X0034 580 | | Content-Format X 581 ACK MID=0x0034 |------------------------>| 582 0.00 584 7.3. OSCORE Compression 586 OSCORE aims to solve the problem of end-to-end encryption for CoAP 587 messages, which are otherwise required to terminate their TLS or DTLS 588 protection at the proxy, as discussed in Section 11.2 of [rfc7252]. 589 CoAP proxies are men-in-the-middle, but not all of the information 590 they have access to is necessary for their operation. The goal, 591 therefore, is to hide as much of the message as possible while still 592 enabling proxy operation. 594 Conceptually this is achieved by splitting the CoAP message into an 595 Inner Plaintext and Outer OSCORE Message. The Inner Plaintext 596 contains sensible information which is not necessary for proxy 597 operation. This, in turn, is the part of the message which can be 598 encrypted and need not be decrypted until it reaches its end 599 destination. The Outer Message acts as a shell matching the format 600 of a regular CoAP message, and includes all Options and information 601 needed for proxy operation and caching. This decomposition is 602 illustrated in Figure 7. 604 CoAP options are sorted into one of 3 classes, each granted a 605 specific type of protection by the protocol: 607 o Class E: Enrypted options moved to the Inner Plaintext, 609 o Class I: Intergrity-protected options included in the AAD for the 610 encryption of the Plaintext but otherwise left untouched in the 611 Outer Message, 613 o Class U: Unprotected options left untouched in the Outer Message. 615 Additionally, the OSCORE Option is added as an Outer option, 616 signaling that the message is OSCORE protected. This option carries 617 the information necessary to retrieve the Security Context with which 618 the message was encrypted so that it may be correctly decrypted at 619 the other end-point. 621 Orignal CoAP Message 622 +-+-+---+-------+---------------+ 623 |v|t|tkl| code | Msg Id. | 624 +-+-+---+-------+---------------+....+ 625 | Token | 626 +-------------------------------.....+ 627 | Options (IEU) | 628 . . 629 . . 630 +------+-------------------+ 631 | 0xFF | 632 +------+------------------------+ 633 | | 634 | Payload | 635 | | 636 +-------------------------------+ 637 / \ 638 / \ 639 / \ 640 / \ 641 Outer Header v v Plaintext 642 +-+-+---+--------+---------------+ +-------+ 643 |v|t|tkl|new code| Msg Id. | | code | 644 +-+-+---+--------+---------------+....+ +-------+-----......+ 645 | Token | | Options (E) | 646 +--------------------------------.....+ +-------+------.....+ 647 | Options (IU) | | OxFF | 648 . . +-------+-----------+ 649 . OSCORE Option . | | 650 +------+-------------------+ | Payload | 651 | 0xFF | | | 652 +------+ +-------------------+ 654 Figure 7: OSCORE inner and outer header form a CoAP message 656 Figure 7 shows the message format for the OSCORE Message and 657 Plaintext. In the Outer Header, the original message code is hidden 658 and replaced by a default value (POST or FETCH) depending on whether 659 the original message was a Request or a Response. The original 660 message code is put into the first byte of the Plaintext. Following 661 the message code come the class E options and if present the original 662 message Payload preceded by its payload marker. 664 The Plaintext is now encrypted by an AEAD algorithm which integrity 665 protects Security Context parameters and eventually any class I 666 options from the Outer Header. Currently no CoAP options are marked 667 class I. The resulting Ciphertext becomes the new Payload of the 668 OSCORE message, as illustrated in Figure 8. 670 Outer Header 671 +-+-+---+--------+---------------+ 672 |v|t|tkl|new code| Msg Id. | 673 +-+-+---+--------+---------------+....+ 674 | Token | 675 +--------------------------------.....+ 676 | Options (IU) | 677 . . 678 . OSCORE Option . 679 +------+-------------------+ 680 | 0xFF | 681 +------+-------------------------+ 682 | | 683 | Encrypted Inner Header and | 684 | Payload | 685 | | 686 +--------------------------------+ 688 Figure 8: OSCORE message 690 The SCHC Compression scheme consists of compressing both the 691 Plaintext before encryption and the resulting OSCORE message after 692 encryption, see Figure 9. This way compression reaches all fields of 693 the original CoAP message. 695 Outer Message OSCORE Plaintext 696 +-+-+---+--------+---------------+ +-------+ 697 |v|t|tkl|new code| Msg Id. | | code | 698 +-+-+---+--------+---------------+....+ +-------+-----......+ 699 | Token | | Options (E) | 700 +--------------------------------.....+ +-------+------.....+ 701 | Options (IU) | | OxFF | 702 . . +-------+-----------+ 703 . OSCORE Option . | | 704 +------+-------------------+ | Payload | 705 | 0xFF | | | 706 +------+------------+ +-------------------+ 707 | Ciphertext |<---------\ | 708 | | | v 709 +-------------------+ | +-----------------+ 710 | | | Inner SCHC | 711 v | | Compression | 712 +-----------------+ | +-----------------+ 713 | Outer SCHC | | | 714 | Compression | | v 715 +-----------------+ | +-------+ 716 | | |Rule ID| 717 v | +-------+--+ 718 +--------+ +------------+ | Residue | 719 |Rule ID'| | Encryption | <--- +----------+--------+ 720 +--------+--+ +------------+ | | 721 | Residue' | | Payload | 722 +-----------+-------+ | | 723 | Ciphertext | +-------------------+ 724 | | 725 +-------------------+ 727 Figure 9: OSCORE Compression Diagram 729 7.4. Example OSCORE Compression 731 In what follows we present an example GET Request and consequent 732 CONTENT Response and show a possible set of rules for the Inner and 733 Outer SCHC Compression. We then show a dump of the results and 734 contrast SCHC + OSCORE performance with SCHC + COAP performance. 735 This gives an approximation to the cost of security with SCHC-OSCORE. 737 Our first example CoAP message is the GET Request in Figure 10 738 Original message: 739 ================= 740 0x4101000182bb74656d7065726174757265 742 Header: 743 0x4101 744 01 Ver 745 00 CON 746 0001 tkl 747 00000001 Request Code 1 "GET" 749 0x0001 = mid 750 0x82 = token 752 Options: 753 0xbb74656d7065726174757265 754 Option 11: URI_PATH 755 Value = temperature 757 Original msg length: 17 bytes. 759 Figure 10: CoAP GET Request 761 Its corresponding response is the CONTENT Response in Figure 11. 763 Original message: 764 ================= 765 0x6145000182ff32332043 767 Header: 768 0x6145 769 01 Ver 770 10 ACK 771 0001 tkl 772 01000101 Successful Response Code 69 "2.05 Content" 774 0x0001 = mid 775 0x82 = token 777 0xFF Payload marker 778 Payload: 779 0x32332043 781 Original msg length: 10 783 Figure 11: CoAP CONTENT Response 785 The SCHC Rules for the Inner Compression include all fields that are 786 already present in a regular CoAP message, what matters is the order 787 of appearance and inclusion of only those CoAP fields that go into 788 the Plaintext, Figure 12. 790 Rule ID 0 791 +----------------+--+--+-----------+-----------+-----------++--------+ 792 | Field |FP|DI| Target | MO | CDA || Sent | 793 | | | | Value | | || [bits] | 794 +----------------+--+--+-----------+-----------+-----------++--------+ 795 |CoAP Code | |up| 1 | equal |not-sent || | 796 |CoAP Code | |dw|[69,132] | match-map |match-sent || c | 797 |CoAP Uri-Path | |up|temperature| equal |not-sent || | 798 |COAP Option-End | |dw| 0xFF | equal |not-sent || | 799 +----------------+--+--+-----------+-----------+-----------++--------+ 801 Figure 12: Inner SCHC Rules 803 The Outer SCHC Rules (Figure 13) must process the OSCORE Options 804 fields. Here we mask off the repeated bits (most importantly the 805 flag and size bits) with the MSB Mathing Operator. 807 Rule ID 0 808 +---------------+--+--+--------------+---------+-----------++------------+ 809 | Field |FP|DI| Target | MO | CDA || Sent | 810 | | | | Value | | || [bits] | 811 +---------------+--+--+--------------+---------+-----------++------------+ 812 |CoAP version | |bi| 01 |equal |not-sent || | 813 |CoAP Type | |up| 0 |equal |not-sent || | 814 |CoAP Type | |dw| 2 |equal |not-sent || | 815 |CoAP TKL | |bi| 1 |equal |not-sent || | 816 |CoAP Code | |up| 2 |equal |not-sent || | 817 |CoAP Code | |dw| 68 |equal |not-sent || | 818 |CoAP MID | |bi| 0000 |MSB(12) |LSB ||MMMM | 819 |CoAP Token | |bi| 0x80 |MSB(5) |LSB ||TTT | 820 |CoAP OSCORE_piv| |up| 0x0900 |MSB(12) |LSB ||PPPP | 821 |COAP OSCORE_kid| |up|b'\x06client' |MSB(52) |LSB ||KKKK | 822 |CoAP OSCORE_piv| |dw| b'' |equal |not-sent || | 823 |COAP Option-End| |dw| 0xFF |equal |not-sent || | 824 +---------------+--+--+--------------+---------+-----------++------------+ 826 Figure 13: Outer SCHC Rules 828 Next we show a dump of the compressed message: 830 Compressed message: 831 ================== 832 0x00291287f0a5c4833760d170 833 0x00 = Rule ID 835 piv = 0x04 837 Compression residue: 838 0b0001 010 0100 0100 (15 bits -> 2 bytes with padding) 839 mid tkn piv kid 841 Payload 842 0xa1fc297120cdd8345c 844 Compressed message length: 12 bytes 846 Figure 14: SCHC-OSCORE Compressed GET Request 848 Compressed message: 849 ================== 850 0x0015f4de9cb814c96aed9b1d981a3a58 851 0x00 = Rule ID 853 Compression residue: 854 0b0001 010 (7 bits -> 1 byte with padding) 855 mid tkn 857 Payload 858 0xfa6f4e5c0a64b576cd8ecc0d1d2c 860 Compressed msg length: 16 bytes 862 Figure 15: SCHC-OSCORE Compressed CONTENT Response 864 For contrast, we compare these results with what would be obtained by 865 SCHC compressing the original CoAP messages without protecting them 866 with OSCORE. To do this, we compress the CoAP mesages according to 867 the SCHC rules in Figure 16. 869 Rule ID 1 870 +---------------+--+--+-----------+---------+-----------++------------+ 871 | Field |FP|DI| Target | MO | CDA || Sent | 872 | | | | Value | | || [bits] | 873 +---------------+--+--+-----------+---------+-----------++------------+ 874 |CoAP version | |bi| 01 |equal |not-sent || | 875 |CoAP Type | |up| 0 |equal |not-sent || | 876 |CoAP Type | |dw| 2 |equal |not-sent || | 877 |CoAP TKL | |bi| 1 |equal |not-sent || | 878 |CoAP Code | |up| 2 |equal |not-sent || | 879 |CoAP Code | |dw| [69,132] |equal |not-sent || | 880 |CoAP MID | |bi| 0000 |MSB(12) |LSB ||MMMM | 881 |CoAP Token | |bi| 0x80 |MSB(5) |LSB ||TTT | 882 |CoAP Uri-Path | |up|temperature|equal |not-sent || | 883 |COAP Option-End| |dw| 0xFF |equal |not-sent || | 884 +---------------+--+--+-----------+---------+-----------++------------+ 886 Figure 16: SCHC-CoAP Rules (No OSCORE) 888 This yields the results in Figure 17 for the Request, and Figure 18 889 for the Response. 891 Compressed message: 892 ================== 893 0x0114 894 0x01 = Rule ID 896 Compression residue: 897 0b00010100 (1 byte) 899 Compressed msg length: 2 901 Figure 17: CoAP GET Compressed without OSCORE 903 Compressed message: 904 ================== 905 0x010a32332043 906 0x01 = Rule ID 908 Compression residue: 909 0b00001010 (1 byte) 911 Payload 912 0x32332043 914 Compressed msg length: 6 916 Figure 18: CoAP CONTENT Compressed without OSCORE 918 As can be seen, the difference between applying SCHC + OSCORE as 919 compared to regular SCHC + COAP is about 10 bytes of cost. 921 8. Normative References 923 [I-D.ietf-core-object-security] 924 Selander, G., Mattsson, J., Palombini, F., and L. Seitz, 925 "Object Security for Constrained RESTful Environments 926 (OSCORE)", draft-ietf-core-object-security-13 (work in 927 progress), June 2018. 929 [I-D.ietf-lpwan-ipv6-static-context-hc] 930 Minaburo, A., Toutain, L., Gomez, C., and D. Barthel, 931 "LPWAN Static Context Header Compression (SCHC) and 932 fragmentation for IPv6 and UDP", draft-ietf-lpwan-ipv6- 933 static-context-hc-16 (work in progress), June 2018. 935 [I-D.toutain-core-time-scale] 936 Minaburo, A. and L. Toutain, "CoAP Time Scale Option", 937 draft-toutain-core-time-scale-00 (work in progress), 938 October 2017. 940 [rfc7252] Shelby, Z., Hartke, K., and C. Bormann, "The Constrained 941 Application Protocol (CoAP)", RFC 7252, 942 DOI 10.17487/RFC7252, June 2014, 943 . 945 [rfc7641] Hartke, K., "Observing Resources in the Constrained 946 Application Protocol (CoAP)", RFC 7641, 947 DOI 10.17487/RFC7641, September 2015, 948 . 950 [rfc7959] Bormann, C. and Z. Shelby, Ed., "Block-Wise Transfers in 951 the Constrained Application Protocol (CoAP)", RFC 7959, 952 DOI 10.17487/RFC7959, August 2016, 953 . 955 [rfc7967] Bhattacharyya, A., Bandyopadhyay, S., Pal, A., and T. 956 Bose, "Constrained Application Protocol (CoAP) Option for 957 No Server Response", RFC 7967, DOI 10.17487/RFC7967, 958 August 2016, . 960 Authors' Addresses 961 Ana Minaburo 962 Acklio 963 1137A avenue des Champs Blancs 964 35510 Cesson-Sevigne Cedex 965 France 967 Email: ana@ackl.io 969 Laurent Toutain 970 Institut MINES TELECOM; IMT Atlantique 971 2 rue de la Chataigneraie 972 CS 17607 973 35576 Cesson-Sevigne Cedex 974 France 976 Email: Laurent.Toutain@imt-atlantique.fr 978 Ricardo Andreasen 979 Universidad de Buenos Aires 980 Av. Paseo Colon 850 981 C1063ACV Ciudad Autonoma de Buenos Aires 982 Argentina 984 Email: randreasen@fi.uba.ar