idnits 2.17.1 draft-ietf-lpwan-coap-static-context-hc-15.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 1135 has weird spacing: '...tkn piv kid...' == Line 1152 has weird spacing: '... mid tkn...' == The document seems to lack the recommended RFC 2119 boilerplate, even if it appears to use RFC 2119 keywords -- however, there's a paragraph with a matching beginning. Boilerplate error? (The document does seem to have the reference to RFC 2119 which the ID-Checklist requires). -- The document date (July 03, 2020) is 1386 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 1176 -- Looks like a reference, but probably isn't: '132' on line 1176 Summary: 0 errors (**), 0 flaws (~~), 4 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: January 4, 2021 Institut MINES TELECOM; IMT Atlantique 6 R. Andreasen 7 Universidad de Buenos Aires 8 July 03, 2020 10 LPWAN Static Context Header Compression (SCHC) for CoAP 11 draft-ietf-lpwan-coap-static-context-hc-15 13 Abstract 15 This draft defines the way Static Context Header Compression (SCHC) 16 header compression can be applied to the Constrained Application 17 Protocol (CoAP). SCHC is a header compression mechanism adapted for 18 constrained devices. SCHC uses a static description of the header to 19 reduce the redundancy and the size of the information in the header. 20 While [rfc8724] describes the SCHC compression and fragmentation 21 framework, and its application for IPv6/UDP headers, this document 22 applies the use of SCHC for CoAP headers. The CoAP header structure 23 differs from IPv6 and UDP since CoAP uses a flexible header with a 24 variable number of options, themselves of variable length. The CoAP 25 protocol messages format is asymmetric: the request messages have a 26 header format different from the one in the response messages. This 27 specification gives guidance on how to apply SCHC to flexible headers 28 and how to leverage the asymmetry for more efficient compression 29 Rules. 31 Status of This Memo 33 This Internet-Draft is submitted in full conformance with the 34 provisions of BCP 78 and BCP 79. 36 Internet-Drafts are working documents of the Internet Engineering 37 Task Force (IETF). Note that other groups may also distribute 38 working documents as Internet-Drafts. The list of current Internet- 39 Drafts is at https://datatracker.ietf.org/drafts/current/. 41 Internet-Drafts are draft documents valid for a maximum of six months 42 and may be updated, replaced, or obsoleted by other documents at any 43 time. It is inappropriate to use Internet-Drafts as reference 44 material or to cite them other than as "work in progress." 46 This Internet-Draft will expire on January 4, 2021. 48 Copyright Notice 50 Copyright (c) 2020 IETF Trust and the persons identified as the 51 document authors. All rights reserved. 53 This document is subject to BCP 78 and the IETF Trust's Legal 54 Provisions Relating to IETF Documents 55 (https://trustee.ietf.org/license-info) in effect on the date of 56 publication of this document. Please review these documents 57 carefully, as they describe your rights and restrictions with respect 58 to this document. Code Components extracted from this document must 59 include Simplified BSD License text as described in Section 4.e of 60 the Trust Legal Provisions and are provided without warranty as 61 described in the Simplified BSD License. 63 Table of Contents 65 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3 66 1.1. Terminology . . . . . . . . . . . . . . . . . . . . . . . 4 67 2. Applying SCHC to CoAP headers . . . . . . . . . . . . . . . . 4 68 3. CoAP Headers compressed with SCHC . . . . . . . . . . . . . . 6 69 3.1. Differences between CoAP and UDP/IP Compression . . . . . 7 70 4. Compression of CoAP header fields . . . . . . . . . . . . . . 8 71 4.1. CoAP version field . . . . . . . . . . . . . . . . . . . 8 72 4.2. CoAP type field . . . . . . . . . . . . . . . . . . . . . 8 73 4.3. CoAP code field . . . . . . . . . . . . . . . . . . . . . 8 74 4.4. CoAP Message ID field . . . . . . . . . . . . . . . . . . 9 75 4.5. CoAP Token fields . . . . . . . . . . . . . . . . . . . . 9 76 5. CoAP options . . . . . . . . . . . . . . . . . . . . . . . . 9 77 5.1. CoAP Content and Accept options. . . . . . . . . . . . . 10 78 5.2. CoAP option Max-Age, Uri-Host and Uri-Port fields . . . . 10 79 5.3. CoAP option Uri-Path and Uri-Query fields . . . . . . . . 10 80 5.3.1. Variable length Uri-Path and Uri-Query . . . . . . . 11 81 5.3.2. Variable number of path or query elements . . . . . . 11 82 5.4. CoAP option Size1, Size2, Proxy-URI and Proxy-Scheme 83 fields . . . . . . . . . . . . . . . . . . . . . . . . . 11 84 5.5. CoAP option ETag, If-Match, If-None-Match, Location-Path 85 and Location-Query fields . . . . . . . . . . . . . . . . 12 86 6. SCHC compression of CoAP extension RFCs . . . . . . . . . . . 12 87 6.1. Block . . . . . . . . . . . . . . . . . . . . . . . . . . 12 88 6.2. Observe . . . . . . . . . . . . . . . . . . . . . . . . . 12 89 6.3. No-Response . . . . . . . . . . . . . . . . . . . . . . . 12 90 6.4. OSCORE . . . . . . . . . . . . . . . . . . . . . . . . . 12 91 7. Examples of CoAP header compression . . . . . . . . . . . . . 14 92 7.1. Mandatory header with CON message . . . . . . . . . . . . 14 93 7.2. OSCORE Compression . . . . . . . . . . . . . . . . . . . 15 94 7.3. Example OSCORE Compression . . . . . . . . . . . . . . . 18 95 8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 28 96 9. Security considerations . . . . . . . . . . . . . . . . . . . 28 97 10. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 29 98 11. Normative References . . . . . . . . . . . . . . . . . . . . 29 99 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 30 101 1. Introduction 103 CoAP [rfc7252] is designed to easily interop with HTTP (Hypertext 104 Transfer Protocol) and is optimized for REST-based (Representational 105 state transfer) services. Although CoAP was designed for constrained 106 devices, the size of a CoAP header still is too large for the 107 constraints of LPWAN (Low Power Wide Area Networks) and some 108 compression is needed to reduce the header size. 110 The [rfc8724] defines SCHC, a header compression mechanism for LPWAN 111 network based on a static context. Section 5 of the [rfc8724] 112 explains the architecture where compression and decompression are 113 done. The context is known by both ends before transmission. The 114 way the context is configured, provisioned or exchanged is out of the 115 scope of this document. 117 CoAP is an End-to-End protocol at the application level, so CoAP 118 compression requires to install common Rules between two hosts and IP 119 Routing may be needed to allow End-to-End communication. Therefore, 120 SCHC compression may apply at two different levels, one to compress 121 IP and UDP as described in [rfc8724] in the LPWAN network and another 122 at the application level. These two compressions may be independent. 123 The Compression Rules can be set up by two independent entities and 124 are out of the scope of this document. In both cases, SCHC mechanism 125 remains the same. 127 SCHC compresses and decompresses headers based on shared contexts 128 between devices. Each context consists of multiple Rules. Each Rule 129 can match header fields and specific values or ranges of values. If 130 a Rule matches, the matched header fields are substituted by the 131 RuleID and optionally some residual bits. Thus, different Rules may 132 correspond to different types of packets that a device expects to 133 send or receive. 135 A Rule describes the complete header of the packet with an ordered 136 list of fields descriptions, see section 7 of [rfc8724], thereby each 137 description contains the field ID (FID), its length (FL) and its 138 position (FP), a direction indicator (DI) (upstream, downstream and 139 bidirectional) and some associated Target Values (TV). 141 A Matching Operator (MO) is associated to each header field 142 description. The Rule is selected if all the MOs fit the TVs for all 143 fields of the incoming header. 145 In that case, a Compression/Decompression Action (CDA) associated to 146 each field defines how the compressed and the decompressed values are 147 computed. Compression mainly results in one of 4 actions: 149 o send the field value, 151 o send nothing, 153 o send some least significant bits of the field or 155 o send an index. 157 After applying the compression there may be some bits to be sent, 158 these values are called Compression Residues. 160 SCHC is a general mechanism that can be applied to different 161 protocols, the exact Rules to be used depend on the protocol and the 162 application. The section 10 of the [rfc8724] describes the 163 compression scheme for IPv6 and UDP headers. This document targets 164 the CoAP header compression using SCHC. 166 1.1. Terminology 168 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 169 "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and 170 "OPTIONAL" in this document are to be interpreted as described in BCP 171 14 [RFC2119][rfc8174] when, and only when, they appear in all 172 capitals, as shown here. 174 2. Applying SCHC to CoAP headers 176 The SCHC Compression Rules can be applied to CoAP headers. SCHC 177 Compression of the CoAP header MAY be done in conjunction with the 178 lower layers (IPv6/UDP) or independently. The SCHC adaptation layers 179 as described in Section 5 of [rfc8724] and may be used as shown in 180 Figure 1, Figure 2 and Figure 3. 182 In the first example Figure 1, a Rule compresses the complete header 183 stack from IPv6 to CoAP. In this case, SCHC C/D (Static Context 184 Header Compression Compressor/Decompressor) is performed at the 185 Sender and at the Receiver. The host communicating with the device 186 do not implement SCHC C/D. 188 (device) (NGW) (internet) (App) 190 +--------+ +--------+ 191 | CoAP | | CoAP | 192 +--------+ +--------+ 193 | UDP | | UDP | 194 +--------+ +----------------+ +--------+ 195 | IPv6 | | IPv6 | | IPv6 | 196 +--------+ +--------+-------+ +--------+ 197 | SCHC | | SCHC | | | | 198 +--------+ +--------+ + + + 199 | LPWAN | | LPWAN | | | | 200 +--------+ +--------+-------+ +--------+ 201 ((((((())))))) ----- ------ ------ ----- 203 Figure 1: Compression/decompression at the LPWAN bondary 205 In the second example, Figure 2, the SCHC compression is applied in 206 the CoAP layer, compressing the CoAP header independently of the 207 other layers. The RuleID and the Compression Residue are encrypted 208 using a mechanism such as DTLS. Only the other end can decipher the 209 information. If needed, layers below use SCHC to compress the header 210 as defined in [rfc8724] document. This use case realizes an End-to- 211 End context initialization between the sender and the receiver and is 212 out-of-scope of this document. 214 (device) (NGW) (internet) (App) 216 +--------+ +--------+ 217 | CoAP | | CoAP | 218 +--------+ +--------+ 219 | SCHC | | SCHC | 220 +--------+ +--------+ 221 | DTLS | | DTLS | 222 +--------+ +--------+ 223 . udp . . udp . 224 .......... .................. .......... 225 . ipv6 . . ipv6 . . ipv6 . 226 .......... .................. .......... 227 . schc . . schc . . . . 228 .......... .......... . . . 229 . lpwan . . lpwan . . . . 230 .......... .................. .......... 231 ((((((())))))) ----- ------ ------ ----- 233 Figure 2: Standalone CoAP ene-to-end compression/decompression 235 In the third example, Figure 3 the Object Security for Constrained 236 RESTful Environments (OSCORE) [rfc8613] is used. In this case, two 237 rulesets are used to compress the CoAP message. A first ruleset 238 focused on the inner header and is applied end to end by both ends. 239 A second ruleset compresses the outer header and the layers below and 240 is done between the Sender and the Receiver. 242 (device) (NGW) (internet) (App) 244 +--------+ +--------+ 245 | CoAP | | CoAP | 246 | inner | | inner | 247 +--------+ +--------+ 248 | SCHC | | SCHC | 249 +--------+ +--------+ 250 | CoAP | | CoAP | 251 | outer | | outer | 252 +--------+ +--------+ 253 . udp . . udp . 254 .......... .................. .......... 255 . ipv6 . . ipv6 . . ipv6 . 256 .......... .................. .......... 257 . schc . . schc . . . . 258 .......... .......... . . . 259 . lpwan . . lpwan . . . . 260 .......... .................. .......... 261 ((((((())))))) ----- ------ ------ ----- 263 Figure 3: OSCORE compression/decompression. 265 In case of 2 rule-sets, as shown in Figure 2 and Figure 3, they may 266 come from different provisioning domains, and that they do not 267 include the cryptography part that is done in between the two SCHC 268 activities. This document focuses on CoAP compression represented in 269 the dashed boxes in the previous figures. 271 3. CoAP Headers compressed with SCHC 273 The use of SCHC over the CoAP header uses the same description and 274 compression/decompression techniques as the one for IP and UDP 275 explained in the [rfc8724]. For CoAP, SCHC Rules description uses 276 the direction information to optimize the compression by reducing the 277 number of Rules needed to compress headers. The field description 278 MAY define both request/response headers and target values in the 279 same Rule, using the DI (direction indicator) to make the difference. 280 As for other protocols, when the compressor does not find a correct 281 Rule to compress the header, the packet MUST be sent uncompressed 282 using the RuleID dedicated to this purpose, and the Compression 283 Residue is the complete header of the packet. See section 6 of 284 [rfc8724]. 286 3.1. Differences between CoAP and UDP/IP Compression 288 CoAP compression differs from IPv6 and UDP compression on the 289 following aspects: 291 o The CoAP protocol is asymmetric, the headers are different for a 292 request or a response. For example, the URI-path option is 293 mandatory in the request, and it is not present in the response, a 294 request may contain an Accept option, and the response may include 295 a Content option. In comparison, IPv6 and UDP returning path swap 296 the value of some fields in the header. 297 But all the directions have the same fields (e.g., source and 298 destination addresses fields). 300 The [rfc8724] defines the use of a Direction Indicator (DI) in the 301 Field Description, which allows a single Rule to process message 302 headers differently depending on the direction. 304 o Even when a field is "symmetric" (i.e., found in both directions), 305 the values carried in each direction are different. 306 The compression may use a matching list in the TV to limit the 307 range of expected values in a particular direction and therefore 308 reduces the size of the Compression Residue. Through the 309 Direction Indicator (DI), a field description in the Rules splits 310 the possible field value into two parts, one for each direction. 311 For instance, if a client sends only CON requests, the type can be 312 elided by compression, and the answer may use one single bit to 313 carry either the ACK or RST type. The field Code have as well the 314 same behavior, the 0.0X code format value in the request and Y.ZZ 315 code format in the response. 317 o Headers in IPv6 and UDP have a fixed size. The size is not sent 318 as part of the Compression Residue, but is defined in the Rule. 319 Some CoAP header fields have variable lengths, so the length is 320 also specified in the Field Description. For example, the Token 321 size may vary from 0 to 8 bytes. And the CoAP options have a 322 variable length since they use the Type-Length-Value encoding 323 format, as URI-path or URI-query. 325 Section 7.5.2 from [rfc8724] offers the possibility to define a 326 function for the Field length in the Field Description to have 327 knowledge of the length before compression. When doing SCHC 328 compression of a variable-length field, 329 if the field size is not known, the Field Length in the Rule is 330 set as variable and the size is sent with the Compression Residue. 332 o A field can appear several time in the CoAP headers. This is 333 typical for elements of a URI (path or queries). The SCHC 334 specification [rfc8724] allows a Field ID to appear several times 335 in the Rule, and uses the Field Position (FP) to identify the 336 correct instance, and thereby removing the ambiguity of the 337 matching operation. 339 o Field sizes defined in the CoAP protocol can be too large 340 regarding LPWAN traffic constraints. This is particularly true 341 for the Message ID field and the Token field. SCHC uses different 342 Matching operators (MO) to perform the compression, see section 343 7.4 of [rfc8724]. In this case the Most Significant Bits (MSB) MO 344 can be applied to reduce the information carried on LPWANs. 346 4. Compression of CoAP header fields 348 This section discusses the compression of the different CoAP header 349 fields. The CoAP compression with SCHC follows the Section 7.1 of 350 [rfc8724]. 352 4.1. CoAP version field 354 CoAP version is bidirectional and MUST be elided during the SCHC 355 compression, since it always contains the same value. In the future, 356 if new versions of CoAP are defined, new Rules will be needed to 357 avoid ambiguities between versions. 359 4.2. CoAP type field 361 The CoAP Protocol [rfc7252] has four type of messages: two request 362 (CON, NON); one response (ACK) and one empty message (RST). 364 The field SHOULD be elided if for instance a client is sending only 365 NON or only CON messages. For the RST message a dedicated Rule may 366 be needed. For other usages a mapping list can be used. 368 4.3. CoAP code field 370 The code field indicates the Request Method used in CoAP, a IANA 371 registry [rfc7252]. The compression of the CoAP code field follows 372 the same principle as that of the CoAP type field. If the device 373 plays a specific role, the set of code values can be split in two 374 parts, the request codes with the 0 class and the response values. 376 If the device only implements a CoAP client, the request code can be 377 reduced to the set of requests the client is able to process. 379 A mapping list can be used for known values. For other values the 380 field cannot be compressed an the value needs to be sent in the 381 Compression Residue. 383 4.4. CoAP Message ID field 385 The Message ID field can be compressed with the MSB(x) MO and the 386 Least Significant Bits (LSB) CDA, see section 7.4 of [rfc8724]. 388 4.5. CoAP Token fields 390 Token is defined through two CoAP fields, Token Length in the 391 mandatory header and Token Value directly following the mandatory 392 CoAP header. 394 Token Length is processed as any protocol field. If the value does 395 not change, the size can be stored in the TV and elided during the 396 transmission. Otherwise, it will have to be sent in the Compression 397 Residue. 399 Token Value MUST NOT be sent as a variable length residue to avoid 400 ambiguity with Token Length. Therefore, Token Length value MUST be 401 used to define the size of the Compression Residue. A specific 402 function designated as "TKL" MUST be used in the Rule. During the 403 decompression, this function returns the value contained in the Token 404 Length field. 406 5. CoAP options 408 CoAP defines options that are placed after the based header in Option 409 Numbers order, see [rfc7252]. Each Option instance in a message uses 410 the format Delta-Type (D-T), Length (L), Value (V). When applying 411 SCHC compression to the Option, the D-T, L, and V format serves to 412 make the Rule description of the Option. The SCHC compression builds 413 the description of the Option by using in the Field ID the Option 414 Number built from D-T; in TV, the Option Value; and the Option Length 415 uses section 7.4 of RFC8724. When the Option Length has a wellknown 416 size it can be stored in the Rule. Therefore, SCHC compression does 417 not send it. Otherwise, SCHC Compression carries the length of the 418 Compression Residue in addition to the Compression Residue value. 420 CoAP request and response do not include the same options. So 421 Compression Rules may reflect these assymetry by tagging the 422 direction indicator. 424 Note that length coding differs between CoAP options and SCHC 425 variable size Compression Residue. 427 The following sections present how SCHC compresses some specific CoAP 428 Options. 430 5.1. CoAP Content and Accept options. 432 If a single value is expected by the client, it can be stored in the 433 TV and elided during the transmission. Otherwise, if several 434 possible values are expected by the client, a matching-list SHOULD be 435 used to limit the size of the Compression Residue. Otherwise, the 436 value has to be sent as a Compression Residue (fixed or variable 437 length). 439 5.2. CoAP option Max-Age, Uri-Host and Uri-Port fields 441 If the duration is known by both ends, the value can be elided. 443 A matching list can be used if some well-known values are defined. 445 Otherwise these options can be sent as a Compression Residue (fixed 446 or variable length). 448 5.3. CoAP option Uri-Path and Uri-Query fields 450 Uri-Path and Uri-Query elements are a repeatable options, the Field 451 Position (FP) gives the position in the path. 453 A Mapping list can be used to reduce the size of variable Paths or 454 Queries. In that case, to optimize the compression, several elements 455 can be regrouped into a single entry. Numbering of elements do not 456 change, MO comparison is set with the first element of the matching. 458 +-------------+---+--+--+--------+---------+-------------+ 459 | Field |FL |FP|DI| Target | Match | CDA | 460 | | | | | Value | Opera. | | 461 +-------------+---+--+--+--------+---------+-------------+ 462 |URI-Path | | 1|up|["/a/b",|equal |not-sent | 463 | | | | |"/c/d"] | | | 464 |URI-Path |var| 3|up| |ignore |value-sent | 465 +-------------+---+--+--+--------+---------+-------------+ 467 Figure 4: complex path example 469 In Figure 4 a single bit residue can be used to code one of the 2 470 paths. If regrouping were not allowed, a 2 bits residue would be 471 needed. The third path element is sent as a variable size residue. 473 5.3.1. Variable length Uri-Path and Uri-Query 475 When the length is not known at the Rule creation, the Field Length 476 MUST be set to variable, and the unit is set to bytes. 478 The MSB MO can be applied to a Uri-Path or Uri-Query element. Since 479 MSB value is given in bit, the size MUST always be a multiple of 8 480 bits. 482 The length sent at the beginning of a variable length residue 483 indicates the size of the LSB in bytes. 485 For instance for a CORECONF path /c/X6?k="eth0" the Rule can be set 486 to: 488 +-------------+---+--+--+--------+---------+-------------+ 489 | Field |FL |FP|DI| Target | Match | CDA | 490 | | | | | Value | Opera. | | 491 +-------------+---+--+--+--------+---------+-------------+ 492 |URI-Path | 8| 1|up|"c" |equal |not-sent | 493 |URI-Path |var| 2|up| |ignore |value-sent | 494 |URI-Query |var| 1|up|"k=" |MSB(16) |LSB | 495 +-------------+---+--+--+--------+---------+-------------+ 497 Figure 5: CORECONF URI compression 499 Figure 5 shows the parsing and the compression of the URI, where c is 500 not sent. The second element is sent with the length (i.e. 0x2 X 6) 501 followed by the query option (i.e. 0x05 "eth0"). 503 5.3.2. Variable number of path or query elements 505 The number of Uri-path or Uri-Query elements in a Rule is fixed at 506 the Rule creation time. If the number varies, several Rules SHOULD 507 be created to cover all the possibilities. Another possibility is to 508 define the length of Uri-Path to variable and send a Compression 509 Residue with a length of 0 to indicate that this Uri-Path is empty. 510 This adds 4 bits to the variable Residue size. See section 7.5.2 511 [rfc8724] 513 5.4. CoAP option Size1, Size2, Proxy-URI and Proxy-Scheme fields 515 If the field value has to be sent, TV is not set, MO is set to 516 "ignore" and CDA is set to "value-sent". A mapping MAY also be used. 518 Otherwise, the TV is set to the value, MO is set to "equal" and CDA 519 is set to "not-sent". 521 5.5. CoAP option ETag, If-Match, If-None-Match, Location-Path and 522 Location-Query fields 524 These fields values cannot be stored in a Rule entry. They MUST 525 always be sent with the Compression Residues. 527 6. SCHC compression of CoAP extension RFCs 529 6.1. Block 531 Block [rfc7959] allows a fragmentation at the CoAP level. SCHC also 532 includes a fragmentation protocol. They can be both used. If a 533 block option is used, its content MUST be sent as a Compression 534 Residue. 536 6.2. Observe 538 The [rfc7641] defines the Observe option. The TV is not set, MO is 539 set to "ignore" and the CDA is set to "value-sent". SCHC does not 540 limit the maximum size for this option (3 bytes). To reduce the 541 transmission size, either the device implementation MAY limit the 542 delta between two consecutive values, or a proxy can modify the 543 increment. 545 Since an RST message may be sent to inform a server that the client 546 does not require Observe response, a Rule MUST allow the transmission 547 of this message. 549 6.3. No-Response 551 The [rfc7967] defines a No-Response option limiting the responses 552 made by a server to a request. If the value is known by both ends, 553 then TV is set to this value, MO is set to "equal" and CDA is set to 554 "not-sent". 556 Otherwise, if the value is changing over time, TV is not set, MO is 557 set to "ignore" and CDA to "value-sent". A matching list can also be 558 used to reduce the size. 560 6.4. OSCORE 562 OSCORE [rfc8613] defines end-to-end protection for CoAP messages. 563 This section describes how SCHC Rules can be applied to compress 564 OSCORE-protected messages. 566 0 1 2 3 4 5 6 7 <--------- n bytes -------------> 567 +-+-+-+-+-+-+-+-+--------------------------------- 568 |0 0 0|h|k| n | Partial IV (if any) ... 569 +-+-+-+-+-+-+-+-+--------------------------------- 570 | | | 571 |<-- CoAP -->|<------ CoAP OSCORE_piv ------> | 572 OSCORE_flags 574 <- 1 byte -> <------ s bytes -----> 575 +------------+----------------------+-----------------------+ 576 | s (if any) | kid context (if any) | kid (if any) ... | 577 +------------+----------------------+-----------------------+ 578 | | | 579 | <------ CoAP OSCORE_kidctxt ----->|<-- CoAP OSCORE_kid -->| 581 Figure 6: OSCORE Option 583 The encoding of the OSCORE Option Value defined in Section 6.1 of 584 [rfc8613] is repeated in Figure 6. 586 The first byte specifies the content of the OSCORE options using 587 flags. The three most significant bits of this byte are reserved and 588 always set to 0. Bit h, when set, indicates the presence of the kid 589 context field in the option. Bit k, when set, indicates the presence 590 of a kid field. The three least significant bits n indicate the 591 length of the piv (Partial Initialization Vector) field in bytes. 592 When n = 0, no piv is present. 594 The flag byte is followed by the piv field, kid context field, and 595 kid field in this order, and if present, the length of the kid 596 context field is encoded in the first byte denoting by s the length 597 of the kid context in bytes. 599 This specification recommends identifying the OSCORE Option and the 600 fields it contains Conceptually, it discerns up to 4 distinct pieces 601 of information within the OSCORE option: the flag bits, the piv, the 602 kid context, and the kid. The SCHC Rule splits into four field 603 descriptions the OSCORE option to compress them: 605 o CoAP OSCORE_flags, 607 o CoAP OSCORE_piv, 609 o CoAP OSCORE_kidctxt, 611 o CoAP OSCORE_kid. 613 The OSCORE Option shows superimposed these four fields using the 614 format Figure 6, the CoAP OSCORE_kidctxt field includes the size bits 615 s. 617 7. Examples of CoAP header compression 619 7.1. Mandatory header with CON message 621 In this first scenario, the LPWAN Compressor at the Network Gateway 622 side receives from an Internet client a POST message, which is 623 immediately acknowledged by the Device. For this simple scenario, 624 the Rules are described Figure 7. 626 RuleID 1 627 +-------------+--+--+--+------+---------+-------------++------------+ 628 | Field |FL|FP|DI|Target| Match | CDA || Sent | 629 | | | | |Value | Opera. | || [bits] | 630 +-------------+--+--+--+------+---------+-------------++------------+ 631 |CoAP version | | |bi| 01 |equal |not-sent || | 632 |CoAP Type | | |dw| CON |equal |not-sent || | 633 |CoAP Type | | |up|[ACK, | | || | 634 | | | | | RST] |match-map|matching-sent|| T | 635 |CoAP TKL | | |bi| 0 |equal |not-sent || | 636 |CoAP Code | | |bi|[0.00,| | || | 637 | | | | | ... | | || | 638 | | | | | 5.05]|match-map|matching-sent|| CC CCC | 639 |CoAP MID | | |bi| 0000 |MSB(7 ) |LSB || M-ID| 640 |CoAP Uri-Path| | |dw| path |equal 1 |not-sent || | 641 +-------------+--+--+--+------+---------+-------------++------------+ 643 Figure 7: CoAP Context to compress header without token 645 The version and Token Length fields are elided. The 26 method and 646 response codes defined in [rfc7252] has been shrunk to 5 bits using a 647 matching list. Uri-Path contains a single element indicated in the 648 matching operator. 650 SCHC Compression reduces the header sending only the Type, a mapped 651 code and the least significant bits of Message ID (9 bits in the 652 example above). 654 Note that a request sent by a client located in an Application Server 655 to a server located in the device, may not be compressed through this 656 Rule since the MID will not start with 7 bits equal to 0. A CoAP 657 proxy, before the core SCHC C/D can rewrite the message ID to a value 658 matched by the Rule. 660 7.2. OSCORE Compression 662 OSCORE aims to solve the problem of end-to-end encryption for CoAP 663 messages. The goal, therefore, is to hide as much of the message as 664 possible while still enabling proxy operation. 666 Conceptually this is achieved by splitting the CoAP message into an 667 Inner Plaintext and Outer OSCORE Message. The Inner Plaintext 668 contains sensitive information which is not necessary for proxy 669 operation. This, in turn, is the part of the message which can be 670 encrypted until it reaches its end destination. The Outer Message 671 acts as a shell matching the format of a regular CoAP message, and 672 includes all Options and information needed for proxy operation and 673 caching. This decomposition is illustrated in Figure 8. 675 CoAP options are sorted into one of 3 classes, each granted a 676 specific type of protection by the protocol: 678 o Class E: Encrypted options moved to the Inner Plaintext, 680 o Class I: Integrity-protected options included in the AAD for the 681 encryption of the Plaintext but otherwise left untouched in the 682 Outer Message, 684 o Class U: Unprotected options left untouched in the Outer Message. 686 Additionally, the OSCORE Option is added as an Outer option, 687 signalling that the message is OSCORE protected. This option carries 688 the information necessary to retrieve the Security Context with which 689 the message was encrypted so that it may be correctly decrypted at 690 the other end-point. 692 Original CoAP Message 693 +-+-+---+-------+---------------+ 694 |v|t|tkl| code | Msg Id. | 695 +-+-+---+-------+---------------+....+ 696 | Token | 697 +-------------------------------.....+ 698 | Options (IEU) | 699 . . 700 . . 701 +------+-------------------+ 702 | 0xFF | 703 +------+------------------------+ 704 | | 705 | Payload | 706 | | 707 +-------------------------------+ 708 / \ 709 / \ 710 / \ 711 / \ 712 Outer Header v v Plaintext 713 +-+-+---+--------+---------------+ +-------+ 714 |v|t|tkl|new code| Msg Id. | | code | 715 +-+-+---+--------+---------------+....+ +-------+-----......+ 716 | Token | | Options (E) | 717 +--------------------------------.....+ +-------+------.....+ 718 | Options (IU) | | OxFF | 719 . . +-------+-----------+ 720 . OSCORE Option . | | 721 +------+-------------------+ | Payload | 722 | 0xFF | | | 723 +------+ +-------------------+ 725 Figure 8: A CoAP message is split into an OSCORE outer and plaintext 727 Figure 8 shows the message format for the OSCORE Message and 728 Plaintext. 730 In the Outer Header, the original message code is hidden and replaced 731 by a default dummy value. As seen in Sections 4.1.3.5 and 4.2 of the 732 [rfc8613], the message code is replaced by POST for requests and 733 Changed for responses when Observe is not used. If Observe is used, 734 the message code is replaced by FETCH for requests and Content for 735 responses. 737 The original message code is put into the first byte of the 738 Plaintext. Following the message code, the class E options comes and 739 if present the original message Payload is preceded by its payload 740 marker. 742 The Plaintext is now encrypted by an AEAD algorithm which integrity 743 protects Security Context parameters and eventually any class I 744 options from the Outer Header. Currently no CoAP options are marked 745 class I. The resulting Ciphertext becomes the new Payload of the 746 OSCORE message, as illustrated in Figure 9. 748 This Ciphertext is, as defined in RFC 5116, the concatenation of the 749 encrypted Plaintext and its authentication tag. Note that Inner 750 Compression only affects the Plaintext before encryption, thus we can 751 only aim to reduce this first, variable length component of the 752 Ciphertext. The authentication tag is fixed in length and considered 753 part of the cost of protection. 755 Outer Header 756 +-+-+---+--------+---------------+ 757 |v|t|tkl|new code| Msg Id. | 758 +-+-+---+--------+---------------+....+ 759 | Token | 760 +--------------------------------.....+ 761 | Options (IU) | 762 . . 763 . OSCORE Option . 764 +------+-------------------+ 765 | 0xFF | 766 +------+---------------------------+ 767 | | 768 | Ciphertext: Encrypted Inner | 769 | Header and Payload | 770 | + Authentication Tag | 771 | | 772 +----------------------------------+ 774 Figure 9: OSCORE message 776 The SCHC Compression scheme consists of compressing both the 777 Plaintext before encryption and the resulting OSCORE message after 778 encryption, see Figure 10. 780 This translates into a segmented process where SCHC compression is 781 applied independently in 2 stages, each with its corresponding set of 782 Rules, with the Inner SCHC Rules and the Outer SCHC Rules. This way 783 compression is applied to all fields of the original CoAP message. 785 Note that since the Inner part of the message can only be decrypted 786 by the corresponding end-point, this end-point will also have to 787 implement Inner SCHC Compression/Decompression. 789 Outer Message OSCORE Plaintext 790 +-+-+---+--------+---------------+ +-------+ 791 |v|t|tkl|new code| Msg Id. | | code | 792 +-+-+---+--------+---------------+....+ +-------+-----......+ 793 | Token | | Options (E) | 794 +--------------------------------.....+ +-------+------.....+ 795 | Options (IU) | | OxFF | 796 . . +-------+-----------+ 797 . OSCORE Option . | | 798 +------+-------------------+ | Payload | 799 | 0xFF | | | 800 +------+------------+ +-------------------+ 801 | Ciphertext |<---------\ | 802 | | | v 803 +-------------------+ | +-----------------+ 804 | | | Inner SCHC | 805 v | | Compression | 806 +-----------------+ | +-----------------+ 807 | Outer SCHC | | | 808 | Compression | | v 809 +-----------------+ | +-------+ 810 | | |RuleID | 811 v | +-------+--+ 812 +--------+ +------------+ | Residue | 813 |RuleID' | | Encryption | <--- +----------+--------+ 814 +--------+--+ +------------+ | | 815 | Residue' | | Payload | 816 +-----------+-------+ | | 817 | Ciphertext | +-------------------+ 818 | | 819 +-------------------+ 821 Figure 10: OSCORE Compression Diagram 823 7.3. Example OSCORE Compression 825 An example is given with a GET Request and its consequent Content 826 Response from a device-based CoAP client to a cloud-based CoAP 827 server. A possible set of Rules for the Inner and Outer SCHC 828 Compression is shown. A dump of the results and a contrast between 829 SCHC + OSCORE performance with SCHC + COAP performance is also 830 listed. This gives an approximation to the cost of security with 831 SCHC-OSCORE. 833 Our first example CoAP message is the GET Request in Figure 11 835 Original message: 836 ================= 837 0x4101000182bb74656d7065726174757265 839 Header: 840 0x4101 841 01 Ver 842 00 CON 843 0001 tkl 844 00000001 Request Code 1 "GET" 846 0x0001 = mid 847 0x82 = token 849 Options: 850 0xbb74656d7065726174757265 851 Option 11: URI_PATH 852 Value = temperature 854 Original msg length: 17 bytes. 856 Figure 11: CoAP GET Request 858 Its corresponding response is the CONTENT Response in Figure 12. 860 Original message: 861 ================= 862 0x6145000182ff32332043 864 Header: 865 0x6145 866 01 Ver 867 10 ACK 868 0001 tkl 869 01000101 Successful Response Code 69 "2.05 Content" 871 0x0001 = mid 872 0x82 = token 874 0xFF Payload marker 875 Payload: 876 0x32332043 878 Original msg length: 10 880 Figure 12: CoAP CONTENT Response 882 The SCHC Rules for the Inner Compression include all fields that are 883 already present in a regular CoAP message. The methods described in 884 Section 4 applies to these fields. As an example, see Figure 13. 886 RuleID 0 887 +---------------+--+--+-----------+-----------+-----------++------+ 888 | Field |FP|DI| Target | MO | CDA || Sent | 889 | | | | Value | | ||[bits]| 890 +---------------+--+--+-----------+-----------+-----------++------+ 891 |CoAP Code | |up| 1 | equal |not-sent || | 892 |CoAP Code | |dw|[69,132] | match-map |match-sent || c | 893 |CoAP Uri-Path | |up|temperature| equal |not-sent || | 894 |COAP Option-End| |dw| 0xFF | equal |not-sent || | 895 +---------------+--+--+-----------+-----------+-----------++------+ 897 Figure 13: Inner SCHC Rules 899 Figure 14 shows the Plaintext obtained for our example GET Request 900 and follows the process of Inner Compression and Encryption until we 901 end up with the Payload to be added in the outer OSCORE Message. 903 In this case the original message has no payload and its resulting 904 Plaintext can be compressed up to only 1 byte (size of the RuleID). 905 The AEAD algorithm preserves this length in its first output, but 906 also yields a fixed-size tag which cannot be compressed and has to be 907 included in the OSCORE message. This translates into an overhead in 908 total message length, which limits the amount of compression that can 909 be achieved and plays into the cost of adding security to the 910 exchange. 912 ________________________________________________________ 913 | | 914 | OSCORE Plaintext | 915 | | 916 | 0x01bb74656d7065726174757265 (13 bytes) | 917 | | 918 | 0x01 Request Code GET | 919 | | 920 | bb74656d7065726174757265 Option 11: URI_PATH | 921 | Value = temperature | 922 |________________________________________________________| 924 | 925 | 926 | Inner SCHC Compression 927 | 928 v 929 _________________________________ 930 | | 931 | Compressed Plaintext | 932 | | 933 | 0x00 | 934 | | 935 | RuleID = 0x00 (1 byte) | 936 | (No residue) | 937 |_________________________________| 939 | 940 | AEAD Encryption 941 | (piv = 0x04) 942 v 943 _________________________________________________ 944 | | 945 | encrypted_plaintext = 0xa2 (1 byte) | 946 | tag = 0xc54fe1b434297b62 (8 bytes) | 947 | | 948 | ciphertext = 0xa2c54fe1b434297b62 (9 bytes) | 949 |_________________________________________________| 951 Figure 14: Plaintext compression and encryption for GET Request 953 In Figure 15 the process is repeated for the example CONTENT 954 Response. The residue is 1 bit long. Note that since SCHC adds 955 padding after the payload, this misalignment causes the hexadecimal 956 code from the payload to differ from the original, even though it has 957 not been compressed. 959 On top of this, the overhead from the tag bytes is incurred as 960 before. 962 ________________________________________________________ 963 | | 964 | OSCORE Plaintext | 965 | | 966 | 0x45ff32332043 (6 bytes) | 967 | | 968 | 0x45 Successful Response Code 69 "2.05 Content" | 969 | | 970 | ff Payload marker | 971 | | 972 | 32332043 Payload | 973 |________________________________________________________| 975 | 976 | 977 | Inner SCHC Compression 978 | 979 v 980 __________________________________________ 981 | | 982 | Compressed Plaintext | 983 | | 984 | 0x001919902180 (6 bytes) | 985 | | 986 | 00 RuleID | 987 | | 988 | 0b0 (1 bit match-map residue) | 989 | 0x32332043 >> 1 (shifted payload) | 990 | 0b0000000 Padding | 991 |__________________________________________| 993 | 994 | AEAD Encryption 995 | (piv = 0x04) 996 v 997 _________________________________________________________ 998 | | 999 | encrypted_plaintext = 0x10c6d7c26cc1 (6 bytes) | 1000 | tag = 0xe9aef3f2461e0c29 (8 bytes) | 1001 | | 1002 | ciphertext = 0x10c6d7c26cc1e9aef3f2461e0c29 (14 bytes) | 1003 |_________________________________________________________| 1005 Figure 15: Plaintext compression and encryption for CONTENT Response 1006 The Outer SCHC Rules (Figure 18) must process the OSCORE Options 1007 fields. In Figure 16 and Figure 17 we show a dump of the OSCORE 1008 Messages generated from our example messages once they have been 1009 provided with the Inner Compressed Ciphertext in the payload. These 1010 are the messages that have to be compressed by the Outer SCHC 1011 Compression. 1013 Protected message: 1014 ================== 1015 0x4102000182d8080904636c69656e74ffa2c54fe1b434297b62 1016 (25 bytes) 1018 Header: 1019 0x4102 1020 01 Ver 1021 00 CON 1022 0001 tkl 1023 00000010 Request Code 2 "POST" 1025 0x0001 = mid 1026 0x82 = token 1028 Options: 1029 0xd8080904636c69656e74 (10 bytes) 1030 Option 21: OBJECT_SECURITY 1031 Value = 0x0904636c69656e74 1032 09 = 000 0 1 001 Flag byte 1033 h k n 1034 04 piv 1035 636c69656e74 kid 1037 0xFF Payload marker 1038 Payload: 1039 0xa2c54fe1b434297b62 (9 bytes) 1041 Figure 16: Protected and Inner SCHC Compressed GET Request 1043 Protected message: 1044 ================== 1045 0x6144000182d008ff10c6d7c26cc1e9aef3f2461e0c29 1046 (22 bytes) 1048 Header: 1049 0x6144 1050 01 Ver 1051 10 ACK 1052 0001 tkl 1053 01000100 Successful Response Code 68 "2.04 Changed" 1055 0x0001 = mid 1056 0x82 = token 1058 Options: 1059 0xd008 (2 bytes) 1060 Option 21: OBJECT_SECURITY 1061 Value = b'' 1063 0xFF Payload marker 1064 Payload: 1065 0x10c6d7c26cc1e9aef3f2461e0c29 (14 bytes) 1067 Figure 17: Protected and Inner SCHC Compressed CONTENT Response 1069 For the flag bits, a number of compression methods has been shown to 1070 be useful depending on the application. The simplest alternative is 1071 to provide a fixed value for the flags, combining MO equal and CDA 1072 not- sent. This saves most bits but could prevent flexibility. 1073 Otherwise, match-mapping could be used to choose from an interested 1074 number of configurations to the exchange. Otherwise, MSB could be 1075 used to mask off the 3 hard-coded most significant bits. 1077 Note that fixing a flag bit will limit the choice of CoAP Options 1078 that can be used in the exchange, since their values are dependent on 1079 certain options. 1081 The piv field lends itself to having a number of bits masked off with 1082 MO MSB and CDA LSB. This could be useful in applications where the 1083 message frequency is low such as that found in LPWAN technologies. 1084 Note that compressing the sequence numbers effectively reduces the 1085 maximum amount of sequence numbers that can be used in an exchange. 1086 Once this amount is exceeded, the OSCORE keys need to be re- 1087 established. 1089 The size s included in the kid context field MAY be masked off with 1090 CDA MSB. The rest of the field could have additional bits masked 1091 off, or have the whole field be fixed with MO equal and CDA not-sent. 1092 The same holds for the kid field. 1094 Figure 18 shows a possible set of Outer Rules to compress the Outer 1095 Header. 1097 RuleID 0 1098 +-------------------+--+--+--------------+--------+---------++------+ 1099 | Field |FP|DI| Target | MO | CDA || Sent | 1100 | | | | Value | | ||[bits]| 1101 +-------------------+--+--+--------------+--------+---------++------+ 1102 |CoAP version | |bi| 01 |equal |not-sent || | 1103 |CoAP Type | |up| 0 |equal |not-sent || | 1104 |CoAP Type | |dw| 2 |equal |not-sent || | 1105 |CoAP TKL | |bi| 1 |equal |not-sent || | 1106 |CoAP Code | |up| 2 |equal |not-sent || | 1107 |CoAP Code | |dw| 68 |equal |not-sent || | 1108 |CoAP MID | |bi| 0000 |MSB(12) |LSB ||MMMM | 1109 |CoAP Token | |bi| 0x80 |MSB(5) |LSB ||TTT | 1110 |CoAP OSCORE_flags | |up| 0x09 |equal |not-sent || | 1111 |CoAP OSCORE_piv | |up| 0x00 |MSB(4) |LSB ||PPPP | 1112 |COAP OSCORE_kid | |up|0x636c69656e70|MSB(52) |LSB ||KKKK | 1113 |COAP OSCORE_kidctxt| |bi| b'' |equal |not-sent || | 1114 |CoAP OSCORE_flags | |dw| b'' |equal |not-sent || | 1115 |CoAP OSCORE_piv | |dw| b'' |equal |not-sent || | 1116 |CoAP OSCORE_kid | |dw| b'' |equal |not-sent || | 1117 |COAP Option-End | |dw| 0xFF |equal |not-sent || | 1118 +-------------------+--+--+--------------+--------+---------++------+ 1120 Figure 18: Outer SCHC Rules 1122 These Outer Rules are applied to the example GET Request and CONTENT 1123 Response. The resulting messages are shown in Figure 19 and 1124 Figure 20. 1126 Compressed message: 1127 ================== 1128 0x001489458a9fc3686852f6c4 (12 bytes) 1129 0x00 RuleID 1130 1489 Compression Residue 1131 458a9fc3686852f6c4 Padded payload 1133 Compression Residue: 1134 0b 0001 010 0100 0100 (15 bits -> 2 bytes with padding) 1135 mid tkn piv kid 1137 Payload 1138 0xa2c54fe1b434297b62 (9 bytes) 1140 Compressed message length: 12 bytes 1142 Figure 19: SCHC-OSCORE Compressed GET Request 1144 Compressed message: 1145 ================== 1146 0x0014218daf84d983d35de7e48c3c1852 (16 bytes) 1147 0x00 RuleID 1148 14 Compression Residue 1149 218daf84d983d35de7e48c3c1852 Padded payload 1150 Compression Residue: 1151 0b0001 010 (7 bits -> 1 byte with padding) 1152 mid tkn 1154 Payload 1155 0x10c6d7c26cc1e9aef3f2461e0c29 (14 bytes) 1157 Compressed msg length: 16 bytes 1159 Figure 20: SCHC-OSCORE Compressed CONTENT Response 1161 For contrast, we compare these results with what would be obtained by 1162 SCHC compressing the original CoAP messages without protecting them 1163 with OSCORE. To do this, we compress the CoAP messages according to 1164 the SCHC Rules in Figure 21. 1166 RuleID 1 1167 +---------------+--+--+-----------+---------+-----------++--------+ 1168 | Field |FP|DI| Target | MO | CDA || Sent | 1169 | | | | Value | | || [bits] | 1170 +---------------+--+--+-----------+---------+-----------++--------+ 1171 |CoAP version | |bi| 01 |equal |not-sent || | 1172 |CoAP Type | |up| 0 |equal |not-sent || | 1173 |CoAP Type | |dw| 2 |equal |not-sent || | 1174 |CoAP TKL | |bi| 1 |equal |not-sent || | 1175 |CoAP Code | |up| 2 |equal |not-sent || | 1176 |CoAP Code | |dw| [69,132] |match-map|map-sent ||C | 1177 |CoAP MID | |bi| 0000 |MSB(12) |LSB ||MMMM | 1178 |CoAP Token | |bi| 0x80 |MSB(5) |LSB ||TTT | 1179 |CoAP Uri-Path | |up|temperature|equal |not-sent || | 1180 |COAP Option-End| |dw| 0xFF |equal |not-sent || | 1181 +---------------+--+--+-----------+---------+-----------++--------+ 1183 Figure 21: SCHC-CoAP Rules (No OSCORE) 1185 This yields the results in Figure 22 for the Request, and Figure 23 1186 for the Response. 1188 Compressed message: 1189 ================== 1190 0x0114 1191 0x01 = RuleID 1193 Compression Residue: 1194 0b00010100 (1 byte) 1196 Compressed msg length: 2 1198 Figure 22: CoAP GET Compressed without OSCORE 1200 Compressed message: 1201 ================== 1202 0x010a32332043 1203 0x01 = RuleID 1205 Compression Residue: 1206 0b00001010 (1 byte) 1208 Payload 1209 0x32332043 1211 Compressed msg length: 6 1213 Figure 23: CoAP CONTENT Compressed without OSCORE 1215 As can be seen, the difference between applying SCHC + OSCORE as 1216 compared to regular SCHC + COAP is about 10 bytes of cost. 1218 8. IANA Considerations 1220 This document has no request to IANA. 1222 9. Security considerations 1224 When applied to LPWAN, the Security Considerations of SCHC header 1225 compression [rfc8724] are valid for SCHC CoAP header compression. 1226 When CoAP uses OSCORE, the security considerations defined in 1227 [rfc8613] does not change when SCHC header compression is applied. 1229 The definition of SCHC over CoAP header fields permits the 1230 compression of header information only. The SCHC header compression 1231 itself does not increase or reduce the level of security in the 1232 communication. When the connection does not use any security 1233 protocol as OSCORE, DTLS, or other, it is highly necessary to use a 1234 layer two security. 1236 DoS attacks are possible if an intruder can introduce a compressed 1237 SCHC corrupted packet onto the link and cause a compression 1238 efficiency reduction. However, an intruder having the ability to add 1239 corrupted packets at the link layer raises additional security issues 1240 than those related to the use of header compression. 1242 SCHC compression returns variable-length Residues for some CoAP 1243 fields. In the compressed header, the length sent is not the 1244 original header field length but the length of the Residue. So if a 1245 corrupted packet comes to the decompressor with a longer or shorter 1246 length than the one in the original header, SCHC decompression will 1247 detect an error and drops the packet. 1249 OSCORE compression is also based on the same compression method 1250 described in [rfc8724]. The size of the Initialisation Vector (IV) 1251 residue must be considered carefully. A residue size obtained with 1252 LSB CDA over the IV has an impact on the compression efficiency and 1253 the frequency the device will renew its key. This operation requires 1254 several exchanges and is energy-consuming. 1256 SCHC header and compression Rules MUST remain tightly coupled. 1257 Otherwise, an encrypted residue may be decompressed differently by 1258 the receiver. To avoid this situation, if the Rule is modified in 1259 one location, the OSCORE keys MUST be re-established. 1261 10. Acknowledgements 1263 The authors would like to thank (in alphabetic order): Christian 1264 Amsuss, Dominique Barthel, Carsten Bormann, Theresa Enghardt, Thomas 1265 Fossati, Klaus Hartke, Francesca Palombini, Alexander Pelov and Goran 1266 Selander. 1268 11. Normative References 1270 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 1271 Requirement Levels", BCP 14, RFC 2119, 1272 DOI 10.17487/RFC2119, March 1997, 1273 . 1275 [rfc7252] Shelby, Z., Hartke, K., and C. Bormann, "The Constrained 1276 Application Protocol (CoAP)", RFC 7252, 1277 DOI 10.17487/RFC7252, June 2014, 1278 . 1280 [rfc7641] Hartke, K., "Observing Resources in the Constrained 1281 Application Protocol (CoAP)", RFC 7641, 1282 DOI 10.17487/RFC7641, September 2015, 1283 . 1285 [rfc7959] Bormann, C. and Z. Shelby, Ed., "Block-Wise Transfers in 1286 the Constrained Application Protocol (CoAP)", RFC 7959, 1287 DOI 10.17487/RFC7959, August 2016, 1288 . 1290 [rfc7967] Bhattacharyya, A., Bandyopadhyay, S., Pal, A., and T. 1291 Bose, "Constrained Application Protocol (CoAP) Option for 1292 No Server Response", RFC 7967, DOI 10.17487/RFC7967, 1293 August 2016, . 1295 [rfc8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC 1296 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, 1297 May 2017, . 1299 [rfc8613] Selander, G., Mattsson, J., Palombini, F., and L. Seitz, 1300 "Object Security for Constrained RESTful Environments 1301 (OSCORE)", RFC 8613, DOI 10.17487/RFC8613, July 2019, 1302 . 1304 [rfc8724] Minaburo, A., Toutain, L., Gomez, C., Barthel, D., and JC. 1305 Zuniga, "SCHC: Generic Framework for Static Context Header 1306 Compression and Fragmentation", RFC 8724, 1307 DOI 10.17487/RFC8724, April 2020, 1308 . 1310 Authors' Addresses 1312 Ana Minaburo 1313 Acklio 1314 1137A avenue des Champs Blancs 1315 35510 Cesson-Sevigne Cedex 1316 France 1318 Email: ana@ackl.io 1320 Laurent Toutain 1321 Institut MINES TELECOM; IMT Atlantique 1322 2 rue de la Chataigneraie 1323 CS 17607 1324 35576 Cesson-Sevigne Cedex 1325 France 1327 Email: Laurent.Toutain@imt-atlantique.fr 1329 Ricardo Andreasen 1330 Universidad de Buenos Aires 1331 Av. Paseo Colon 850 1332 C1063ACV Ciudad Autonoma de Buenos Aires 1333 Argentina 1335 Email: randreasen@fi.uba.ar