idnits 2.17.1 draft-ietf-lpwan-coap-static-context-hc-18.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 : ---------------------------------------------------------------------------- No issues found here. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year == Line 1182 has weird spacing: '...tkn piv kid...' == Line 1199 has weird spacing: '... mid tkn...' -- The document date (January 21, 2021) is 1189 days in the past. Is this intentional? Checking references for intended status: Proposed Standard ---------------------------------------------------------------------------- (See RFCs 3967 and 4897 for information about using normative references to lower-maturity documents in RFCs) -- Looks like a reference, but probably isn't: '69' on line 1223 -- Looks like a reference, but probably isn't: '132' on line 1223 ** Downref: Normative reference to an Informational RFC: RFC 7967 Summary: 1 error (**), 0 flaws (~~), 3 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: Standards Track L. Toutain 5 Expires: July 25, 2021 Institut MINES TELECOM; IMT Atlantique 6 R. Andreasen 7 Universidad de Buenos Aires 8 January 21, 2021 10 LPWAN Static Context Header Compression (SCHC) for CoAP 11 draft-ietf-lpwan-coap-static-context-hc-18 13 Abstract 15 This draft defines how to compress the Constrained Application 16 Protocol (CoAP) using the Static Context Header Compression (SCHC). 17 SCHC is a header compression mechanism adapted for Constrained 18 Devices. SCHC uses a static description of the header to reduce the 19 header's redundancy and size. While RFC 8724 describes the SCHC 20 compression and fragmentation framework, and its application for 21 IPv6/UDP headers, this document applies SCHC for CoAP headers. The 22 CoAP header structure differs from IPv6 and UDP since CoAP uses a 23 flexible header with a variable number of options, themselves of 24 variable length. The CoAP protocol messages format is asymmetric: 25 the request messages have a header format different from the one in 26 the response messages. This specification gives guidance on applying 27 SCHC to flexible headers and how to leverage the asymmetry for more 28 efficient compression Rules. 30 Status of This Memo 32 This Internet-Draft is submitted in full conformance with the 33 provisions of BCP 78 and BCP 79. 35 Internet-Drafts are working documents of the Internet Engineering 36 Task Force (IETF). Note that other groups may also distribute 37 working documents as Internet-Drafts. The list of current Internet- 38 Drafts is at https://datatracker.ietf.org/drafts/current/. 40 Internet-Drafts are draft documents valid for a maximum of six months 41 and may be updated, replaced, or obsoleted by other documents at any 42 time. It is inappropriate to use Internet-Drafts as reference 43 material or to cite them other than as "work in progress." 45 This Internet-Draft will expire on July 25, 2021. 47 Copyright Notice 49 Copyright (c) 2021 IETF Trust and the persons identified as the 50 document authors. All rights reserved. 52 This document is subject to BCP 78 and the IETF Trust's Legal 53 Provisions Relating to IETF Documents 54 (https://trustee.ietf.org/license-info) in effect on the date of 55 publication of this document. Please review these documents 56 carefully, as they describe your rights and restrictions with respect 57 to this document. Code Components extracted from this document must 58 include Simplified BSD License text as described in Section 4.e of 59 the Trust Legal Provisions and are provided without warranty as 60 described in the Simplified BSD License. 62 Table of Contents 64 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3 65 1.1. Terminology . . . . . . . . . . . . . . . . . . . . . . . 4 66 2. SCHC Applicability to CoAP . . . . . . . . . . . . . . . . . 4 67 3. CoAP Headers compressed with SCHC . . . . . . . . . . . . . . 7 68 3.1. Differences between CoAP and UDP/IP Compression . . . . . 8 69 4. Compression of CoAP header fields . . . . . . . . . . . . . . 9 70 4.1. CoAP version field . . . . . . . . . . . . . . . . . . . 9 71 4.2. CoAP type field . . . . . . . . . . . . . . . . . . . . . 9 72 4.3. CoAP code field . . . . . . . . . . . . . . . . . . . . . 9 73 4.4. CoAP Message ID field . . . . . . . . . . . . . . . . . . 10 74 4.5. CoAP Token fields . . . . . . . . . . . . . . . . . . . . 10 75 5. CoAP options . . . . . . . . . . . . . . . . . . . . . . . . 10 76 5.1. CoAP Content and Accept options. . . . . . . . . . . . . 11 77 5.2. CoAP option Max-Age, Uri-Host, and Uri-Port fields . . . 11 78 5.3. CoAP option Uri-Path and Uri-Query fields . . . . . . . . 11 79 5.3.1. Variable-length Uri-Path and Uri-Query . . . . . . . 12 80 5.3.2. Variable number of Path or Query elements . . . . . . 13 81 5.4. CoAP option Size1, Size2, Proxy-URI and Proxy-Scheme 82 fields . . . . . . . . . . . . . . . . . . . . . . . . . 13 83 5.5. CoAP option ETag, If-Match, If-None-Match, Location-Path, 84 and Location-Query fields . . . . . . . . . . . . . . . . 13 85 6. SCHC compression of CoAP extension RFCs . . . . . . . . . . . 13 86 6.1. Block . . . . . . . . . . . . . . . . . . . . . . . . . . 13 87 6.2. Observe . . . . . . . . . . . . . . . . . . . . . . . . . 13 88 6.3. No-Response . . . . . . . . . . . . . . . . . . . . . . . 14 89 6.4. OSCORE . . . . . . . . . . . . . . . . . . . . . . . . . 14 90 7. Examples of CoAP header compression . . . . . . . . . . . . . 15 91 7.1. Mandatory header with CON message . . . . . . . . . . . . 15 92 7.2. OSCORE Compression . . . . . . . . . . . . . . . . . . . 16 93 7.3. Example OSCORE Compression . . . . . . . . . . . . . . . 20 94 8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 31 95 9. Security considerations . . . . . . . . . . . . . . . . . . . 31 96 10. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 32 97 11. Normative References . . . . . . . . . . . . . . . . . . . . 32 98 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 33 100 1. Introduction 102 CoAP [RFC7252] is a command/response protocol designed for micro- 103 controllers with a small RAM and ROM and optimized for REST-based 104 (Representative state transfer) services. Although the Constrained 105 Devices leads the CoAP design, a CoAP header's size is still too 106 large for LPWAN (Low Power Wide Area Networks). SCHC header 107 compression over CoAP header is required to increase performance or 108 use CoAP over LPWAN technologies. 110 The [RFC8724] defines SCHC, a header compression mechanism for the 111 LPWAN network based on a static context. Section 5 of the [RFC8724] 112 explains where compression and decompression occur in the 113 architecture. The SCHC compression scheme assumes as a prerequisite 114 that both end-points know the static context before transmission. 115 The way the context is configured, provisioned, or exchanged is out 116 of this document's scope. 118 CoAP is an application protocol, so CoAP compression requires 119 installing common Rules between the two SCHC instances. SCHC 120 compression may apply at two different levels: at IP and UDP in the 121 LPWAN network and another at the application level for CoAP. These 122 two compressions may be independent. Both follow the same principle 123 described in [RFC8724]. As different entities manage the CoAP 124 compression at different levels, the SCHC Rules driving the 125 compression/decompression are also different. The [RFC8724] 126 describes how to use SCHC for IP and UDP headers. This document 127 specifies how to apply SCHC compression to CoAP headers. 129 SCHC compresses and decompresses headers based on common contexts 130 between Devices. SCHC context includes multiple Rules. Each Rule 131 can match the header fields to specific values or ranges of values. 132 If a Rule matches, the matched header fields are replaced by the 133 RuleID and the Compression Residue that contains the residual bits of 134 the compression. Thus, different Rules may correspond to different 135 protocol headers in the packet that a Device expects to send or 136 receive. 138 A Rule describes the packets' entire header with an ordered list of 139 fields descriptions; see section 7 of [RFC8724]. Thereby 140 each description contains the field ID (FID), its length (FL), and 141 its position (FP), a direction indicator (DI) (upstream, downstream, 142 and bidirectional), and some associated Target Values (TV). The 143 direction indicator is used for compression to give the best TV to 144 the FID when these values differ in the transmission direction. So a 145 field may be described several times. 147 A Matching Operator (MO) is associated with each header field 148 description. The Rule is selected if all the MOs fit the TVs for all 149 fields of the incoming header. A Rule cannot be selected if the 150 message contains an unknown field to the SCHC compressor. 152 In that case, a Compression/Decompression Action (CDA) associated 153 with each field gives the method to compress and decompress each 154 field. Compression mainly results in one of 4 actions: 156 o send the field value (value-sent), 158 o send nothing (not-sent), 160 o send some least significant bits of the field (LSB) or, 162 o send an index (mapping-sent). 164 After applying the compression, there may be some bits to be sent. 165 These values are called Compression Residue. 167 SCHC is a general mechanism applied to different protocols, the exact 168 Rules to be used depending on the protocol and the Application. 169 Section 10 of the [RFC8724] describes the compression scheme for IPv6 170 and UDP headers. This document targets the CoAP header compression 171 using SCHC. 173 1.1. Terminology 175 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 176 "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and 177 "OPTIONAL" in this document are to be interpreted as described in BCP 178 14 [RFC2119][RFC8174] when, and only when, they appear in all 179 capitals, as shown here. 181 2. SCHC Applicability to CoAP 183 SCHC Compression for CoAP header MAY be done in conjunction with the 184 lower layers (IPv6/UDP) or independently. The SCHC adaptation 185 layers, described in Section 5 of [RFC8724], may be used as shown in 186 Figure 1, Figure 2, and Figure 3. 188 In the first example, Figure 1, a Rule compresses the complete header 189 stack from IPv6 to CoAP. In this case, the Device and the NGW 190 perform SCHC C/D (Static Context Header Compression Compressor/ 191 Decompressor). The Application communicating with the Device does 192 not implement SCHC C/D. 194 (Device) (NGW) (App) 196 +--------+ +--------+ 197 | CoAP | | CoAP | 198 +--------+ +--------+ 199 | UDP | | UDP | 200 +--------+ +----------------+ +--------+ 201 | IPv6 | | IPv6 | | IPv6 | 202 +--------+ +--------+-------+ +--------+ 203 | SCHC | | SCHC | | | | 204 +--------+ +--------+ + + + 205 | LPWAN | | LPWAN | | | | 206 +--------+ +--------+-------+ +--------+ 207 ((((LPWAN)))) ------ Internet ------ 209 Figure 1: Compression/Decompression at the LPWAN boundary. 211 Figure 1 shows the use of SCHC header compression above layer 2 in 212 the Device and the NGW. The SCHC layer receives non-encrypted 213 packets and can apply compression Rules to all the headers in the 214 stack. On the other end, the NGW receives the SCHC packet and 215 reconstructs the headers using the Rule and the Compression Residue. 216 After the decompression, the NGW forwards the IPv6 packet toward the 217 destination. The same process applies in the other direction when a 218 non-encrypted packet arrives at the NGW. Thanks to the IP forwarding 219 based on the IPv6 prefix, the NGW identifies the Device and 220 compresses headers using the Device's Rules. 222 In the second example, Figure 2, the SCHC compression is applied in 223 the CoAP layer, compressing the CoAP header independently of the 224 other layers. The RuleID, the Compression Residue, and CoAP payload 225 are encrypted using a mechanism such as DTLS. Only the other end 226 (App) can decipher the information. If needed, layers below use SCHC 227 to compress the header as defined in [RFC8724] (represented in dotted 228 lines). 230 This use case needs an end-to-end context initialization between the 231 Device and the Application. The context initialization is out of the 232 scope of this document. 234 (Device) (NGW) (App) 236 +--------+ +--------+ 237 | CoAP | | CoAP | 238 +--------+ +--------+ 239 | SCHC | | SCHC | 240 +--------+ +--------+ 241 | DTLS | | DTLS | 242 +--------+ +--------+ 243 . udp . . udp . 244 .......... .................. .......... 245 . ipv6 . . ipv6 . . ipv6 . 246 .......... .................. .......... 247 . schc . . schc . . . . 248 .......... .......... . . . 249 . lpwan . . lpwan . . . . 250 .......... .................. .......... 251 ((((LPWAN)))) ------ Internet ------ 253 Figure 2: Standalone CoAP end-to-end Compression/Decompression 255 The third example, Figure 3, shows the use of Object Security for 256 Constrained RESTful Environments (OSCORE) [RFC8613]. In this case, 257 SCHC needs two Rules to compress the CoAP header. A first Rule 258 focused on the inner header. The result of this first compression is 259 encrypted using the OSCORE mechanism. Then a second Rule compresses 260 the outer header, including the OSCORE Options. 262 (Device) (NGW) (App) 264 +--------+ +--------+ 265 | CoAP | | CoAP | 266 | inner | | inner | 267 +--------+ +--------+ 268 | SCHC | | SCHC | 269 | inner | | inner | 270 +--------+ +--------+ 271 | CoAP | | CoAP | 272 | outer | | outer | 273 +--------+ +--------+ 274 | SCHC | | SCHC | 275 | outer | | outer | 276 +--------+ +--------+ 277 . udp . . udp . 278 .......... .................. .......... 279 . ipv6 . . ipv6 . . ipv6 . 280 .......... .................. .......... 281 . schc . . schc . . . . 282 .......... .......... . . . 283 . lpwan . . lpwan . . . . 284 .......... .................. .......... 285 ((((LPWAN)))) ------ Internet ------ 287 Figure 3: OSCORE compression/decompression. 289 In the case of several SCHC instances, as shown in Figure 2 and 290 Figure 3, the Rules may come from different provisioning domains. 292 This document focuses on CoAP compression represented in the dashed 293 boxes in the previous figures. 295 3. CoAP Headers compressed with SCHC 297 The use of SCHC over the CoAP header uses the same description, and 298 compression/decompression techniques like the one for IP and UDP 299 explained in the [RFC8724]. For CoAP, the SCHC Rules description 300 uses the direction information to optimize the compression by 301 reducing the number of Rules needed to compress headers. The field 302 description MAY define both request/response headers and target 303 values in the same Rule, using the DI (direction indicator) to make 304 the difference. 306 As for other header compression protocols, when the compressor does 307 not find a correct Rule to compress the header, the packet MUST be 308 sent uncompressed using the RuleID dedicated to this purpose. Where 309 the Compression Residue is the complete header of the packet. See 310 section 6 of [RFC8724]. 312 3.1. Differences between CoAP and UDP/IP Compression 314 CoAP compression differs from IPv6 and UDP compression in the 315 following aspects: 317 o The CoAP protocol is asymmetric; the headers are different for a 318 request or a response. For example, the URI-Path option is 319 mandatory in the request, and it might not be present in the 320 response. A request might contain an Accept option, and the 321 response might include a Content-Format option. In comparison, 322 IPv6 and UDP returning path swap the value of some fields in the 323 header. However, all the directions have the same fields (e.g., 324 source and destination address fields). 326 The [RFC8724] defines the use of a direction indicator (DI) in the 327 Field Descriptor, which allows a single Rule to process a message 328 header differently depending on the direction. 330 o Even when a field is "symmetric" (i.e., found in both directions), 331 the values carried in each direction are different. The 332 compression may use a "match-mapping" MO to limit the range of 333 expected values in a particular direction and reduce the 334 Compression Residue's size. Through the direction indicator (DI), 335 a field description in the Rules splits the possible field value 336 into two parts, one for each direction. For instance, if a client 337 sends only CON requests, the Type can be elided by compression, 338 and the answer may use one single bit to carry either the ACK or 339 RST type. The field Code has the same behavior, the 0.0X code 340 format value in the request, and the Y.ZZ code format in the 341 response. 343 o In SCHC, the Rule defines the different header fields' length, so 344 SCHC does not need to send it. In IPv6 and UDP headers, the 345 fields have a fixed size, known by definition. On the other hand, 346 some CoAP header fields have variable lengths, and the Rule 347 description specifies it. For example, in a URI-path or URI- 348 query, the Token size may vary from 0 to 8 bytes, and the CoAP 349 options use the Type-Length-Value encoding format. 351 When doing SCHC compression of a variable-length field, 352 Section 7.5.2 from [RFC8724] offers the possibility to define a 353 function for the Field length in the Field Description to know the 354 length before compression. If the field length is unknown, the 355 Rule will set it as a variable, and SCHC will send the compressed 356 field's length in the Compression Residue. 358 o A field can appear several times in the CoAP headers. It is found 359 typically for elements of a URI (path or queries). The SCHC 360 specification [RFC8724] allows a Field ID to appear several times 361 in the Rule and uses the Field Position (FP) to identify the 362 correct instance, thereby removing the matching operation's 363 ambiguity. 365 o Field lengths defined in the CoAP protocol can be too 366 large regarding LPWAN traffic constraints. For instance, this is 367 particularly true for the Message-ID field and the Token field. 368 SCHC uses different Matching operators (MO) to perform the 369 compression. See section 7.4 of [RFC8724]. In this case, SCHC 370 can apply the Most Significant Bits (MSB) MO to reduce the 371 information carried on LPWANs. 373 4. Compression of CoAP header fields 375 This section discusses the compression of the different CoAP header 376 fields. The CoAP compression with SCHC follows Section 7.1 of 377 [RFC8724]. 379 4.1. CoAP version field 381 CoAP version is bidirectional and MUST be elided during the SCHC 382 compression since it always contains the same value. In the future, 383 or if a new version of CoAP is defined, new Rules will be needed to 384 avoid ambiguities between versions. 386 4.2. CoAP type field 388 The CoAP protocol [RFC7252] has four types of messages: two requests 389 (CON, NON), one response (ACK), and one empty message (RST). 391 The SCHC compression SHOULD elide this field if, for instance, a 392 client is sending only NON or only CON messages. For the RST 393 message, SCHC may use a dedicated Rule. For other usages, SCHC can 394 use a "match-mapping" MO. 396 4.3. CoAP code field 398 The code field is an IANA registry [RFC7252], and it indicates the 399 Request Method used in CoAP. The compression of the CoAP code field 400 follows the same principle as that of the CoAP type field. If the 401 Device plays a specific role, SCHC may split the code values into two 402 fields description, the request codes with the 0 class and the 403 response values. SCHC will use the direction indicator to identify 404 the correct value in the packet. 406 If the Device only implements a CoAP client, SCHC compression may 407 reduce the request code to the set of requests the client can 408 process. 410 For known values, SCHC can use a "match-mapping" MO. If SCHC cannot 411 compress the code field, it will send the values in the Compression 412 Residue. 414 4.4. CoAP Message ID field 416 SCHC can compress the Message ID field with the "MSB" MO and the 417 "LSB" CDA. See section 7.4 of [RFC8724]. 419 4.5. CoAP Token fields 421 CoAP defines the Token using two CoAP fields, Token Length in the 422 mandatory header and Token Value directly following the mandatory 423 CoAP header. 425 SCHC processes the Token length as any header field. If the value 426 does not change, the size can be stored in the TV and elided during 427 the transmission. Otherwise, SCHC will send the token length in the 428 Compression Residue. 430 For the Token Value, SCHC MUST NOT send it as a variable-length in 431 the Compression Residue to avoid ambiguity with Token Length. 432 Therefore, SCHC MUST use the Token length value to define the size of 433 the Compression Residue. SCHC designates a specific function "tkl" 434 that the Rule MUST use to complete the field description. During the 435 decompression, this function returns the value contained in the Token 436 Length field. 438 5. CoAP options 440 CoAP defines options placed after the based header in Option Numbers 441 order; see [RFC7252]. Each Option instance in a message uses the 442 format Delta-Type (D-T), Length (L), Value (V). The SCHC Rule builds 443 the description of the option by using in the Field ID the Option 444 Number built from D-T; in TV, the Option Value; and the Option Length 445 uses section 7.4 of [RFC8724]. When the Option Length has a well- 446 known size, the Rule may stock the length value. Therefore, SCHC 447 compression does not send it. Otherwise, SCHC Compression carries 448 the length of the Compression Residue, in addition to the Compression 449 Residue value. 451 CoAP requests and responses do not include the same options. So 452 Compression Rules may reflect this asymmetry by tagging the direction 453 indicator. 455 Note that length coding differs between CoAP options and SCHC 456 variable size Compression Residue. 458 The following sections present how SCHC compresses some specific CoAP 459 options. 461 If CoAP introduces a new option, the SCHC Rules MAY be updated, and 462 the new Field ID description MUST be assigned to allow its 463 compression. Otherwise, if no Rule describes this new option, the 464 SCHC compression is not achieved, and SCHC sends the CoAP header 465 without compression. 467 5.1. CoAP Content and Accept options. 469 If the client expects a single value, it can be stored in the TV and 470 elided during the transmission. Otherwise, if the client expects 471 several possible values, a "match-mapping" SHOULD be used to limit 472 the Compression Residue's size. If not, SCHC has to send the option 473 value in the Compression Residue (fixed or variable length). 475 5.2. CoAP option Max-Age, Uri-Host, and Uri-Port fields 477 SCHC compresses these three fields in the same way. When the value 478 of these options is known, SCHC can elide these fields. If the 479 option uses well-known values, SCHC can use a "match-mapping" MO. 480 Otherwise, SCHC will use "value-sent" MO, and the Compression Residue 481 will send these options' values. 483 5.3. CoAP option Uri-Path and Uri-Query fields 485 The Uri-Path and Uri-Query fields are repeatable options; this means 486 that in the CoAP header, they may appear several times with different 487 values. SCHC Rule description uses the Field Position (FP) to 488 distinguish the different instances in the path. 490 To compress repeatable field values, SCHC may use a "match-mapping" 491 MO to reduce the size of variable Paths or Queries. In these cases, 492 to optimize the compression, several elements can be regrouped into a 493 single entry. The Numbering of elements does not change, and the 494 first matching element sets the MO comparison. 496 +--------+---+--+--+--------+-------------+------------+ 497 | Field |FL |FP|DI| Target | Matching | CDA | 498 | | | | | Value | Operator | | 499 +--------+---+--+--+--------+-------------+------------+ 500 |Uri-Path| | 1|up|["/a/b",|match-mapping|mapping-sent| 501 | | | | |"/c/d"] | | | 502 |Uri-Path|var| 3|up| |ignore |value-sent | 503 +--------+---+--+--+--------+-------------+------------+ 505 Figure 4: complex path example 507 In Figure 4, SCHC can use a single bit in the Compression Residue to 508 code one of the two paths. If regrouping were not allowed, 2 bits in 509 the Compression Residue would be needed. SCHC sends the third path 510 element as a variable size in the Compression Residue. 512 5.3.1. Variable-length Uri-Path and Uri-Query 514 When SCHC creates the Rule, the length of URI-Path and URI-Query may 515 be known. Nevertheless, SCHC MUST set the field length to variable, 516 and the unit to bytes. 518 SCHC compression can use the MSB MO to a Uri-Path or Uri-Query 519 element. However, attention to the length is important because the 520 MSB value is in bits, and the size MUST always be a multiple of 8 521 bits. 523 The length sent at the beginning of a variable-length Compression 524 Residue indicates the LSB's size in bytes. 526 For instance, for a CORECONF path /c/X6?k="eth0" the Rule description 527 can be: 529 +-------------+---+--+--+--------+---------+-------------+ 530 | Field |FL |FP|DI| Target | Match | CDA | 531 | | | | | Value | Opera. | | 532 +-------------+---+--+--+--------+---------+-------------+ 533 |Uri-Path | 8| 1|up|"c" |equal |not-sent | 534 |Uri-Path |var| 2|up| |ignore |value-sent | 535 |Uri-Query |var| 1|up|"k=" |MSB(16) |LSB | 536 +-------------+---+--+--+--------+---------+-------------+ 538 Figure 5: CORECONF URI compression 540 Figure 5 shows the Rule description for a URI-Path and a URI-Query. 541 SCHC compresses the first part of the URI-Path with a "not-sent" CDA. 543 SCHC will send the second element of the URI-Path with the length 544 (i.e., 0x2 X 6) followed by the query option (i.e., 0x05 "eth0"). 546 5.3.2. Variable number of Path or Query elements 548 SCHC fixed the number of Uri-Path or Uri-Query elements in a Rule at 549 the Rule creation time. If the number varies, SCHC SHOULD create 550 several Rules to cover all the possibilities. Another one is to 551 define the length of Uri-Path to variable and sends a Compression 552 Residue with a length of 0 to indicate that this Uri-Path is empty. 553 However, this adds 4 bits to the variable Compression Residue size. 554 See section 7.5.2 [RFC8724]. 556 5.4. CoAP option Size1, Size2, Proxy-URI and Proxy-Scheme fields 558 The SCHC Rule description MAY define sending some field values by 559 setting the TV to "not-sent," MO to "ignore," and CDA to "value- 560 sent." A Rule MAY also use a "match-mapping" when there are 561 different options for the same FID. Otherwise, the Rule sets the TV 562 to the value, MO to "equal," and CDA to "not-sent." 564 5.5. CoAP option ETag, If-Match, If-None-Match, Location-Path, and 565 Location-Query fields 567 A Rule entry cannot store these fields' values. The Rule description 568 MUST always send these values in the Compression Residue. 570 6. SCHC compression of CoAP extension RFCs 572 6.1. Block 574 When a packet uses a Block [RFC7959] option, SCHC compression MUST 575 send its content in the Compression Residue. The SCHC Rule describes 576 an empty TV with a MO set to "ignore" and a CDA to "value-sent." 577 Block option allows fragmentation at the CoAP level that is 578 compatible with SCHC fragmentation. Both fragmentation mechanisms 579 are complementary, and the node may use them for the same packet as 580 needed. 582 6.2. Observe 584 The [RFC7641] defines the Observe option. The SCHC Rule description 585 will not define the TV, but MO to "ignore," and the CDA to "value- 586 sent." SCHC does not limit the maximum size for this option (3 587 bytes). To reduce the transmission size, either the Device 588 implementation MAY limit the delta between two consecutive values, or 589 a proxy can modify the increment. 591 Since the Observe option MAY use an RST message to inform a server 592 that the client does not require the Observe response, a specific 593 SCHC Rule SHOULD exist to allow the message's compression with the 594 RST type. 596 6.3. No-Response 598 The [RFC7967] defines a No-Response. Different behaviors exist while 599 using this option to limit the responses made by a server to a 600 request. If both ends know the value, then the SCHC Rule will 601 describe a TV to this value, with a MO set to "equal" and CDA set to 602 "not-sent." 604 Otherwise, if the value is changing over time, the SCHC Rule will set 605 the MO to "ignore" and CDA to "value-sent." The Rule may also use a 606 "match-mapping" to compress this option. 608 6.4. OSCORE 610 OSCORE [RFC8613] defines end-to-end protection for CoAP messages. 611 This section describes how SCHC Rules can be applied to compress 612 OSCORE-protected messages. 614 0 1 2 3 4 5 6 7 <--------- n bytes -------------> 615 +-+-+-+-+-+-+-+-+--------------------------------- 616 |0 0 0|h|k| n | Partial IV (if any) ... 617 +-+-+-+-+-+-+-+-+--------------------------------- 618 | | | 619 |<-- CoAP -->|<------ CoAP OSCORE_piv ------> | 620 OSCORE_flags 622 <- 1 byte -> <------ s bytes -----> 623 +------------+----------------------+-----------------------+ 624 | s (if any) | kid context (if any) | kid (if any) ... | 625 +------------+----------------------+-----------------------+ 626 | | | 627 | <------ CoAP OSCORE_kidctx ------>|<-- CoAP OSCORE_kid -->| 629 Figure 6: OSCORE Option 631 The Figure 6 shows the OSCORE Option Value encoding defined in 632 Section 6.1 of [RFC8613], where the first byte specifies the Content 633 of the OSCORE options using flags. The three most significant bits 634 of this byte are reserved and always set to 0. Bit h, when set, 635 indicates the presence of the kid context field in the option. Bit 636 k, when set, indicates the presence of a kid field. The three least 637 significant bits n indicate the length of the piv (Partial 638 Initialization Vector) field in bytes. When n = 0, no piv is 639 present. 641 The flag byte is followed by the piv field, kid context field, and 642 kid field in this order, and if present, the kid context field's 643 length is encoded in the first byte denoting by 's' the length of the 644 kid context in bytes. 646 To better perform OSCORE SCHC compression, the Rule description needs 647 to identify the OSCORE Option and the fields it contains. 648 Conceptually, it discerns up to 4 distinct pieces of information 649 within the OSCORE option: the flag bits, the piv, the kid context, 650 and the kid. The SCHC Rule splits into four field descriptions the 651 OSCORE option to compress them: 653 o CoAP OSCORE_flags, 655 o CoAP OSCORE_piv, 657 o CoAP OSCORE_kidctx, 659 o CoAP OSCORE_kid. 661 Figure 6 shows the OSCORE Option format with those four fields 662 superimposed on it. Note that the CoAP OSCORE_kidctx field directly 663 includes the size octet s. 665 7. Examples of CoAP header compression 667 7.1. Mandatory header with CON message 669 In this first scenario, the SCHC Compressor at the Network Gateway 670 side receives a POST message from an Internet client, which is 671 immediately acknowledged by the Device. Figure 7 describes the SCHC 672 Rule descriptions for this scenario. 674 RuleID 1 675 +-------------+--+--+--+------+---------+-------------++------------+ 676 | Field |FL|FP|DI|Target| Match | CDA || Sent | 677 | | | | |Value | Opera. | || [bits] | 678 +-------------+--+--+--+------+---------+-------------++------------+ 679 |CoAP version | 2| 1|bi| 01 |equal |not-sent || | 680 |CoAP Type | 2| 1|dw| CON |equal |not-sent || | 681 |CoAP Type | 2| 1|up|[ACK, | | || | 682 | | | | | RST] |match-map|matching-sent|| T | 683 |CoAP TKL | 4| 1|bi| 0 |equal |not-sent || | 684 |CoAP Code | 8| 1|bi|[0.00,| | || | 685 | | | | | ... | | || | 686 | | | | | 5.05]|match-map|matching-sent|| CC CCC | 687 |CoAP MID |16| 1|bi| 0000 |MSB(7 ) |LSB || M-ID| 688 |CoAP Uri-Path|var 1|dw| path |equal 1 |not-sent || | 689 +-------------+--+--+--+------+---------+-------------++------------+ 691 Figure 7: CoAP Context to compress header without Token 693 In this example, SCHC compression elides the version and the Token 694 Length fields. The 26 method and response codes defined in [RFC7252] 695 has been shrunk to 5 bits using a "match-mapping" MO. The Uri-Path 696 contains a single element indicated in the TV and elided with the CDA 697 "not-sent." 699 SCHC Compression reduces the header sending only the Type, a mapped 700 code, and the least significant bits of Message ID (9 bits in the 701 example above). 703 Note that a client located in an Application Server sending a request 704 to a server located in the Device may not be compressed through this 705 Rule since the MID will not start with 7 bits equal to 0. A CoAP 706 proxy placed before the SCHC C/D can rewrite the message ID to fit 707 the value and match the Rule. 709 7.2. OSCORE Compression 711 OSCORE aims to solve the problem of end-to-end encryption for CoAP 712 messages. Therefore, the goal is to hide as much as possible the 713 message while still enabling proxy operation. 715 Conceptually this is achieved by splitting the CoAP message into an 716 Inner Plaintext and Outer OSCORE Message. The Inner Plaintext 717 contains sensitive information that is not necessary for proxy 718 operation. However, it is part of the message that can be encrypted 719 until it reaches its end destination. The Outer Message acts as a 720 shell matching the regular CoAP message format and includes all 721 Options and information needed for proxy operation and caching. 722 Figure 8 illustrates this analysis. 724 The CoAP protocol arranges the options into one of 3 classes; each 725 granted a specific type of protection by the protocol: 727 o Class E: Encrypted options moved to the Inner Plaintext, 729 o Class I: Integrity-protected options included in the AAD for the 730 encryption of the Plaintext but otherwise left untouched in the 731 Outer Message, 733 o Class U: Unprotected options left untouched in the Outer Message. 735 These classes point out that the Outer option contains the OSCORE 736 Option and that the message is OSCORE protected; this option carries 737 the information necessary to retrieve the Security Context. The end- 738 point will use this Security Context to decrypt the message 739 correctly. 741 Original CoAP Packet 742 +-+-+---+-------+---------------+ 743 |v|t|TKL| code | Msg Id. | 744 +-+-+---+-------+---------------+....+ 745 | Token | 746 +-------------------------------.....+ 747 | Options (IEU) | 748 . . 749 . . 750 +------+-------------------+ 751 | 0xFF | 752 +------+------------------------+ 753 | | 754 | Payload | 755 | | 756 +-------------------------------+ 757 / \ 758 / \ 759 / \ 760 / \ 761 Outer Header v v Plaintext 762 +-+-+---+--------+---------------+ +-------+ 763 |v|t|TKL|new code| Msg Id. | | code | 764 +-+-+---+--------+---------------+....+ +-------+-----......+ 765 | Token | | Options (E) | 766 +--------------------------------.....+ +-------+------.....+ 767 | Options (IU) | | OxFF | 768 . . +-------+-----------+ 769 . OSCORE Option . | | 770 +------+-------------------+ | Payload | 771 | 0xFF | | | 772 +------+ +-------------------+ 774 Figure 8: A CoAP packet is split into an OSCORE outer and plaintext 776 Figure 8 shows the packet format for the OSCORE Outer header and 777 Plaintext. 779 In the Outer Header, the original header code is hidden and replaced 780 by a default dummy value. As seen in Sections 4.1.3.5 and 4.2 of 781 [RFC8613], the message code is replaced by POST for requests and 782 Changed for responses when CoAP is not using the Observe option. If 783 CoAP uses Observe, the OSCORE message code is replaced by FETCH for 784 requests and Content for responses. 786 The first byte of the Plaintext contains the original packet code, 787 followed by the message code, the class E options, and, if present, 788 the original message Payload preceded by its payload marker. 790 An AEAD algorithm now encrypts the Plaintext. This integrity 791 protects the Security Context parameters and, eventually, any class I 792 options from the Outer Header. The resulting Ciphertext becomes the 793 new payload of the OSCORE message, as illustrated in Figure 9. 795 As defined in [RFC5116], this Ciphertext is the encrypted Plaintext's 796 concatenation of the authentication tag. Note that Inner Compression 797 only affects the Plaintext before encryption. Thus only the first 798 variable-length of the Ciphertext can be reduced. The authentication 799 tag is fixed in length and is considered part of the cost of 800 protection. 802 Outer Header 803 +-+-+---+--------+---------------+ 804 |v|t|TKL|new code| Msg Id. | 805 +-+-+---+--------+---------------+....+ 806 | Token | 807 +--------------------------------.....+ 808 | Options (IU) | 809 . . 810 . OSCORE Option . 811 +------+-------------------+ 812 | 0xFF | 813 +------+---------------------------+ 814 | | 815 | Ciphertext: Encrypted Inner | 816 | Header and Payload | 817 | + Authentication Tag | 818 | | 819 +----------------------------------+ 821 Figure 9: OSCORE message 823 The SCHC Compression scheme consists of compressing both the 824 Plaintext before encryption and the resulting OSCORE message after 825 encryption, see Figure 10. 827 The OSCORE message translates into a segmented process where SCHC 828 compression is applied independently in 2 stages, each with its 829 corresponding set of Rules, with the Inner SCHC Rules and the Outer 830 SCHC Rules. This way, compression is applied to all fields of the 831 original CoAP message. 833 Note that since the corresponding end-point can only decrypt the 834 Inner part of the message, this end-point will also have to implement 835 Inner SCHC Compression/Decompression. 837 Outer Message OSCORE Plaintext 838 +-+-+---+--------+---------------+ +-------+ 839 |v|t|TKL|new code| Msg Id. | | code | 840 +-+-+---+--------+---------------+....+ +-------+-----......+ 841 | Token | | Options (E) | 842 +--------------------------------.....+ +-------+------.....+ 843 | Options (IU) | | OxFF | 844 . . +-------+-----------+ 845 . OSCORE Option . | | 846 +------+-------------------+ | Payload | 847 | 0xFF | | | 848 +------+------------+ +-------------------+ 849 | Ciphertext |<---------\ | 850 | | | v 851 +-------------------+ | +-----------------+ 852 | | | Inner SCHC | 853 v | | Compression | 854 +-----------------+ | +-----------------+ 855 | Outer SCHC | | | 856 | Compression | | v 857 +-----------------+ | +-------+ 858 | | |RuleID | 859 v | +-------+-----------+ 860 +--------+ +------------+ |Compression Residue| 861 |RuleID' | | Encryption | <-- +----------+--------+ 862 +--------+-----------+ +------------+ | | 863 |Compression Residue'| | Payload | 864 +-----------+--------+ | | 865 | Ciphertext | +-------------------+ 866 | | 867 +--------------------+ 869 Figure 10: OSCORE Compression Diagram 871 7.3. Example OSCORE Compression 873 This section gives an example with a GET Request and its consequent 874 Content Response from a Device-based CoAP client to a cloud-based 875 CoAP server. The example also describes a possible set of Rules for 876 the Inner and Outer SCHC Compression. A dump of the results and a 877 contrast between SCHC + OSCORE performance with SCHC + COAP 878 performance is also listed. This example gives an approximation of 879 the cost of security with SCHC-OSCORE. 881 Our first CoAP message is the GET request in Figure 11. 883 Original message: 884 ================= 885 0x4101000182bb74656d7065726174757265 887 Header: 888 0x4101 889 01 Ver 890 00 CON 891 0001 TKL 892 00000001 Request Code 1 "GET" 894 0x0001 = mid 895 0x82 = token 897 Options: 898 0xbb74656d7065726174757265 899 Option 11: URI_PATH 900 Value = temperature 902 Original msg length: 17 bytes. 904 Figure 11: CoAP GET Request 906 Its corresponding response is the CONTENT Response in Figure 12. 908 Original message: 909 ================= 910 0x6145000182ff32332043 912 Header: 913 0x6145 914 01 Ver 915 10 ACK 916 0001 TKL 917 01000101 Successful Response Code 69 "2.05 Content" 919 0x0001 = mid 920 0x82 = token 922 0xFF Payload marker 923 Payload: 924 0x32332043 926 Original msg length: 10 928 Figure 12: CoAP CONTENT Response 930 The SCHC Rules for the Inner Compression include all fields already 931 present in a regular CoAP message. The methods described in 932 Section 4 apply to these fields. As an example, see Figure 13. 934 RuleID 0 935 +--------------+--+--+--+-----------+---------+---------++------+ 936 | Field |FL|FP|DI| Target | MO | CDA || Sent | 937 | | | | | Value | | ||[bits]| 938 +--------------+--+--+--+-----------+---------+---------++------+ 939 |CoAP Code | 8| 1|up| 1 | equal |not-sent || | 940 |CoAP Code | 8| 1|dw|[69, | | || | 941 | | | | |132] |match-map|mapp-sent|| c | 942 |CoAP Uri-Path |88| 1|up|temperature| equal |not-sent || | 943 +--------------+--+--+--+-----------+---------+---------++------+ 945 Figure 13: Inner SCHC Rules 947 Figure 14 shows the Plaintext obtained for the example GET request. 948 The packet follows the process of Inner Compression and Encryption 949 until the payload. The outer OSCORE Message adds the result of the 950 Inner process. 952 In this case, the original message has no payload, and its resulting 953 Plaintext compressed up to only 1 byte (size of the RuleID). The 954 AEAD algorithm preserves this length in its first output and yields a 955 fixed-size tag. SCHC cannot compress the tag, and the OSCORE message 956 must include it without compression. The use of integrity translates 957 into an overhead in total message length, limiting the amount of 958 compression that can be achieved and plays into the cost of adding 959 security to the exchange. 961 ________________________________________________________ 962 | | 963 | OSCORE Plaintext | 964 | | 965 | 0x01bb74656d7065726174757265 (13 bytes) | 966 | | 967 | 0x01 Request Code GET | 968 | | 969 | bb74656d7065726174757265 Option 11: URI_PATH | 970 | Value = temperature | 971 |________________________________________________________| 973 | 974 | 975 | Inner SCHC Compression 976 | 977 v 978 _________________________________ 979 | | 980 | Compressed Plaintext | 981 | | 982 | 0x00 | 983 | | 984 | RuleID = 0x00 (1 byte) | 985 | (No Compression Residue) | 986 |_________________________________| 988 | 989 | AEAD Encryption 990 | (piv = 0x04) 991 v 992 _________________________________________________ 993 | | 994 | encrypted_plaintext = 0xa2 (1 byte) | 995 | tag = 0xc54fe1b434297b62 (8 bytes) | 996 | | 997 | ciphertext = 0xa2c54fe1b434297b62 (9 bytes) | 998 |_________________________________________________| 1000 Figure 14: Plaintext compression and encryption for GET Request 1002 Figure 15 shows the process for the example CONTENT Response. The 1003 Compression Residue is 1 bit long. Note that since SCHC adds padding 1004 after the payload, this misalignment causes the hexadecimal code from 1005 the payload to differ from the original, even if SCHC cannot compress 1006 the tag. The overhead for the tag bytes limits the SCHC's 1007 performance but brings security to the transmission. 1009 ________________________________________________________ 1010 | | 1011 | OSCORE Plaintext | 1012 | | 1013 | 0x45ff32332043 (6 bytes) | 1014 | | 1015 | 0x45 Successful Response Code 69 "2.05 Content" | 1016 | | 1017 | ff Payload marker | 1018 | | 1019 | 32332043 Payload | 1020 |________________________________________________________| 1022 | 1023 | 1024 | Inner SCHC Compression 1025 | 1026 v 1027 _____________________________________________ 1028 | | 1029 | Compressed Plaintext | 1030 | | 1031 | 0x001919902180 (6 bytes) | 1032 | | 1033 | 00 RuleID | 1034 | | 1035 | 0b0 (1 bit match-map Compression Residue) | 1036 | 0x32332043 >> 1 (shifted payload) | 1037 | 0b0000000 Padding | 1038 |_____________________________________________| 1040 | 1041 | AEAD Encryption 1042 | (piv = 0x04) 1043 v 1044 _________________________________________________________ 1045 | | 1046 | encrypted_plaintext = 0x10c6d7c26cc1 (6 bytes) | 1047 | tag = 0xe9aef3f2461e0c29 (8 bytes) | 1048 | | 1049 | ciphertext = 0x10c6d7c26cc1e9aef3f2461e0c29 (14 bytes) | 1050 |_________________________________________________________| 1052 Figure 15: Plaintext compression and encryption for CONTENT Response 1054 The Outer SCHC Rules (Figure 18) must process the OSCORE Options 1055 fields. Figure 16 and Figure 17 shows a dump of the OSCORE Messages 1056 generated from the example messages. They include the Inner 1057 Compressed Ciphertext in the payload. These are the messages that 1058 have to be compressed by the Outer SCHC Compression. 1060 Protected message: 1061 ================== 1062 0x4102000182d8080904636c69656e74ffa2c54fe1b434297b62 1063 (25 bytes) 1065 Header: 1066 0x4102 1067 01 Ver 1068 00 CON 1069 0001 TKL 1070 00000010 Request Code 2 "POST" 1072 0x0001 = mid 1073 0x82 = token 1075 Options: 1076 0xd8080904636c69656e74 (10 bytes) 1077 Option 21: OBJECT_SECURITY 1078 Value = 0x0904636c69656e74 1079 09 = 000 0 1 001 Flag byte 1080 h k n 1081 04 piv 1082 636c69656e74 kid 1084 0xFF Payload marker 1085 Payload: 1086 0xa2c54fe1b434297b62 (9 bytes) 1088 Figure 16: Protected and Inner SCHC Compressed GET Request 1090 Protected message: 1091 ================== 1092 0x6144000182d008ff10c6d7c26cc1e9aef3f2461e0c29 1093 (22 bytes) 1095 Header: 1096 0x6144 1097 01 Ver 1098 10 ACK 1099 0001 TKL 1100 01000100 Successful Response Code 68 "2.04 Changed" 1102 0x0001 = mid 1103 0x82 = token 1105 Options: 1106 0xd008 (2 bytes) 1107 Option 21: OBJECT_SECURITY 1108 Value = b'' 1110 0xFF Payload marker 1111 Payload: 1112 0x10c6d7c26cc1e9aef3f2461e0c29 (14 bytes) 1114 Figure 17: Protected and Inner SCHC Compressed CONTENT Response 1116 For the flag bits, some SCHC compression methods are useful, 1117 depending on the Application. The most straightforward alternative 1118 is to provide a fixed value for the flags, combining MO "equal" and 1119 CDA "not-sent." This SCHC definition saves most bits but could 1120 prevent flexibility. Otherwise, SCHC could use a "match-mapping" MO 1121 to choose from several configurations for the exchange. If not, the 1122 SCHC description may use an "MSB" MO to mask off the three hard-coded 1123 most significant bits. 1125 Note that fixing a flag bit will limit CoAP Options choice that can 1126 be used in the exchange since their values are dependent on specific 1127 options. 1129 The piv field lends itself to having some bits masked off with "MSB" 1130 MO and "LSB" CDA. This SCHC description could be useful in 1131 applications where the message frequency is low such as LPWAN 1132 technologies. Note that compressing the sequence numbers may reduce 1133 the maximum number of sequence numbers used in an exchange. Once the 1134 sequence number exceeds the maximum value, the OSCORE keys need to be 1135 re-established. 1137 The size s included in the kid context field MAY be masked off with 1138 "LSB" CDA. The rest of the field could have additional bits masked 1139 off or have the whole field fixed with MO "equal" and CDA "not-sent." 1140 The same holds for the kid field. 1142 Figure 18 shows a possible set of Outer Rules to compress the Outer 1143 Header. 1145 RuleID 0 1146 +------------------+--+--+--+--------------+-------+--------++------+ 1147 | Field |FL|FP|DI| Target | MO | CDA || Sent | 1148 | | | | | Value | | ||[bits]| 1149 +------------------+--+--+--+--------------+-------+--------++------+ 1150 |CoAP version | 2| 1|bi| 01 |equal |not-sent|| | 1151 |CoAP Type | 2| 1|up| 0 |equal |not-sent|| | 1152 |CoAP Type | 2| 1|dw| 2 |equal |not-sent|| | 1153 |CoAP TKL | 4| 1|bi| 1 |equal |not-sent|| | 1154 |CoAP Code | 8| 1|up| 2 |equal |not-sent|| | 1155 |CoAP Code | 8| 1|dw| 68 |equal |not-sent|| | 1156 |CoAP MID |16| 1|bi| 0000 |MSB(12)|LSB ||MMMM | 1157 |CoAP Token |tkl 1|bi| 0x80 |MSB(5) |LSB ||TTT | 1158 |CoAP OSCORE_flags | 8| 1|up| 0x09 |equal |not-sent|| | 1159 |CoAP OSCORE_piv |var 1|up| 0x00 |MSB(4) |LSB ||PPPP | 1160 |COAP OSCORE_kid |var 1|up|0x636c69656e70|MSB(52)|LSB ||KKKK | 1161 |COAP OSCORE_kidctx|var 1|bi| b'' |equal |not-sent|| | 1162 |CoAP OSCORE_flags | 8| 1|dw| b'' |equal |not-sent|| | 1163 |CoAP OSCORE_piv |var 1|dw| b'' |equal |not-sent|| | 1164 |CoAP OSCORE_kid |var 1|dw| b'' |equal |not-sent|| | 1165 +------------------+--+--+--+--------------+-------+--------++------+ 1167 Figure 18: Outer SCHC Rules 1169 The Outer Rule of Figure 18 is applied to the example GET Request and 1170 CONTENT Response. Figure 19 and Figure 20 show the resulting 1171 messages. 1173 Compressed message: 1174 ================== 1175 0x001489458a9fc3686852f6c4 (12 bytes) 1176 0x00 RuleID 1177 1489 Compression Residue 1178 458a9fc3686852f6c4 Padded payload 1180 Compression Residue: 1181 0b 0001 010 0100 0100 (15 bits -> 2 bytes with padding) 1182 mid tkn piv kid 1184 Payload 1185 0xa2c54fe1b434297b62 (9 bytes) 1187 Compressed message length: 12 bytes 1189 Figure 19: SCHC-OSCORE Compressed GET Request 1191 Compressed message: 1192 ================== 1193 0x0014218daf84d983d35de7e48c3c1852 (16 bytes) 1194 0x00 RuleID 1195 14 Compression Residue 1196 218daf84d983d35de7e48c3c1852 Padded payload 1197 Compression Residue: 1198 0b0001 010 (7 bits -> 1 byte with padding) 1199 mid tkn 1201 Payload 1202 0x10c6d7c26cc1e9aef3f2461e0c29 (14 bytes) 1204 Compressed msg length: 16 bytes 1206 Figure 20: SCHC-OSCORE Compressed CONTENT Response 1208 In contrast, comparing these results with what would be obtained by 1209 SCHC compressing the original CoAP messages without protecting them 1210 with OSCORE is done by compressing the CoAP messages according to the 1211 SCHC Rules in Figure 21. 1213 RuleID 1 1214 +---------------+--+--+--+-----------+---------+-----------++-------+ 1215 | Field |FL|FP|DI| Target | MO | CDA || Sent | 1216 | | | | | Value | | || [bits]| 1217 +---------------+--+--+--+-----------+---------+-----------++-------+ 1218 |CoAP version | 2| 1|bi| 01 |equal |not-sent || | 1219 |CoAP Type | 2| 1|up| 0 |equal |not-sent || | 1220 |CoAP Type | 2| 1|dw| 2 |equal |not-sent || | 1221 |CoAP TKL | 4| 1|bi| 1 |equal |not-sent || | 1222 |CoAP Code | 8| 1|up| 2 |equal |not-sent || | 1223 |CoAP Code | 8| 1|dw| [69,132] |match-map|map-sent ||C | 1224 |CoAP MID |16| 1|bi| 0000 |MSB(12) |LSB ||MMMM | 1225 |CoAP Token |tkl 1|bi| 0x80 |MSB(5) |LSB ||TTT | 1226 |CoAP Uri-Path |88| 1|up|temperature|equal |not-sent || | 1227 +---------------+--+--+--+-----------+---------+-----------++-------+ 1229 Figure 21: SCHC-CoAP Rules (No OSCORE) 1231 Figure 21 Rule yields the SCHC compression results in Figure 22 for 1232 request, and Figure 23 for the response. 1234 Compressed message: 1235 ================== 1236 0x0114 1237 0x01 = RuleID 1239 Compression Residue: 1240 0b00010100 (1 byte) 1242 Compressed msg length: 2 1244 Figure 22: CoAP GET Compressed without OSCORE 1246 Compressed message: 1247 ================== 1248 0x010a32332043 1249 0x01 = RuleID 1251 Compression Residue: 1252 0b00001010 (1 byte) 1254 Payload 1255 0x32332043 1257 Compressed msg length: 6 1259 Figure 23: CoAP CONTENT Compressed without OSCORE 1261 As can be seen, the difference between applying SCHC + OSCORE as 1262 compared to regular SCHC + COAP is about 10 bytes. 1264 8. IANA Considerations 1266 This document has no request to IANA. 1268 9. Security considerations 1270 The use of SCHC header compression over CoAP header fields allow the 1271 compression of the header information only. The SCHC header 1272 compression itself does not increase or reduce the level of security 1273 in the communication. When the connection does not use any security 1274 protocol as OSCORE, DTLS, or other, it is necessary to use a layer 1275 two security. 1277 If LPWAN is the layer two technology, the use of SCHC over the CoAP 1278 protocol keeps valid the Security Considerations of SCHC header 1279 compression [RFC8724]. When using another layer two, integrity 1280 protection is mandatory. 1282 The use of SCHC when CoAP uses OSCORE keeps valid the security 1283 considerations defined in [RFC8613]. 1285 DoS attacks are possible if an intruder can introduce a corrupted 1286 SCHC compressed packet onto the link and cause excessive resource 1287 consumption at the decompressor. However, an intruder having the 1288 ability to add corrupted packets at the link layer raises additional 1289 security issues than those related to header compression. 1291 SCHC compression returns variable-length Compression Residues for 1292 some CoAP fields. In the compressed header, the length sent is not 1293 the original header field length but the Compression Residue's length 1294 that is transmitted. So If a corrupted packet comes to the 1295 decompressor with a longer or shorter length than the original 1296 header, SCHC decompression will detect an error and drop the packet. 1298 Using SCHC over the OSCORE headers, OSCORE MUST consider the 1299 Initialization Vector (IV) size carefully in the Compression Residue. 1300 A Compression Residue size obtained with an "LSB" CDA over the IV 1301 impacts the compression efficiency and the frequency that the Device 1302 will renew its key. This operation requires several exchanges and is 1303 energy-consuming. 1305 SCHC header and compression Rules MUST remain tightly coupled. 1306 Otherwise, an encrypted Compression Residue may be decompressed 1307 differently by the receiver. Any update in the context Rules on one 1308 side MUST trigger the OSCORE keys re-establishment. 1310 10. Acknowledgements 1312 The authors would like to thank (in alphabetic order): Christian 1313 Amsuss, Dominique Barthel, Carsten Bormann, Theresa Enghardt, Thomas 1314 Fossati, Klaus Hartke, Benjamin Kaduk, Francesca Palombini, Alexander 1315 Pelov, Goran Selander and Eric Vyncke. 1317 11. Normative References 1319 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 1320 Requirement Levels", BCP 14, RFC 2119, 1321 DOI 10.17487/RFC2119, March 1997, 1322 . 1324 [RFC5116] McGrew, D., "An Interface and Algorithms for Authenticated 1325 Encryption", RFC 5116, DOI 10.17487/RFC5116, January 2008, 1326 . 1328 [RFC7252] Shelby, Z., Hartke, K., and C. Bormann, "The Constrained 1329 Application Protocol (CoAP)", RFC 7252, 1330 DOI 10.17487/RFC7252, June 2014, 1331 . 1333 [RFC7641] Hartke, K., "Observing Resources in the Constrained 1334 Application Protocol (CoAP)", RFC 7641, 1335 DOI 10.17487/RFC7641, September 2015, 1336 . 1338 [RFC7959] Bormann, C. and Z. Shelby, Ed., "Block-Wise Transfers in 1339 the Constrained Application Protocol (CoAP)", RFC 7959, 1340 DOI 10.17487/RFC7959, August 2016, 1341 . 1343 [RFC7967] Bhattacharyya, A., Bandyopadhyay, S., Pal, A., and T. 1344 Bose, "Constrained Application Protocol (CoAP) Option for 1345 No Server Response", RFC 7967, DOI 10.17487/RFC7967, 1346 August 2016, . 1348 [RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC 1349 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, 1350 May 2017, . 1352 [RFC8613] Selander, G., Mattsson, J., Palombini, F., and L. Seitz, 1353 "Object Security for Constrained RESTful Environments 1354 (OSCORE)", RFC 8613, DOI 10.17487/RFC8613, July 2019, 1355 . 1357 [RFC8724] Minaburo, A., Toutain, L., Gomez, C., Barthel, D., and JC. 1358 Zuniga, "SCHC: Generic Framework for Static Context Header 1359 Compression and Fragmentation", RFC 8724, 1360 DOI 10.17487/RFC8724, April 2020, 1361 . 1363 Authors' Addresses 1365 Ana Minaburo 1366 Acklio 1367 1137A avenue des Champs Blancs 1368 35510 Cesson-Sevigne Cedex 1369 France 1371 Email: ana@ackl.io 1373 Laurent Toutain 1374 Institut MINES TELECOM; IMT Atlantique 1375 2 rue de la Chataigneraie 1376 CS 17607 1377 35576 Cesson-Sevigne Cedex 1378 France 1380 Email: Laurent.Toutain@imt-atlantique.fr 1381 Ricardo Andreasen 1382 Universidad de Buenos Aires 1383 Av. Paseo Colon 850 1384 C1063ACV Ciudad Autonoma de Buenos Aires 1385 Argentina 1387 Email: randreasen@fi.uba.ar