idnits 2.17.1 draft-ietf-lpwan-coap-static-context-hc-19.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 1179 has weird spacing: '...tkn piv kid...' == Line 1196 has weird spacing: '... mid tkn...' -- The document date (March 08, 2021) is 1143 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 1220 -- Looks like a reference, but probably isn't: '132' on line 1220 ** 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: September 9, 2021 Institut MINES TELECOM; IMT Atlantique 6 R. Andreasen 7 Universidad de Buenos Aires 8 March 08, 2021 10 LPWAN Static Context Header Compression (SCHC) for CoAP 11 draft-ietf-lpwan-coap-static-context-hc-19 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 September 9, 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 number of Path or Query elements . . . . . . 13 80 5.4. CoAP option Size1, Size2, Proxy-URI and Proxy-Scheme 81 fields . . . . . . . . . . . . . . . . . . . . . . . . . 13 82 5.5. CoAP option ETag, If-Match, If-None-Match, Location-Path, 83 and Location-Query fields . . . . . . . . . . . . . . . . 13 84 6. SCHC compression of CoAP extension RFCs . . . . . . . . . . . 13 85 6.1. Block . . . . . . . . . . . . . . . . . . . . . . . . . . 13 86 6.2. Observe . . . . . . . . . . . . . . . . . . . . . . . . . 13 87 6.3. No-Response . . . . . . . . . . . . . . . . . . . . . . . 14 88 6.4. OSCORE . . . . . . . . . . . . . . . . . . . . . . . . . 14 89 7. Examples of CoAP header compression . . . . . . . . . . . . . 15 90 7.1. Mandatory header with CON message . . . . . . . . . . . . 15 91 7.2. OSCORE Compression . . . . . . . . . . . . . . . . . . . 16 92 7.3. Example OSCORE Compression . . . . . . . . . . . . . . . 20 93 8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 31 94 9. Security considerations . . . . . . . . . . . . . . . . . . . 31 95 10. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 32 96 11. Normative References . . . . . . . . . . . . . . . . . . . . 32 97 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 33 99 1. Introduction 101 CoAP [RFC7252] is a command/response protocol designed for micro- 102 controllers with a small RAM and ROM and optimized for REST-based 103 (Representative state transfer) services. Although the Constrained 104 Devices leads the CoAP design, a CoAP header's size is still too 105 large for LPWAN (Low Power Wide Area Networks). SCHC header 106 compression over CoAP header is required to increase performance or 107 use CoAP over LPWAN technologies. 109 The [RFC8724] defines SCHC, a header compression mechanism for the 110 LPWAN network based on a static context. Section 5 of the [RFC8724] 111 explains where compression and decompression occur in the 112 architecture. The SCHC compression scheme assumes as a prerequisite 113 that both end-points know the static context before transmission. 114 The way the context is configured, provisioned, or exchanged is out 115 of this document's scope. 117 CoAP is an application protocol, so CoAP compression requires 118 installing common Rules between the two SCHC instances. SCHC 119 compression may apply at two different levels: at IP and UDP in the 120 LPWAN network and another at the application level for CoAP. These 121 two compressions may be independent. Both follow the same principle 122 described in [RFC8724]. As different entities manage the CoAP 123 compression at different levels, the SCHC Rules driving the 124 compression/decompression are also different. The [RFC8724] 125 describes how to use SCHC for IP and UDP headers. This document 126 specifies how to apply SCHC compression to CoAP headers. 128 SCHC compresses and decompresses headers based on common contexts 129 between Devices. SCHC context includes multiple Rules. Each Rule 130 can match the header fields to specific values or ranges of values. 131 If a Rule matches, the matched header fields are replaced by the 132 RuleID and the Compression Residue that contains the residual bits of 133 the compression. Thus, different Rules may correspond to different 134 protocol headers in the packet that a Device expects to send or 135 receive. 137 A Rule describes the packets' entire header with an ordered list of 138 fields descriptions; see section 7 of [RFC8724]. Thereby 139 each description contains the field ID (FID), its length (FL), and 140 its position (FP), a direction indicator (DI) (upstream, downstream, 141 and bidirectional), and some associated Target Values (TV). The 142 direction indicator is used for compression to give the best TV to 143 the FID when these values differ in the transmission direction. So a 144 field may be described several times. 146 A Matching Operator (MO) is associated with each header field 147 description. The Rule is selected if all the MOs fit the TVs for all 148 fields of the incoming header. A Rule cannot be selected if the 149 message contains an unknown field to the SCHC compressor. 151 In that case, a Compression/Decompression Action (CDA) associated 152 with each field gives the method to compress and decompress each 153 field. Compression mainly results in one of 4 actions: 155 o send the field value (value-sent), 157 o send nothing (not-sent), 159 o send some least significant bits of the field (LSB) or, 161 o send an index (mapping-sent). 163 After applying the compression, there may be some bits to be sent. 164 These values are called Compression Residue. 166 SCHC is a general mechanism applied to different protocols, the exact 167 Rules to be used depending on the protocol and the Application. 168 Section 10 of the [RFC8724] describes the compression scheme for IPv6 169 and UDP headers. This document targets the CoAP header compression 170 using SCHC. 172 1.1. Terminology 174 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 175 "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and 176 "OPTIONAL" in this document are to be interpreted as described in BCP 177 14 [RFC2119][RFC8174] when, and only when, they appear in all 178 capitals, as shown here. 180 2. SCHC Applicability to CoAP 182 SCHC Compression for CoAP header MAY be done in conjunction with the 183 lower layers (IPv6/UDP) or independently. The SCHC adaptation 184 layers, described in Section 5 of [RFC8724], may be used as shown in 185 Figure 1, Figure 2, and Figure 3. 187 In the first example, Figure 1, a Rule compresses the complete header 188 stack from IPv6 to CoAP. In this case, the Device and the NGW 189 perform SCHC C/D (Static Context Header Compression Compressor/ 190 Decompressor). The Application communicating with the Device does 191 not implement SCHC C/D. 193 (Device) (NGW) (App) 195 +--------+ +--------+ 196 | CoAP | | CoAP | 197 +--------+ +--------+ 198 | UDP | | UDP | 199 +--------+ +----------------+ +--------+ 200 | IPv6 | | IPv6 | | IPv6 | 201 +--------+ +--------+-------+ +--------+ 202 | SCHC | | SCHC | | | | 203 +--------+ +--------+ + + + 204 | LPWAN | | LPWAN | | | | 205 +--------+ +--------+-------+ +--------+ 206 ((((LPWAN)))) ------ Internet ------ 208 Figure 1: Compression/Decompression at the LPWAN boundary. 210 Figure 1 shows the use of SCHC header compression above layer 2 in 211 the Device and the NGW. The SCHC layer receives non-encrypted 212 packets and can apply compression Rules to all the headers in the 213 stack. On the other end, the NGW receives the SCHC packet and 214 reconstructs the headers using the Rule and the Compression Residue. 215 After the decompression, the NGW forwards the IPv6 packet toward the 216 destination. The same process applies in the other direction when a 217 non-encrypted packet arrives at the NGW. Thanks to the IP forwarding 218 based on the IPv6 prefix, the NGW identifies the Device and 219 compresses headers using the Device's Rules. 221 In the second example, Figure 2, the SCHC compression is applied in 222 the CoAP layer, compressing the CoAP header independently of the 223 other layers. The RuleID, the Compression Residue, and CoAP payload 224 are encrypted using a mechanism such as DTLS. Only the other end 225 (App) can decipher the information. If needed, layers below use SCHC 226 to compress the header as defined in [RFC8724] (represented in dotted 227 lines). 229 This use case needs an end-to-end context initialization between the 230 Device and the Application. The context initialization is out of the 231 scope of this document. 233 (Device) (NGW) (App) 235 +--------+ +--------+ 236 | CoAP | | CoAP | 237 +--------+ +--------+ 238 | SCHC | | SCHC | 239 +--------+ +--------+ 240 | DTLS | | DTLS | 241 +--------+ +--------+ 242 . udp . . udp . 243 .......... .................. .......... 244 . ipv6 . . ipv6 . . ipv6 . 245 .......... .................. .......... 246 . schc . . schc . . . . 247 .......... .......... . . . 248 . lpwan . . lpwan . . . . 249 .......... .................. .......... 250 ((((LPWAN)))) ------ Internet ------ 252 Figure 2: Standalone CoAP end-to-end Compression/Decompression 254 The third example, Figure 3, shows the use of Object Security for 255 Constrained RESTful Environments (OSCORE) [RFC8613]. In this case, 256 SCHC needs two Rules to compress the CoAP header. A first Rule 257 focused on the inner header. The result of this first compression is 258 encrypted using the OSCORE mechanism. Then a second Rule compresses 259 the outer header, including the OSCORE Options. 261 (Device) (NGW) (App) 263 +--------+ +--------+ 264 | CoAP | | CoAP | 265 | inner | | inner | 266 +--------+ +--------+ 267 | SCHC | | SCHC | 268 | inner | | inner | 269 +--------+ +--------+ 270 | CoAP | | CoAP | 271 | outer | | outer | 272 +--------+ +--------+ 273 | SCHC | | SCHC | 274 | outer | | outer | 275 +--------+ +--------+ 276 . udp . . udp . 277 .......... .................. .......... 278 . ipv6 . . ipv6 . . ipv6 . 279 .......... .................. .......... 280 . schc . . schc . . . . 281 .......... .......... . . . 282 . lpwan . . lpwan . . . . 283 .......... .................. .......... 284 ((((LPWAN)))) ------ Internet ------ 286 Figure 3: OSCORE compression/decompression. 288 In the case of several SCHC instances, as shown in Figure 2 and 289 Figure 3, the Rules may come from different provisioning domains. 291 This document focuses on CoAP compression represented in the dashed 292 boxes in the previous figures. 294 3. CoAP Headers compressed with SCHC 296 The use of SCHC over the CoAP header uses the same description, and 297 compression/decompression techniques like the one for IP and UDP 298 explained in the [RFC8724]. For CoAP, the SCHC Rules description 299 uses the direction information to optimize the compression by 300 reducing the number of Rules needed to compress headers. The field 301 description MAY define both request/response headers and target 302 values in the same Rule, using the DI (direction indicator) to make 303 the difference. 305 As for other header compression protocols, when the compressor does 306 not find a correct Rule to compress the header, the packet MUST be 307 sent uncompressed using the RuleID dedicated to this purpose. Where 308 the Compression Residue is the complete header of the packet. See 309 section 6 of [RFC8724]. 311 3.1. Differences between CoAP and UDP/IP Compression 313 CoAP compression differs from IPv6 and UDP compression in the 314 following aspects: 316 o The CoAP protocol is asymmetric; the headers are different for a 317 request or a response. For example, the URI-Path option is 318 mandatory in the request, and it might not be present in the 319 response. A request might contain an Accept option, and the 320 response might include a Content-Format option. In comparison, 321 IPv6 and UDP returning path swap the value of some fields in the 322 header. However, all the directions have the same fields (e.g., 323 source and destination address fields). 325 The [RFC8724] defines the use of a direction indicator (DI) in the 326 Field Descriptor, which allows a single Rule to process a message 327 header differently depending on the direction. 329 o Even when a field is "symmetric" (i.e., found in both directions), 330 the values carried in each direction are different. The 331 compression may use a "match-mapping" MO to limit the range of 332 expected values in a particular direction and reduce the 333 Compression Residue's size. Through the direction indicator (DI), 334 a field description in the Rules splits the possible field value 335 into two parts, one for each direction. For instance, if a client 336 sends only CON requests, the Type can be elided by compression, 337 and the answer may use one single bit to carry either the ACK or 338 RST type. The field Code has the same behavior, the 0.0X code 339 format value in the request, and the Y.ZZ code format in the 340 response. 342 o In SCHC, the Rule defines the different header fields' length, so 343 SCHC does not need to send it. In IPv6 and UDP headers, the 344 fields have a fixed size, known by definition. On the other hand, 345 some CoAP header fields have variable lengths, and the Rule 346 description specifies it. For example, in a URI-path or URI- 347 query, the Token size may vary from 0 to 8 bytes, and the CoAP 348 options use the Type-Length-Value encoding format. 350 When doing SCHC compression of a variable-length field, 351 Section 7.5.2 from [RFC8724] offers the possibility to define a 352 function for the Field length in the Field Description to know the 353 length before compression. If the field length is unknown, the 354 Rule will set it as a variable, and SCHC will send the compressed 355 field's length in the Compression Residue. 357 o A field can appear several times in the CoAP headers. It is found 358 typically for elements of a URI (path or queries). The SCHC 359 specification [RFC8724] allows a Field ID to appear several times 360 in the Rule and uses the Field Position (FP) to identify the 361 correct instance, thereby removing the matching operation's 362 ambiguity. 364 o Field lengths defined in the CoAP protocol can be too 365 large regarding LPWAN traffic constraints. For instance, this is 366 particularly true for the Message-ID field and the Token field. 367 SCHC uses different Matching operators (MO) to perform the 368 compression. See section 7.4 of [RFC8724]. In this case, SCHC 369 can apply the Most Significant Bits (MSB) MO to reduce the 370 information carried on LPWANs. 372 4. Compression of CoAP header fields 374 This section discusses the compression of the different CoAP header 375 fields. The CoAP compression with SCHC follows Section 7.1 of 376 [RFC8724]. 378 4.1. CoAP version field 380 CoAP version is bidirectional and MUST be elided during the SCHC 381 compression since it always contains the same value. In the future, 382 or if a new version of CoAP is defined, new Rules will be needed to 383 avoid ambiguities between versions. 385 4.2. CoAP type field 387 The CoAP protocol [RFC7252] has four types of messages: two requests 388 (CON, NON), one response (ACK), and one empty message (RST). 390 The SCHC compression SHOULD elide this field if, for instance, a 391 client is sending only NON or only CON messages. For the RST 392 message, SCHC may use a dedicated Rule. For other usages, SCHC can 393 use a "match-mapping" MO. 395 4.3. CoAP code field 397 The code field is an IANA registry [RFC7252], and it indicates the 398 Request Method used in CoAP. The compression of the CoAP code field 399 follows the same principle as that of the CoAP type field. If the 400 Device plays a specific role, SCHC may split the code values into two 401 fields description, the request codes with the 0 class and the 402 response values. SCHC will use the direction indicator to identify 403 the correct value in the packet. 405 If the Device only implements a CoAP client, SCHC compression may 406 reduce the request code to the set of requests the client can 407 process. 409 For known values, SCHC can use a "match-mapping" MO. If SCHC cannot 410 compress the code field, it will send the values in the Compression 411 Residue. 413 4.4. CoAP Message ID field 415 SCHC can compress the Message ID field with the "MSB" MO and the 416 "LSB" CDA. See section 7.4 of [RFC8724]. 418 4.5. CoAP Token fields 420 CoAP defines the Token using two CoAP fields, Token Length in the 421 mandatory header and Token Value directly following the mandatory 422 CoAP header. 424 SCHC processes the Token length as any header field. If the value 425 does not change, the size can be stored in the TV and elided during 426 the transmission. Otherwise, SCHC will send the token length in the 427 Compression Residue. 429 For the Token Value, SCHC MUST NOT send it as a variable-length in 430 the Compression Residue to avoid ambiguity with Token Length. 431 Therefore, SCHC MUST use the Token length value to define the size of 432 the Compression Residue. SCHC designates a specific function "tkl" 433 that the Rule MUST use to complete the field description. During the 434 decompression, this function returns the value contained in the Token 435 Length field. 437 5. CoAP options 439 CoAP defines options placed after the basic header in Option Numbers 440 order; see [RFC7252]. Each Option instance in a message uses the 441 format Delta-Type (D-T), Length (L), Value (V). The SCHC Rule builds 442 the description of the option by using in the Field ID the Option 443 Number built from D-T; in TV, the Option Value; and the Option Length 444 uses section 7.4 of [RFC8724]. When the Option Length has a well- 445 known size, the Rule may keep the length value. Therefore, SCHC 446 compression does not send it. Otherwise, SCHC Compression carries 447 the length of the Compression Residue, in addition to the Compression 448 Residue value. 450 CoAP requests and responses do not include the same options. So 451 Compression Rules may reflect this asymmetry by tagging the direction 452 indicator. 454 Note that length coding differs between CoAP options and SCHC 455 variable size Compression Residue. 457 The following sections present how SCHC compresses some specific CoAP 458 options. 460 If CoAP introduces a new option, the SCHC Rules MAY be updated, and 461 the new Field ID description MUST be assigned to allow its 462 compression. Otherwise, if no Rule describes this new option, the 463 SCHC compression is not achieved, and SCHC sends the CoAP header 464 without compression. 466 5.1. CoAP Content and Accept options. 468 If the client expects a single value, it can be stored in the TV and 469 elided during the transmission. Otherwise, if the client expects 470 several possible values, a "match-mapping" SHOULD be used to limit 471 the Compression Residue's size. If not, SCHC has to send the option 472 value in the Compression Residue (fixed or variable length). 474 5.2. CoAP option Max-Age, Uri-Host, and Uri-Port fields 476 SCHC compresses these three fields in the same way. When the value 477 of these options is known, SCHC can elide these fields. If the 478 option uses well-known values, SCHC can use a "match-mapping" MO. 479 Otherwise, SCHC will use "value-sent" MO, and the Compression Residue 480 will send these options' values. 482 5.3. CoAP option Uri-Path and Uri-Query fields 484 The Uri-Path and Uri-Query fields are repeatable options; this means 485 that in the CoAP header, they may appear several times with different 486 values. SCHC Rule description uses the Field Position (FP) to 487 distinguish the different instances in the path. 489 To compress repeatable field values, SCHC may use a "match-mapping" 490 MO to reduce the size of variable Paths or Queries. In these cases, 491 to optimize the compression, several elements can be regrouped into a 492 single entry. The Numbering of elements does not change, and the 493 first matching element sets the MO comparison. 495 +--------+---+--+--+--------+-------------+------------+ 496 | Field |FL |FP|DI| Target | Matching | CDA | 497 | | | | | Value | Operator | | 498 +--------+---+--+--+--------+-------------+------------+ 499 |Uri-Path| | 1|up|["/a/b",|match-mapping|mapping-sent| 500 | | | | |"/c/d"] | | | 501 |Uri-Path|var| 3|up| |ignore |value-sent | 502 +--------+---+--+--+--------+-------------+------------+ 504 Figure 4: complex path example 506 In Figure 4, SCHC can use a single bit in the Compression Residue to 507 code one of the two paths. If regrouping were not allowed, 2 bits in 508 the Compression Residue would be needed. SCHC sends the third path 509 element as a variable size in the Compression Residue. 511 The length of URI-Path and URI-Query may be known when the rule is 512 defined. In any case, SCHC MUST set the field length to variable. 513 The unit to indicate the Compression Residue size is in Byte. 515 SCHC compression can use the MSB MO to a Uri-Path or Uri-Query 516 element. However, attention to the length is important because the 517 MSB value is in bits, and the size MUST always be a multiple of 8 518 bits. 520 The length sent at the beginning of a variable-length Compression 521 Residue indicates the LSB's size in bytes. 523 For instance, for a CORECONF path /c/X6?k="eth0" the Rule description 524 can be: 526 +-------------+---+--+--+--------+---------+-------------+ 527 | Field |FL |FP|DI| Target | Match | CDA | 528 | | | | | Value | Opera. | | 529 +-------------+---+--+--+--------+---------+-------------+ 530 |Uri-Path | | 1|up|"c" |equal |not-sent | 531 |Uri-Path |var| 2|up| |ignore |value-sent | 532 |Uri-Query |var| 1|up|"k=\"" |MSB(24) |LSB | 533 +-------------+---+--+--+--------+---------+-------------+ 535 Figure 5: CORECONF URI compression 537 Figure 5 shows the Rule description for a URI-Path and a URI-Query. 538 SCHC compresses the first part of the URI-Path with a "not-sent" CDA. 539 SCHC will send the second element of the URI-Path with the length 540 (i.e., 0x2 X 6) followed by the query option (i.e., 0x05 eth0"). 542 5.3.1. Variable number of Path or Query elements 544 SCHC fixed the number of Uri-Path or Uri-Query elements in a Rule at 545 the Rule creation time. If the number varies, SCHC SHOULD create 546 several Rules to cover all the possibilities. Another one is to 547 define the length of Uri-Path to variable and sends a Compression 548 Residue with a length of 0 to indicate that this Uri-Path is empty. 549 However, this adds 4 bits to the variable Compression Residue size. 550 See section 7.5.2 [RFC8724]. 552 5.4. CoAP option Size1, Size2, Proxy-URI and Proxy-Scheme fields 554 The SCHC Rule description MAY define sending some field values by 555 setting the TV to "not-sent," MO to "ignore," and CDA to "value- 556 sent." A Rule MAY also use a "match-mapping" when there are 557 different options for the same FID. Otherwise, the Rule sets the TV 558 to the value, MO to "equal," and CDA to "not-sent." 560 5.5. CoAP option ETag, If-Match, If-None-Match, Location-Path, and 561 Location-Query fields 563 A Rule entry cannot store these fields' values. The Rule description 564 MUST always send these values in the Compression Residue. 566 6. SCHC compression of CoAP extension RFCs 568 6.1. Block 570 When a packet uses a Block [RFC7959] option, SCHC compression MUST 571 send its content in the Compression Residue. The SCHC Rule describes 572 an empty TV with a MO set to "ignore" and a CDA to "value-sent." 573 Block option allows fragmentation at the CoAP level that is 574 compatible with SCHC fragmentation. Both fragmentation mechanisms 575 are complementary, and the node may use them for the same packet as 576 needed. 578 6.2. Observe 580 The [RFC7641] defines the Observe option. The SCHC Rule description 581 will not define the TV, but MO to "ignore," and the CDA to "value- 582 sent." SCHC does not limit the maximum size for this option (3 583 bytes). To reduce the transmission size, either the Device 584 implementation MAY limit the delta between two consecutive values, or 585 a proxy can modify the increment. 587 Since the Observe option MAY use an RST message to inform a server 588 that the client does not require the Observe response, a specific 589 SCHC Rule SHOULD exist to allow the message's compression with the 590 RST type. 592 6.3. No-Response 594 The [RFC7967] defines a No-Response option limiting the responses 595 made by a server to a request. Different behaviors exist while using 596 this option to limit the responses made by a server to a request. If 597 both ends know the value, then the SCHC Rule will describe a TV to 598 this value, with a MO set to "equal" and CDA set to "not-sent." 600 Otherwise, if the value is changing over time, the SCHC Rule will set 601 the MO to "ignore" and CDA to "value-sent." The Rule may also use a 602 "match-mapping" to compress this option. 604 6.4. OSCORE 606 OSCORE [RFC8613] defines end-to-end protection for CoAP messages. 607 This section describes how SCHC Rules can be applied to compress 608 OSCORE-protected messages. 610 0 1 2 3 4 5 6 7 <--------- n bytes -------------> 611 +-+-+-+-+-+-+-+-+--------------------------------- 612 |0 0 0|h|k| n | Partial IV (if any) ... 613 +-+-+-+-+-+-+-+-+--------------------------------- 614 | | | 615 |<-- CoAP -->|<------ CoAP OSCORE_piv ------> | 616 OSCORE_flags 618 <- 1 byte -> <------ s bytes -----> 619 +------------+----------------------+-----------------------+ 620 | s (if any) | kid context (if any) | kid (if any) ... | 621 +------------+----------------------+-----------------------+ 622 | | | 623 | <------ CoAP OSCORE_kidctx ------>|<-- CoAP OSCORE_kid -->| 625 Figure 6: OSCORE Option 627 The Figure 6 shows the OSCORE Option Value encoding defined in 628 Section 6.1 of [RFC8613], where the first byte specifies the Content 629 of the OSCORE options using flags. The three most significant bits 630 of this byte are reserved and always set to 0. Bit h, when set, 631 indicates the presence of the kid context field in the option. Bit 632 k, when set, indicates the presence of a kid field. The three least 633 significant bits n indicate the length of the piv (Partial 634 Initialization Vector) field in bytes. When n = 0, no piv is 635 present. 637 The flag byte is followed by the piv field, kid context field, and 638 kid field in this order, and if present, the kid context field's 639 length is encoded in the first byte denoting by 's' the length of the 640 kid context in bytes. 642 To better perform OSCORE SCHC compression, the Rule description needs 643 to identify the OSCORE Option and the fields it contains. 644 Conceptually, it discerns up to 4 distinct pieces of information 645 within the OSCORE option: the flag bits, the piv, the kid context, 646 and the kid. The SCHC Rule splits into four field descriptions the 647 OSCORE option to compress them: 649 o CoAP OSCORE_flags, 651 o CoAP OSCORE_piv, 653 o CoAP OSCORE_kidctx, 655 o CoAP OSCORE_kid. 657 Figure 6 shows the OSCORE Option format with those four fields 658 superimposed on it. Note that the CoAP OSCORE_kidctx field directly 659 includes the size octet s. 661 7. Examples of CoAP header compression 663 7.1. Mandatory header with CON message 665 In this first scenario, the SCHC Compressor at the Network Gateway 666 side receives a POST message from an Internet client, which is 667 immediately acknowledged by the Device. Figure 7 describes the SCHC 668 Rule descriptions for this scenario. 670 RuleID 1 671 +-------------+--+--+--+------+---------+-------------++------------+ 672 | Field |FL|FP|DI|Target| Match | CDA || Sent | 673 | | | | |Value | Opera. | || [bits] | 674 +-------------+--+--+--+------+---------+-------------++------------+ 675 |CoAP version | 2| 1|bi| 01 |equal |not-sent || | 676 |CoAP Type | 2| 1|dw| CON |equal |not-sent || | 677 |CoAP Type | 2| 1|up|[ACK, |match- |matching- || | 678 | | | | | RST] |mapping |sent || T | 679 |CoAP TKL | 4| 1|bi| 0 |equal |not-sent || | 680 |CoAP Code | 8| 1|bi|[0.00,| | || | 681 | | | | | ... |match- |matching- || | 682 | | | | | 5.05]|mapping |sent || CC CCC | 683 |CoAP MID |16| 1|bi| 0000 |MSB(7 ) |LSB || M-ID| 684 |CoAP Uri-Path|var 1|dw| path |equal 1 |not-sent || | 685 +-------------+--+--+--+------+---------+-------------++------------+ 687 Figure 7: CoAP Context to compress header without Token 689 In this example, SCHC compression elides the version and the Token 690 Length fields. The 26 method and response codes defined in [RFC7252] 691 has been shrunk to 5 bits using a "match-mapping" MO. The Uri-Path 692 contains a single element indicated in the TV and elided with the CDA 693 "not-sent." 695 SCHC Compression reduces the header sending only the Type, a mapped 696 code, and the least significant bits of Message ID (9 bits in the 697 example above). 699 Note that a client located in an Application Server sending a request 700 to a server located in the Device may not be compressed through this 701 Rule since the MID might not start with 7 bits equal to 0. A CoAP 702 proxy placed before the SCHC C/D can rewrite the message ID to fit 703 the value and match the Rule. 705 7.2. OSCORE Compression 707 OSCORE aims to solve the problem of end-to-end encryption for CoAP 708 messages. Therefore, the goal is to hide as much as possible the 709 message while still enabling proxy operation. 711 Conceptually this is achieved by splitting the CoAP message into an 712 Inner Plaintext and Outer OSCORE Message. The Inner Plaintext 713 contains sensitive information that is not necessary for proxy 714 operation. However, it is part of the message that can be encrypted 715 until it reaches its end destination. The Outer Message acts as a 716 shell matching the regular CoAP message format and includes all 717 Options and information needed for proxy operation and caching. 718 Figure 8 illustrates this analysis. 720 The CoAP protocol arranges the options into one of 3 classes; each 721 granted a specific type of protection by the protocol: 723 o Class E: Encrypted options moved to the Inner Plaintext, 725 o Class I: Integrity-protected options included in the AAD for the 726 encryption of the Plaintext but otherwise left untouched in the 727 Outer Message, 729 o Class U: Unprotected options left untouched in the Outer Message. 731 These classes point out that the Outer option contains the OSCORE 732 Option and that the message is OSCORE protected; this option carries 733 the information necessary to retrieve the Security Context. The end- 734 point will use this Security Context to decrypt the message 735 correctly. 737 Original CoAP Packet 738 +-+-+---+-------+---------------+ 739 |v|t|TKL| code | Msg Id. | 740 +-+-+---+-------+---------------+....+ 741 | Token | 742 +-------------------------------.....+ 743 | Options (IEU) | 744 . . 745 . . 746 +------+-------------------+ 747 | 0xFF | 748 +------+------------------------+ 749 | | 750 | Payload | 751 | | 752 +-------------------------------+ 753 / \ 754 / \ 755 / \ 756 / \ 757 Outer Header v v Plaintext 758 +-+-+---+--------+---------------+ +-------+ 759 |v|t|TKL|new code| Msg Id. | | code | 760 +-+-+---+--------+---------------+....+ +-------+-----......+ 761 | Token | | Options (E) | 762 +--------------------------------.....+ +-------+------.....+ 763 | Options (IU) | | OxFF | 764 . . +-------+-----------+ 765 . OSCORE Option . | | 766 +------+-------------------+ | Payload | 767 | 0xFF | | | 768 +------+ +-------------------+ 770 Figure 8: A CoAP packet is split into an OSCORE outer and plaintext 772 Figure 8 shows the packet format for the OSCORE Outer header and 773 Plaintext. 775 In the Outer Header, the original header code is hidden and replaced 776 by a default dummy value. As seen in Sections 4.1.3.5 and 4.2 of 777 [RFC8613], the message code is replaced by POST for requests and 778 Changed for responses when CoAP is not using the Observe option. If 779 CoAP uses Observe, the OSCORE message code is replaced by FETCH for 780 requests and Content for responses. 782 The first byte of the Plaintext contains the original packet code, 783 followed by the message code, the class E options, and, if present, 784 the original message Payload preceded by its payload marker. 786 An AEAD algorithm now encrypts the Plaintext. This integrity 787 protects the Security Context parameters and, eventually, any class I 788 options from the Outer Header. The resulting Ciphertext becomes the 789 new payload of the OSCORE message, as illustrated in Figure 9. 791 As defined in [RFC5116], this Ciphertext is the encrypted Plaintext's 792 concatenation of the authentication tag. Note that Inner Compression 793 only affects the Plaintext before encryption. Thus only the first 794 variable-length of the Ciphertext can be reduced. The authentication 795 tag is fixed in length and is considered part of the cost of 796 protection. 798 Outer Header 799 +-+-+---+--------+---------------+ 800 |v|t|TKL|new code| Msg Id. | 801 +-+-+---+--------+---------------+....+ 802 | Token | 803 +--------------------------------.....+ 804 | Options (IU) | 805 . . 806 . OSCORE Option . 807 +------+-------------------+ 808 | 0xFF | 809 +------+---------------------------+ 810 | | 811 | Ciphertext: Encrypted Inner | 812 | Header and Payload | 813 | + Authentication Tag | 814 | | 815 +----------------------------------+ 817 Figure 9: OSCORE message 819 The SCHC Compression scheme consists of compressing both the 820 Plaintext before encryption and the resulting OSCORE message after 821 encryption, see Figure 10. 823 The OSCORE message translates into a segmented process where SCHC 824 compression is applied independently in 2 stages, each with its 825 corresponding set of Rules, with the Inner SCHC Rules and the Outer 826 SCHC Rules. This way, compression is applied to all fields of the 827 original CoAP message. 829 Note that since the corresponding end-point can only decrypt the 830 Inner part of the message, this end-point will also have to implement 831 Inner SCHC Compression/Decompression. 833 Outer Message OSCORE Plaintext 834 +-+-+---+--------+---------------+ +-------+ 835 |v|t|TKL|new code| Msg Id. | | code | 836 +-+-+---+--------+---------------+....+ +-------+-----......+ 837 | Token | | Options (E) | 838 +--------------------------------.....+ +-------+------.....+ 839 | Options (IU) | | OxFF | 840 . . +-------+-----------+ 841 . OSCORE Option . | | 842 +------+-------------------+ | Payload | 843 | 0xFF | | | 844 +------+------------+ +-------------------+ 845 | Ciphertext |<---------\ | 846 | | | v 847 +-------------------+ | +-----------------+ 848 | | | Inner SCHC | 849 v | | Compression | 850 +-----------------+ | +-----------------+ 851 | Outer SCHC | | | 852 | Compression | | v 853 +-----------------+ | +-------+ 854 | | |RuleID | 855 v | +-------+-----------+ 856 +--------+ +------------+ |Compression Residue| 857 |RuleID' | | Encryption | <-- +----------+--------+ 858 +--------+-----------+ +------------+ | | 859 |Compression Residue'| | Payload | 860 +-----------+--------+ | | 861 | Ciphertext | +-------------------+ 862 | | 863 +--------------------+ 865 Figure 10: OSCORE Compression Diagram 867 7.3. Example OSCORE Compression 869 This section gives an example with a GET Request and its consequent 870 Content Response from a Device-based CoAP client to a cloud-based 871 CoAP server. The example also describes a possible set of Rules for 872 the Inner and Outer SCHC Compression. A dump of the results and a 873 contrast between SCHC + OSCORE performance with SCHC + COAP 874 performance is also listed. This example gives an approximation of 875 the cost of security with SCHC-OSCORE. 877 Our first CoAP message is the GET request in Figure 11. 879 Original message: 880 ================= 881 0x4101000182bb74656d7065726174757265 883 Header: 884 0x4101 885 01 Ver 886 00 CON 887 0001 TKL 888 00000001 Request Code 1 "GET" 890 0x0001 = mid 891 0x82 = token 893 Options: 894 0xbb74656d7065726174757265 895 Option 11: URI_PATH 896 Value = temperature 898 Original msg length: 17 bytes. 900 Figure 11: CoAP GET Request 902 Its corresponding response is the CONTENT Response in Figure 12. 904 Original message: 905 ================= 906 0x6145000182ff32332043 908 Header: 909 0x6145 910 01 Ver 911 10 ACK 912 0001 TKL 913 01000101 Successful Response Code 69 "2.05 Content" 915 0x0001 = mid 916 0x82 = token 918 0xFF Payload marker 919 Payload: 920 0x32332043 922 Original msg length: 10 924 Figure 12: CoAP CONTENT Response 926 The SCHC Rules for the Inner Compression include all fields already 927 present in a regular CoAP message. The methods described in 928 Section 4 apply to these fields. As an example, see Figure 13. 930 RuleID 0 931 +--------------+--+--+--+-----------+---------+---------++------+ 932 | Field |FL|FP|DI| Target | MO | CDA || Sent | 933 | | | | | Value | | ||[bits]| 934 +--------------+--+--+--+-----------+---------+---------++------+ 935 |CoAP Code | 8| 1|up| 1 | equal |not-sent || | 936 |CoAP Code | 8| 1|dw|[69, | | || | 937 | | | | |132] |match- |mapping- || | 938 | | | | | |mapping |sent || c | 939 |CoAP Uri-Path | | 1|up|temperature| equal |not-sent || | 940 +--------------+--+--+--+-----------+---------+---------++------+ 942 Figure 13: Inner SCHC Rules 944 Figure 14 shows the Plaintext obtained for the example GET request. 945 The packet follows the process of Inner Compression and Encryption 946 until the payload. The outer OSCORE Message adds the result of the 947 Inner process. 949 In this case, the original message has no payload, and its resulting 950 Plaintext compressed up to only 1 byte (size of the RuleID). The 951 AEAD algorithm preserves this length in its first output and yields a 952 fixed-size tag. SCHC cannot compress the tag, and the OSCORE message 953 must include it without compression. The use of integrity protection 954 translates into an overhead in total message length, limiting the 955 amount of compression that can be achieved and plays into the cost of 956 adding security to the exchange. 958 ________________________________________________________ 959 | | 960 | OSCORE Plaintext | 961 | | 962 | 0x01bb74656d7065726174757265 (13 bytes) | 963 | | 964 | 0x01 Request Code GET | 965 | | 966 | bb74656d7065726174757265 Option 11: URI_PATH | 967 | Value = temperature | 968 |________________________________________________________| 970 | 971 | 972 | Inner SCHC Compression 973 | 974 v 975 _________________________________ 976 | | 977 | Compressed Plaintext | 978 | | 979 | 0x00 | 980 | | 981 | RuleID = 0x00 (1 byte) | 982 | (No Compression Residue) | 983 |_________________________________| 985 | 986 | AEAD Encryption 987 | (piv = 0x04) 988 v 989 _________________________________________________ 990 | | 991 | encrypted_plaintext = 0xa2 (1 byte) | 992 | tag = 0xc54fe1b434297b62 (8 bytes) | 993 | | 994 | ciphertext = 0xa2c54fe1b434297b62 (9 bytes) | 995 |_________________________________________________| 997 Figure 14: Plaintext compression and encryption for GET Request 999 Figure 15 shows the process for the example CONTENT Response. The 1000 Compression Residue is 1 bit long. Note that since SCHC adds padding 1001 after the payload, this misalignment causes the hexadecimal code from 1002 the payload to differ from the original, even if SCHC cannot compress 1003 the tag. The overhead for the tag bytes limits the SCHC's 1004 performance but brings security to the transmission. 1006 ________________________________________________________ 1007 | | 1008 | OSCORE Plaintext | 1009 | | 1010 | 0x45ff32332043 (6 bytes) | 1011 | | 1012 | 0x45 Successful Response Code 69 "2.05 Content" | 1013 | | 1014 | ff Payload marker | 1015 | | 1016 | 32332043 Payload | 1017 |________________________________________________________| 1019 | 1020 | 1021 | Inner SCHC Compression 1022 | 1023 v 1024 _____________________________________________ 1025 | | 1026 | Compressed Plaintext | 1027 | | 1028 | 0x001919902180 (6 bytes) | 1029 | | 1030 | 00 RuleID | 1031 | | 1032 | 0b0 (1 bit match-map Compression Residue) | 1033 | 0x32332043 >> 1 (shifted payload) | 1034 | 0b0000000 Padding | 1035 |_____________________________________________| 1037 | 1038 | AEAD Encryption 1039 | (piv = 0x04) 1040 v 1041 _________________________________________________________ 1042 | | 1043 | encrypted_plaintext = 0x10c6d7c26cc1 (6 bytes) | 1044 | tag = 0xe9aef3f2461e0c29 (8 bytes) | 1045 | | 1046 | ciphertext = 0x10c6d7c26cc1e9aef3f2461e0c29 (14 bytes) | 1047 |_________________________________________________________| 1049 Figure 15: Plaintext compression and encryption for CONTENT Response 1051 The Outer SCHC Rules (Figure 18) must process the OSCORE Options 1052 fields. Figure 16 and Figure 17 shows a dump of the OSCORE Messages 1053 generated from the example messages. They include the Inner 1054 Compressed Ciphertext in the payload. These are the messages that 1055 have to be compressed by the Outer SCHC Compression. 1057 Protected message: 1058 ================== 1059 0x4102000182d8080904636c69656e74ffa2c54fe1b434297b62 1060 (25 bytes) 1062 Header: 1063 0x4102 1064 01 Ver 1065 00 CON 1066 0001 TKL 1067 00000010 Request Code 2 "POST" 1069 0x0001 = mid 1070 0x82 = token 1072 Options: 1073 0xd8080904636c69656e74 (10 bytes) 1074 Option 21: OBJECT_SECURITY 1075 Value = 0x0904636c69656e74 1076 09 = 000 0 1 001 Flag byte 1077 h k n 1078 04 piv 1079 636c69656e74 kid 1081 0xFF Payload marker 1082 Payload: 1083 0xa2c54fe1b434297b62 (9 bytes) 1085 Figure 16: Protected and Inner SCHC Compressed GET Request 1087 Protected message: 1088 ================== 1089 0x6144000182d008ff10c6d7c26cc1e9aef3f2461e0c29 1090 (22 bytes) 1092 Header: 1093 0x6144 1094 01 Ver 1095 10 ACK 1096 0001 TKL 1097 01000100 Successful Response Code 68 "2.04 Changed" 1099 0x0001 = mid 1100 0x82 = token 1102 Options: 1103 0xd008 (2 bytes) 1104 Option 21: OBJECT_SECURITY 1105 Value = b'' 1107 0xFF Payload marker 1108 Payload: 1109 0x10c6d7c26cc1e9aef3f2461e0c29 (14 bytes) 1111 Figure 17: Protected and Inner SCHC Compressed CONTENT Response 1113 For the flag bits, some SCHC compression methods are useful, 1114 depending on the Application. The most straightforward alternative 1115 is to provide a fixed value for the flags, combining MO "equal" and 1116 CDA "not-sent." This SCHC definition saves most bits but could 1117 prevent flexibility. Otherwise, SCHC could use a "match-mapping" MO 1118 to choose from several configurations for the exchange. If not, the 1119 SCHC description may use an "MSB" MO to mask off the three hard-coded 1120 most significant bits. 1122 Note that fixing a flag bit will limit CoAP Options choice that can 1123 be used in the exchange since their values are dependent on specific 1124 options. 1126 The piv field lends itself to having some bits masked off with "MSB" 1127 MO and "LSB" CDA. This SCHC description could be useful in 1128 applications where the message frequency is low such as LPWAN 1129 technologies. Note that compressing the sequence numbers may reduce 1130 the maximum number of sequence numbers that can be used in an 1131 exchange. Once the sequence number exceeds the maximum value, the 1132 OSCORE keys need to be re-established. 1134 The size s included in the kid context field MAY be masked off with 1135 "LSB" CDA. The rest of the field could have additional bits masked 1136 off or have the whole field fixed with MO "equal" and CDA "not-sent." 1137 The same holds for the kid field. 1139 Figure 18 shows a possible set of Outer Rules to compress the Outer 1140 Header. 1142 RuleID 0 1143 +------------------+--+--+--+--------------+-------+--------++------+ 1144 | Field |FL|FP|DI| Target | MO | CDA || Sent | 1145 | | | | | Value | | ||[bits]| 1146 +------------------+--+--+--+--------------+-------+--------++------+ 1147 |CoAP version | 2| 1|bi| 01 |equal |not-sent|| | 1148 |CoAP Type | 2| 1|up| 0 |equal |not-sent|| | 1149 |CoAP Type | 2| 1|dw| 2 |equal |not-sent|| | 1150 |CoAP TKL | 4| 1|bi| 1 |equal |not-sent|| | 1151 |CoAP Code | 8| 1|up| 2 |equal |not-sent|| | 1152 |CoAP Code | 8| 1|dw| 68 |equal |not-sent|| | 1153 |CoAP MID |16| 1|bi| 0000 |MSB(12)|LSB ||MMMM | 1154 |CoAP Token |tkl 1|bi| 0x80 |MSB(5) |LSB ||TTT | 1155 |CoAP OSCORE_flags | 8| 1|up| 0x09 |equal |not-sent|| | 1156 |CoAP OSCORE_piv |var 1|up| 0x00 |MSB(4) |LSB ||PPPP | 1157 |COAP OSCORE_kid |var 1|up|0x636c69656e70|MSB(52)|LSB ||KKKK | 1158 |COAP OSCORE_kidctx|var 1|bi| b'' |equal |not-sent|| | 1159 |CoAP OSCORE_flags | 8| 1|dw| b'' |equal |not-sent|| | 1160 |CoAP OSCORE_piv |var 1|dw| b'' |equal |not-sent|| | 1161 |CoAP OSCORE_kid |var 1|dw| b'' |equal |not-sent|| | 1162 +------------------+--+--+--+--------------+-------+--------++------+ 1164 Figure 18: Outer SCHC Rules 1166 The Outer Rule of Figure 18 is applied to the example GET Request and 1167 CONTENT Response. Figure 19 and Figure 20 show the resulting 1168 messages. 1170 Compressed message: 1171 ================== 1172 0x001489458a9fc3686852f6c4 (12 bytes) 1173 0x00 RuleID 1174 1489 Compression Residue 1175 458a9fc3686852f6c4 Padded payload 1177 Compression Residue: 1178 0b 0001 010 0100 0100 (15 bits -> 2 bytes with padding) 1179 mid tkn piv kid 1181 Payload 1182 0xa2c54fe1b434297b62 (9 bytes) 1184 Compressed message length: 12 bytes 1186 Figure 19: SCHC-OSCORE Compressed GET Request 1188 Compressed message: 1189 ================== 1190 0x0014218daf84d983d35de7e48c3c1852 (16 bytes) 1191 0x00 RuleID 1192 14 Compression Residue 1193 218daf84d983d35de7e48c3c1852 Padded payload 1194 Compression Residue: 1195 0b0001 010 (7 bits -> 1 byte with padding) 1196 mid tkn 1198 Payload 1199 0x10c6d7c26cc1e9aef3f2461e0c29 (14 bytes) 1201 Compressed msg length: 16 bytes 1203 Figure 20: SCHC-OSCORE Compressed CONTENT Response 1205 In contrast, comparing these results with what would be obtained by 1206 SCHC compressing the original CoAP messages without protecting them 1207 with OSCORE is done by compressing the CoAP messages according to the 1208 SCHC Rules in Figure 21. 1210 RuleID 1 1211 +---------------+--+--+--+-----------+---------+-----------++-------+ 1212 | Field |FL|FP|DI| Target | MO | CDA || Sent | 1213 | | | | | Value | | || [bits]| 1214 +---------------+--+--+--+-----------+---------+-----------++-------+ 1215 |CoAP version | 2| 1|bi| 01 |equal |not-sent || | 1216 |CoAP Type | 2| 1|up| 0 |equal |not-sent || | 1217 |CoAP Type | 2| 1|dw| 2 |equal |not-sent || | 1218 |CoAP TKL | 4| 1|bi| 1 |equal |not-sent || | 1219 |CoAP Code | 8| 1|up| 2 |equal |not-sent || | 1220 |CoAP Code | 8| 1|dw| [69,132] |match- |mapping- || | 1221 | | | | | |mapping |sent ||C | 1222 |CoAP MID |16| 1|bi| 0000 |MSB(12) |LSB ||MMMM | 1223 |CoAP Token |tkl 1|bi| 0x80 |MSB(5) |LSB ||TTT | 1224 |CoAP Uri-Path | | 1|up|temperature|equal |not-sent || | 1225 +---------------+--+--+--+-----------+---------+-----------++-------+ 1227 Figure 21: SCHC-CoAP Rules (No OSCORE) 1229 Figure 21 Rule yields the SCHC compression results in Figure 22 for 1230 request, and Figure 23 for the response. 1232 Compressed message: 1233 ================== 1234 0x0114 1235 0x01 = RuleID 1237 Compression Residue: 1238 0b00010100 (1 byte) 1240 Compressed msg length: 2 1242 Figure 22: CoAP GET Compressed without OSCORE 1244 Compressed message: 1245 ================== 1246 0x010a32332043 1247 0x01 = RuleID 1249 Compression Residue: 1250 0b00001010 (1 byte) 1252 Payload 1253 0x32332043 1255 Compressed msg length: 6 1257 Figure 23: CoAP CONTENT Compressed without OSCORE 1259 As can be seen, the difference between applying SCHC + OSCORE as 1260 compared to regular SCHC + COAP is about 10 bytes. 1262 8. IANA Considerations 1264 This document has no request to IANA. 1266 9. Security considerations 1268 The use of SCHC header compression for CoAP header fields only 1269 affects the representation of the header information. SCHC header 1270 compression itself does not increase or decrease the overall level of 1271 security of the communication. When the connection does not use a 1272 security protocol (such as OSCORE, DTLS, etc.), it is necessary to 1273 use a layer-two security mechanism to protect the SCHC messages. 1275 If LPWAN is the layer-two technology, the SCHC security 1276 considerations of [RFC8724] continue to apply. When using another 1277 layer-two protocol, use of a cryptographic integrity-protection 1278 mechanisms to protect the SCHC headers is REQUIRED. Such 1279 cryptographic integrity protection is necessary in order to continue 1280 to provide the properties that [RFC8724] relies upon. 1282 When SCHC is used with OSCORE, the security considerations of 1283 [RFC8613] continue to apply. 1285 When SCHC is used with the OSCORE outer headers, the Initialization 1286 Vector (IV) size in the Compression Residue must be carefully 1287 selected. There is a tradeoff between compression efficiency (with a 1288 longer "MSB" MO prefix) and the frequency at which the Device must 1289 renew its key material (in order to prevent the IV from expanding to 1290 an uncompressable value). The key renewal operation itself requires 1291 several message exchanges and requires energy-intensive computation, 1292 but the optimal tradeoff will depend on the specifics of the device 1293 and expected usage patterns. 1295 If an attacker can introduce a corrupted SCHC-compressed packet onto 1296 a link, DoS attacks are possible by causing excessive resource 1297 consumption at the decompressor. However, an attacker able to inject 1298 packets at the link layer is also capable of other, potentially more 1299 damaging, attacks. 1301 SCHC compression emits variable-length Compression Residues for some 1302 CoAP fields. In the compressed header representation, the length 1303 field that is sent is not the length of the original header field but 1304 rather the length of the Compression Residue that is being 1305 transmitted. If a corrupted packet arrives at the decompressor with 1306 a longer or shorter length than the original compressed 1307 representation possessed, the SCHC decompression procedures will 1308 detect an error and drop the packet. 1310 SCHC header compression rules MUST remain tightly coupled between 1311 compressor and decompressor. If the compression rules get out of 1312 sync, a Compression Residue might be decompressed differently at the 1313 receiver than the initial message submitted to compression 1314 procedures. Accordingly, any time the context Rules are updated on 1315 an OSCORE endpoint, that endpoint MUST trigger OSCORE key re- 1316 establishment. Similar procedures may be appropriate to signal Rule 1317 udpates when other message-protection mechanisms are in use. 1319 10. Acknowledgements 1321 The authors would like to thank (in alphabetic order): Christian 1322 Amsuss, Dominique Barthel, Carsten Bormann, Theresa Enghardt, Thomas 1323 Fossati, Klaus Hartke, Benjamin Kaduk, Francesca Palombini, Alexander 1324 Pelov, Goran Selander and Eric Vyncke. 1326 11. Normative References 1328 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 1329 Requirement Levels", BCP 14, RFC 2119, 1330 DOI 10.17487/RFC2119, March 1997, 1331 . 1333 [RFC5116] McGrew, D., "An Interface and Algorithms for Authenticated 1334 Encryption", RFC 5116, DOI 10.17487/RFC5116, January 2008, 1335 . 1337 [RFC7252] Shelby, Z., Hartke, K., and C. Bormann, "The Constrained 1338 Application Protocol (CoAP)", RFC 7252, 1339 DOI 10.17487/RFC7252, June 2014, 1340 . 1342 [RFC7641] Hartke, K., "Observing Resources in the Constrained 1343 Application Protocol (CoAP)", RFC 7641, 1344 DOI 10.17487/RFC7641, September 2015, 1345 . 1347 [RFC7959] Bormann, C. and Z. Shelby, Ed., "Block-Wise Transfers in 1348 the Constrained Application Protocol (CoAP)", RFC 7959, 1349 DOI 10.17487/RFC7959, August 2016, 1350 . 1352 [RFC7967] Bhattacharyya, A., Bandyopadhyay, S., Pal, A., and T. 1353 Bose, "Constrained Application Protocol (CoAP) Option for 1354 No Server Response", RFC 7967, DOI 10.17487/RFC7967, 1355 August 2016, . 1357 [RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC 1358 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, 1359 May 2017, . 1361 [RFC8613] Selander, G., Mattsson, J., Palombini, F., and L. Seitz, 1362 "Object Security for Constrained RESTful Environments 1363 (OSCORE)", RFC 8613, DOI 10.17487/RFC8613, July 2019, 1364 . 1366 [RFC8724] Minaburo, A., Toutain, L., Gomez, C., Barthel, D., and JC. 1367 Zuniga, "SCHC: Generic Framework for Static Context Header 1368 Compression and Fragmentation", RFC 8724, 1369 DOI 10.17487/RFC8724, April 2020, 1370 . 1372 Authors' Addresses 1374 Ana Minaburo 1375 Acklio 1376 1137A avenue des Champs Blancs 1377 35510 Cesson-Sevigne Cedex 1378 France 1380 Email: ana@ackl.io 1381 Laurent Toutain 1382 Institut MINES TELECOM; IMT Atlantique 1383 2 rue de la Chataigneraie 1384 CS 17607 1385 35576 Cesson-Sevigne Cedex 1386 France 1388 Email: Laurent.Toutain@imt-atlantique.fr 1390 Ricardo Andreasen 1391 Universidad de Buenos Aires 1392 Av. Paseo Colon 850 1393 C1063ACV Ciudad Autonoma de Buenos Aires 1394 Argentina 1396 Email: randreasen@fi.uba.ar