idnits 2.17.1 draft-ietf-lpwan-coap-static-context-hc-14.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 1086 has weird spacing: '...tkn piv kid...' == Line 1103 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 (May 26, 2020) is 1429 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 1127 -- Looks like a reference, but probably isn't: '132' on line 1127 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: November 27, 2020 Institut MINES TELECOM; IMT Atlantique 6 R. Andreasen 7 Universidad de Buenos Aires 8 May 26, 2020 10 LPWAN Static Context Header Compression (SCHC) for CoAP 11 draft-ietf-lpwan-coap-static-context-hc-14 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 November 27, 2020. 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 . . . . . . . . . . . . . . 5 69 3.1. Differences between CoAP and UDP/IP Compression . . . . . 5 70 4. Compression of CoAP header fields . . . . . . . . . . . . . . 6 71 4.1. CoAP version field . . . . . . . . . . . . . . . . . . . 7 72 4.2. CoAP type field . . . . . . . . . . . . . . . . . . . . . 7 73 4.3. CoAP code field . . . . . . . . . . . . . . . . . . . . . 7 74 4.4. CoAP Message ID field . . . . . . . . . . . . . . . . . . 7 75 4.5. CoAP Token fields . . . . . . . . . . . . . . . . . . . . 7 76 5. CoAP options . . . . . . . . . . . . . . . . . . . . . . . . 8 77 5.1. CoAP Content and Accept options. . . . . . . . . . . . . 8 78 5.2. CoAP option Max-Age, Uri-Host and Uri-Port fields . . . . 8 79 5.3. CoAP option Uri-Path and Uri-Query fields . . . . . . . . 9 80 5.3.1. Variable length Uri-Path and Uri-Query . . . . . . . 9 81 5.3.2. Variable number of path or query elements . . . . . . 10 82 5.4. CoAP option Size1, Size2, Proxy-URI and Proxy-Scheme 83 fields . . . . . . . . . . . . . . . . . . . . . . . . . 10 84 5.5. CoAP option ETag, If-Match, If-None-Match, Location-Path 85 and Location-Query fields . . . . . . . . . . . . . . . . 10 86 6. SCHC compression of CoAP extension RFCs . . . . . . . . . . . 11 87 6.1. Block . . . . . . . . . . . . . . . . . . . . . . . . . . 11 88 6.2. Observe . . . . . . . . . . . . . . . . . . . . . . . . . 11 89 6.3. No-Response . . . . . . . . . . . . . . . . . . . . . . . 11 90 6.4. OSCORE . . . . . . . . . . . . . . . . . . . . . . . . . 11 91 7. Examples of CoAP header compression . . . . . . . . . . . . . 13 92 7.1. Mandatory header with CON message . . . . . . . . . . . . 13 93 7.2. OSCORE Compression . . . . . . . . . . . . . . . . . . . 14 94 7.3. Example OSCORE Compression . . . . . . . . . . . . . . . 17 95 8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 27 96 9. Security considerations . . . . . . . . . . . . . . . . . . . 27 97 10. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 28 98 11. Normative References . . . . . . . . . . . . . . . . . . . . 28 99 Appendix A. Extension to the RFC8724 Annex D. . . . . . . . . . 29 100 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 29 102 1. Introduction 104 CoAP [rfc7252] is designed to easily interop with HTTP (Hypertext 105 Transfer Protocol) and is optimized for REST-based (Representational 106 state transfer) services. Although CoAP was designed for constrained 107 devices, the size of a CoAP header still is too large for the 108 constraints of LPWAN (Low Power Wide Area Networks) and some 109 compression is needed to reduce the header size. 111 The [rfc8724] defines SCHC, a header compression mechanism for LPWAN 112 network based on a static context. The section 5 of the [rfc8724] 113 explains the architecture where compression and decompression are 114 done. The context is known by both ends before transmission. The 115 way the context is configured, provisioned or exchanged is out of the 116 scope of this document. 118 SCHC compresses and decompresses headers based on shared contexts 119 between devices. Each context consists of multiple Rules. Each Rule 120 can match header fields and specific values or ranges of values. If 121 a Rule matches, the matched header fields are substituted by the 122 RuleID and optionally some residual bits. Thus, different Rules may 123 correspond to different types of packets that a device expects to 124 send or receive. 126 A Rule describes the complete header of the packet with an ordered 127 list of fields descriptions, see section 7 of [rfc8724], thereby each 128 description contains the field ID (FID), its length (FL) and its 129 position (FP), a direction indicator (DI) (upstream, downstream and 130 bidirectional) and some associated Target Values (TV). 132 A Matching Operator (MO) is associated to each header field 133 description. The Rule is selected if all the MOs fit the TVs for all 134 fields of the incoming header. 135 In that case, a Compression/Decompression Action (CDA) associated to 136 each field defines how the compressed and the decompressed values are 137 computed. Compression mainly results in one of 4 actions: 139 o send the field value, 141 o send nothing, 143 o send some least significant bits of the field or 144 o send an index. 146 After applying the compression there may be some bits to be sent, 147 these values are called Compression Residues. 149 SCHC is a general mechanism that can be applied to different 150 protocols, the exact Rules to be used depend on the protocol and the 151 application. The section 10 of the [rfc8724] describes the 152 compression scheme for IPv6 and UDP headers. This document targets 153 the CoAP header compression using SCHC. 155 1.1. Terminology 157 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 158 "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and 159 "OPTIONAL" in this document are to be interpreted as described in BCP 160 14 [RFC2119][rfc8174] when, and only when, they appear in all 161 capitals, as shown here. 163 2. Applying SCHC to CoAP headers 165 The SCHC Compression Rules can be applied to CoAP headers. SCHC 166 Compression of the CoAP header MAY be done in conjunction with the 167 lower layers (IPv6/UDP) or independently. The SCHC adaptation layers 168 as described in Section 5 of [rfc8724] and may be used as shown in 169 Figure 1. 171 ^ +------------+ ^ +------------+ ^ +------------+ 172 | | CoAP | | | CoAP | inner | | CoAP | 173 | +------------+ v +------------+ x | OSCORE | 174 | | UDP | | DTLS | outer | +------------+ 175 | +------------+ +------------+ | | UDP | 176 | | IPv6 | | UDP | | +------------+ 177 v +------------+ +------------+ | | IPv6 | 178 | IPv6 | v +------------+ 179 +------------+ 181 Figure 1: Rule scope for CoAP 183 Figure 1 shows some examples for CoAP protocol stacks and the SCHC 184 Rule's scope. 186 In the first example, a Rule compresses the complete header stack 187 from IPv6 to CoAP. In this case, SCHC C/D (Static Context Header 188 Compression Compressor/Decompressor) is performed at the Sender and 189 at the Receiver. 191 In the second example, the SCHC compression is applied in the CoAP 192 layer, compressing the CoAP header independently of the other layers. 193 The RuleID and the Compression Residue are encrypted using a 194 mechanism such as DTLS. Only the other end can decipher the 195 information. If needed, layers below use SCHC to compress the header 196 as defined in [rfc8724] document. This use case realizes an End-to- 197 End context initialization between the sender and the receiver, see 198 Appendix A. 200 In the third example, the Object Security for Constrained RESTful 201 Environments (OSCORE) [rfc8613] is used. In this case, two rulesets 202 are used to compress the CoAP message. A first ruleset focused on 203 the inner header and is applied end to end by both ends. A second 204 ruleset compresses the outer header and the layers below and is done 205 between the Sender and the Receiver. 207 3. CoAP Headers compressed with SCHC 209 The use of SCHC over the CoAP header uses the same description and 210 compression/decompression techniques as the one for IP and UDP 211 explained in the [rfc8724]. For CoAP, SCHC Rules description uses 212 the direction information to optimize the compression by reducing the 213 number of Rules needed to compress headers. The field description 214 MAY define both request/response headers and target values in the 215 same Rule, using the DI (direction indicator) to make the difference. 216 As for other protocols, when the compressor does not find a correct 217 Rule to compress the header, the packet MUST be sent uncompressed 218 using the RuleID dedicated to this purpose, and the Compression 219 Residue is the complete header of the packet. See section 6 of 220 [rfc8724]. 222 3.1. Differences between CoAP and UDP/IP Compression 224 CoAP compression differs from IPv6 and UDP compression on the 225 following aspects: 227 o The CoAP protocol is asymmetric, the headers are different for a 228 request or a response. For example, the URI-path option is 229 mandatory in the request, and it is not present in the response, a 230 request may contain an Accept option, and the response may include 231 a Content option. In comparison, IPv6 and UDP returning path swap 232 the value of some fields in the header. 233 But all the directions have the same fields (e.g., source and 234 destination addresses fields). 236 The [rfc8724] defines the use of a Direction Indicator (DI) in the 237 Field Description, which allows a single Rule to process message 238 headers differently depending on the direction. 240 o Even when a field is "symmetric" (i.e., found in both directions), 241 the values carried in each direction are different. 242 The compression may use a matching list in the TV to limit the 243 range of expected values in a particular direction and therefore 244 reduces the size of the Compression Residue. Through the 245 Direction Indicator (DI), a field description in the Rules splits 246 the possible field value into two parts, one for each direction. 247 For instance, if a client sends only CON requests, the type can be 248 elided by compression, and the answer may use one single bit to 249 carry either the ACK or RST type. The field Code have as well the 250 same behavior, the 0.0X code format value in the request and Y.ZZ 251 code format in the response. 253 o Headers in IPv6 and UDP have a fixed size. The size is not sent 254 as part of the Compression Residue, but is defined in the Rule. 255 Some CoAP header fields have variable lengths, so the length is 256 also specified in the Field Description. For example, the Token 257 size may vary from 0 to 8 bytes. And the CoAP options have a 258 variable length since they use the Type-Length-Value encoding 259 format, as URI-path or URI-query. 261 Section 7.5.2 from [rfc8724] offers the possibility to define a 262 function for the Field length in the Field Description to have 263 knowledge of the length before compression. When doing SCHC 264 compression of a variable-length field, 265 if the field size is not known, the Field Length in the Rule is 266 set as variable and the size is sent with the Compression Residue. 268 o A field can appear several time in the CoAP headers. This is 269 typical for elements of a URI (path or queries). The SCHC 270 specification [rfc8724] allows a Field ID to appear several times 271 in the Rule, and uses the Field Position (FP) to identify the 272 correct instance, and thereby removing the ambiguity of the 273 matching operation. 275 o Field sizes defined in the CoAP protocol can be too large 276 regarding LPWAN traffic constraints. This is particularly true 277 for the Message ID field and the Token field. SCHC uses different 278 Matching operators (MO) to perform the compression, see section 279 7.4 of [rfc8724]. In this case the Most Significant Bits (MSB) MO 280 can be applied to reduce the information carried on LPWANs. 282 4. Compression of CoAP header fields 284 This section discusses the compression of the different CoAP header 285 fields. The CoAP compression with SCHC follows the Section 7.1 of 286 [rfc8724]. 288 4.1. CoAP version field 290 CoAP version is bidirectional and MUST be elided during the SCHC 291 compression, since it always contains the same value. In the future, 292 if new versions of CoAP are defined, new Rules will be needed to 293 avoid ambiguities between versions. 295 4.2. CoAP type field 297 The CoAP Protocol [rfc7252] has four type of messages: two request 298 (CON, NON); one response (ACK) and one empty message (RST). 300 The field SHOULD be elided if for instance a client is sending only 301 NON or only CON messages. For the RST message a dedicated Rule may 302 be needed. For other usages a mapping list can be used. 304 4.3. CoAP code field 306 The code field indicates the Request Method used in CoAP, a IANA 307 registry [rfc7252]. The compression of the CoAP code field follows 308 the same principle as that of the CoAP type field. If the device 309 plays a specific role, the set of code values can be split in two 310 parts, the request codes with the 0 class and the response values. 312 If the device only implements a CoAP client, the request code can be 313 reduced to the set of requests the client is able to process. 315 A mapping list can be used for known values. For other values the 316 field cannot be compressed an the value needs to be sent in the 317 Compression Residue. 319 4.4. CoAP Message ID field 321 The Message ID field can be compressed with the MSB(x) MO and the 322 Least Significant Bits (LSB) CDA, see section 7.4 of [rfc8724]. 324 4.5. CoAP Token fields 326 Token is defined through two CoAP fields, Token Length in the 327 mandatory header and Token Value directly following the mandatory 328 CoAP header. 330 Token Length is processed as any protocol field. If the value does 331 not change, the size can be stored in the TV and elided during the 332 transmission. Otherwise, it will have to be sent in the Compression 333 Residue. 335 Token Value MUST NOT be sent as a variable length residue to avoid 336 ambiguity with Token Length. Therefore, Token Length value MUST be 337 used to define the size of the Compression Residue. A specific 338 function designated as "TKL" MUST be used in the Rule. During the 339 decompression, this function returns the value contained in the Token 340 Length field. 342 5. CoAP options 344 CoAP defines options that are placed after the based header in Option 345 Numbers order, see [rfc7252]. Each Option instance in a message uses 346 the format Delta-Type (D-T), Length (L), Value (V). When applying 347 SCHC compression to the Option, the D-T, L, and V format serves to 348 make the Rule description of the Option. The SCHC compression builds 349 the description of the Option by using in the Field ID the Option 350 Number built from D-T; in TV, the Option Value; and the Option Length 351 uses section 7.4 of RFC8724. When the Option Length has a wellknown 352 size it can be stored in the Rule. Therefore, SCHC compression does 353 not send it. Otherwise, SCHC Compression carries the length of the 354 Compression Residue in addition to the Compression Residue value. 356 Note that length coding differs between CoAP options and SCHC 357 variable size Compression Residue. 359 The following sections present how SCHC compresses some specific CoAP 360 Options. 362 5.1. CoAP Content and Accept options. 364 These fields are both unidirectional and MUST NOT be set to 365 bidirectional in a Rule entry. 367 If a single value is expected by the client, it can be stored in the 368 TV and elided during the transmission. Otherwise, if several 369 possible values are expected by the client, a matching-list SHOULD be 370 used to limit the size of the Compression Residue. Otherwise, the 371 value has to be sent as a Compression Residue (fixed or variable 372 length). 374 5.2. CoAP option Max-Age, Uri-Host and Uri-Port fields 376 These fields are unidirectional and MUST NOT be set to bidirectional 377 in a Rule DI entry, see section 7.1 of [rfc8724]. They are used only 378 by the server to inform of the caching duration and is never found in 379 client requests. 381 If the duration is known by both ends, the value can be elided. 383 A matching list can be used if some well-known values are defined. 385 Otherwise these options can be sent as a Compression Residue (fixed 386 or variable length). 388 5.3. CoAP option Uri-Path and Uri-Query fields 390 These fields are unidirectional and MUST NOT be set to bidirectional 391 in a Rule entry. They are used only by the client to access a 392 specific resource and are never found in server responses. 394 Uri-Path and Uri-Query elements are a repeatable options, the Field 395 Position (FP) gives the position in the path. 397 A Mapping list can be used to reduce the size of variable Paths or 398 Queries. In that case, to optimize the compression, several elements 399 can be regrouped into a single entry. Numbering of elements do not 400 change, MO comparison is set with the first element of the matching. 402 +-------------+---+--+--+--------+---------+-------------+ 403 | Field |FL |FP|DI| Target | Match | CDA | 404 | | | | | Value | Opera. | | 405 +-------------+---+--+--+--------+---------+-------------+ 406 |URI-Path | | 1|up|["/a/b",|equal |not-sent | 407 | | | | |"/c/d"] | | | 408 |URI-Path |var| 3|up| |ignore |value-sent | 409 +-------------+---+--+--+--------+---------+-------------+ 411 Figure 2: complex path example 413 In Figure 2 a single bit residue can be used to code one of the 2 414 paths. If regrouping were not allowed, a 2 bits residue would be 415 needed. The third path element is sent as a variable size residue. 417 5.3.1. Variable length Uri-Path and Uri-Query 419 When the length is not known at the Rule creation, the Field Length 420 MUST be set to variable, and the unit is set to bytes. 422 The MSB MO can be applied to a Uri-Path or Uri-Query element. Since 423 MSB value is given in bit, the size MUST always be a multiple of 8 424 bits. 426 The length sent at the beginning of a variable length residue 427 indicates the size of the LSB in bytes. 429 For instance for a CORECONF path /c/X6?k="eth0" the Rule can be set 430 to: 432 +-------------+---+--+--+--------+---------+-------------+ 433 | Field |FL |FP|DI| Target | Match | CDA | 434 | | | | | Value | Opera. | | 435 +-------------+---+--+--+--------+---------+-------------+ 436 |URI-Path | 8| 1|up|"c" |equal |not-sent | 437 |URI-Path |var| 2|up| |ignore |value-sent | 438 |URI-Query |var| 1|up|"k=" |MSB(16) |LSB | 439 +-------------+---+--+--+--------+---------+-------------+ 441 Figure 3: CORECONF URI compression 443 Figure 3 shows the parsing and the compression of the URI, where c is 444 not sent. The second element is sent with the length (i.e. 0x2 X 6) 445 followed by the query option (i.e. 0x05 "eth0"). 447 5.3.2. Variable number of path or query elements 449 The number of Uri-path or Uri-Query elements in a Rule is fixed at 450 the Rule creation time. If the number varies, several Rules SHOULD 451 be created to cover all the possibilities. Another possibility is to 452 define the length of Uri-Path to variable and send a Compression 453 Residue with a length of 0 to indicate that this Uri-Path is empty. 454 This adds 4 bits to the variable Residue size. See section 7.5.2 455 [rfc8724] 457 5.4. CoAP option Size1, Size2, Proxy-URI and Proxy-Scheme fields 459 These fields are unidirectional and MUST NOT be set to bidirectional 460 in a Rule DI entry, see section 7.1 of the [rfc8724]. They are used 461 only by the client to access a specific resource and are never found 462 in server response. 464 If the field value has to be sent, TV is not set, MO is set to 465 "ignore" and CDA is set to "value-sent". A mapping MAY also be used. 467 Otherwise, the TV is set to the value, MO is set to "equal" and CDA 468 is set to "not-sent". 470 5.5. CoAP option ETag, If-Match, If-None-Match, Location-Path and 471 Location-Query fields 473 These fields are unidirectional. 475 These fields values cannot be stored in a Rule entry. They MUST 476 always be sent with the Compression Residues. 478 6. SCHC compression of CoAP extension RFCs 480 6.1. Block 482 Block [rfc7959] allows a fragmentation at the CoAP level. SCHC also 483 includes a fragmentation protocol. They can be both used. If a 484 block option is used, its content MUST be sent as a Compression 485 Residue. 487 6.2. Observe 489 The [rfc7641] defines the Observe option. The TV is not set, MO is 490 set to "ignore" and the CDA is set to "value-sent". SCHC does not 491 limit the maximum size for this option (3 bytes). To reduce the 492 transmission size, either the device implementation MAY limit the 493 delta between two consecutive values, or a proxy can modify the 494 increment. 496 Since an RST message may be sent to inform a server that the client 497 does not require Observe response, a Rule MUST allow the transmission 498 of this message. 500 6.3. No-Response 502 The [rfc7967] defines a No-Response option limiting the responses 503 made by a server to a request. If the value is known by both ends, 504 then TV is set to this value, MO is set to "equal" and CDA is set to 505 "not-sent". 507 Otherwise, if the value is changing over time, TV is not set, MO is 508 set to "ignore" and CDA to "value-sent". A matching list can also be 509 used to reduce the size. 511 6.4. OSCORE 513 OSCORE [rfc8613] defines end-to-end protection for CoAP messages. 514 This section describes how SCHC Rules can be applied to compress 515 OSCORE-protected messages. 517 0 1 2 3 4 5 6 7 <--------- n bytes -------------> 518 +-+-+-+-+-+-+-+-+--------------------------------- 519 |0 0 0|h|k| n | Partial IV (if any) ... 520 +-+-+-+-+-+-+-+-+--------------------------------- 521 | | | 522 |<-- CoAP -->|<------ CoAP OSCORE_piv ------> | 523 OSCORE_flags 525 <- 1 byte -> <------ s bytes -----> 526 +------------+----------------------+-----------------------+ 527 | s (if any) | kid context (if any) | kid (if any) ... | 528 +------------+----------------------+-----------------------+ 529 | | | 530 | <------ CoAP OSCORE_kidctxt ----->|<-- CoAP OSCORE_kid -->| 532 Figure 4: OSCORE Option 534 The encoding of the OSCORE Option Value defined in Section 6.1 of 535 [rfc8613] is repeated in Figure 4. 537 The first byte specifies the content of the OSCORE options using 538 flags. The three most significant bits of this byte are reserved and 539 always set to 0. Bit h, when set, indicates the presence of the kid 540 context field in the option. Bit k, when set, indicates the presence 541 of a kid field. The three least significant bits n indicate the 542 length of the piv (Partial Initialization Vector) field in bytes. 543 When n = 0, no piv is present. 545 The flag byte is followed by the piv field, kid context field, and 546 kid field in this order, and if present, the length of the kid 547 context field is encoded in the first byte denoting by s the length 548 of the kid context in bytes. 550 This specification recommends identifying the OSCORE Option and the 551 fields it contains Conceptually, it discerns up to 4 distinct pieces 552 of information within the OSCORE option: the flag bits, the piv, the 553 kid context, and the kid. The SCHC Rule splits into four field 554 descriptions the OSCORE option to compress them: 556 o CoAP OSCORE_flags, 558 o CoAP OSCORE_piv, 560 o CoAP OSCORE_kidctxt, 562 o CoAP OSCORE_kid. 564 The OSCORE Option shows superimposed these four fields using the 565 format Figure 4, the CoAP OSCORE_kidctxt field includes the size bits 566 s. 568 7. Examples of CoAP header compression 570 7.1. Mandatory header with CON message 572 In this first scenario, the LPWAN Compressor at the Network Gateway 573 side receives from an Internet client a POST message, which is 574 immediately acknowledged by the Device. For this simple scenario, 575 the Rules are described Figure 5. 577 RuleID 1 578 +-------------+--+--+--+------+---------+-------------++------------+ 579 | Field |FL|FP|DI|Target| Match | CDA || Sent | 580 | | | | |Value | Opera. | || [bits] | 581 +-------------+--+--+--+------+---------+-------------++------------+ 582 |CoAP version | | |bi| 01 |equal |not-sent || | 583 |CoAP Type | | |dw| CON |equal |not-sent || | 584 |CoAP Type | | |up|[ACK, | | || | 585 | | | | | RST] |match-map|matching-sent|| T | 586 |CoAP TKL | | |bi| 0 |equal |not-sent || | 587 |CoAP Code | | |bi|[0.00,| | || | 588 | | | | | ... | | || | 589 | | | | | 5.05]|match-map|matching-sent|| CC CCC | 590 |CoAP MID | | |bi| 0000 |MSB(7 ) |LSB || M-ID| 591 |CoAP Uri-Path| | |dw| path |equal 1 |not-sent || | 592 +-------------+--+--+--+------+---------+-------------++------------+ 594 Figure 5: CoAP Context to compress header without token 596 The version and Token Length fields are elided. The 26 method and 597 response codes defined in [rfc7252] has been shrunk to 5 bits using a 598 matching list. Uri-Path contains a single element indicated in the 599 matching operator. 601 SCHC Compression reduces the header sending only the Type, a mapped 602 code and the least significant bits of Message ID (9 bits in the 603 example above). 605 Note that a request sent by a client located in an Application Server 606 to a server located in the device, may not be compressed through this 607 Rule since the MID will not start with 7 bits equal to 0. A CoAP 608 proxy, before the core SCHC C/D can rewrite the message ID to a value 609 matched by the Rule. 611 7.2. OSCORE Compression 613 OSCORE aims to solve the problem of end-to-end encryption for CoAP 614 messages. The goal, therefore, is to hide as much of the message as 615 possible while still enabling proxy operation. 617 Conceptually this is achieved by splitting the CoAP message into an 618 Inner Plaintext and Outer OSCORE Message. The Inner Plaintext 619 contains sensitive information which is not necessary for proxy 620 operation. This, in turn, is the part of the message which can be 621 encrypted until it reaches its end destination. The Outer Message 622 acts as a shell matching the format of a regular CoAP message, and 623 includes all Options and information needed for proxy operation and 624 caching. This decomposition is illustrated in Figure 6. 626 CoAP options are sorted into one of 3 classes, each granted a 627 specific type of protection by the protocol: 629 o Class E: Encrypted options moved to the Inner Plaintext, 631 o Class I: Integrity-protected options included in the AAD for the 632 encryption of the Plaintext but otherwise left untouched in the 633 Outer Message, 635 o Class U: Unprotected options left untouched in the Outer Message. 637 Additionally, the OSCORE Option is added as an Outer option, 638 signalling that the message is OSCORE protected. This option carries 639 the information necessary to retrieve the Security Context with which 640 the message was encrypted so that it may be correctly decrypted at 641 the other end-point. 643 Original CoAP Message 644 +-+-+---+-------+---------------+ 645 |v|t|tkl| code | Msg Id. | 646 +-+-+---+-------+---------------+....+ 647 | Token | 648 +-------------------------------.....+ 649 | Options (IEU) | 650 . . 651 . . 652 +------+-------------------+ 653 | 0xFF | 654 +------+------------------------+ 655 | | 656 | Payload | 657 | | 658 +-------------------------------+ 659 / \ 660 / \ 661 / \ 662 / \ 663 Outer Header v v Plaintext 664 +-+-+---+--------+---------------+ +-------+ 665 |v|t|tkl|new code| Msg Id. | | code | 666 +-+-+---+--------+---------------+....+ +-------+-----......+ 667 | Token | | Options (E) | 668 +--------------------------------.....+ +-------+------.....+ 669 | Options (IU) | | OxFF | 670 . . +-------+-----------+ 671 . OSCORE Option . | | 672 +------+-------------------+ | Payload | 673 | 0xFF | | | 674 +------+ +-------------------+ 676 Figure 6: A CoAP message is split into an OSCORE outer and plaintext 678 Figure 6 shows the message format for the OSCORE Message and 679 Plaintext. 681 In the Outer Header, the original message code is hidden and replaced 682 by a default dummy value. As seen in Sections 4.1.3.5 and 4.2 of the 683 [rfc8613], the message code is replaced by POST for requests and 684 Changed for responses when Observe is not used. If Observe is used, 685 the message code is replaced by FETCH for requests and Content for 686 responses. 688 The original message code is put into the first byte of the 689 Plaintext. Following the message code, the class E options comes and 690 if present the original message Payload is preceded by its payload 691 marker. 693 The Plaintext is now encrypted by an AEAD algorithm which integrity 694 protects Security Context parameters and eventually any class I 695 options from the Outer Header. Currently no CoAP options are marked 696 class I. The resulting Ciphertext becomes the new Payload of the 697 OSCORE message, as illustrated in Figure 7. 699 This Ciphertext is, as defined in RFC 5116, the concatenation of the 700 encrypted Plaintext and its authentication tag. Note that Inner 701 Compression only affects the Plaintext before encryption, thus we can 702 only aim to reduce this first, variable length component of the 703 Ciphertext. The authentication tag is fixed in length and considered 704 part of the cost of protection. 706 Outer Header 707 +-+-+---+--------+---------------+ 708 |v|t|tkl|new code| Msg Id. | 709 +-+-+---+--------+---------------+....+ 710 | Token | 711 +--------------------------------.....+ 712 | Options (IU) | 713 . . 714 . OSCORE Option . 715 +------+-------------------+ 716 | 0xFF | 717 +------+---------------------------+ 718 | | 719 | Ciphertext: Encrypted Inner | 720 | Header and Payload | 721 | + Authentication Tag | 722 | | 723 +----------------------------------+ 725 Figure 7: OSCORE message 727 The SCHC Compression scheme consists of compressing both the 728 Plaintext before encryption and the resulting OSCORE message after 729 encryption, see Figure 8. 731 This translates into a segmented process where SCHC compression is 732 applied independently in 2 stages, each with its corresponding set of 733 Rules, with the Inner SCHC Rules and the Outer SCHC Rules. This way 734 compression is applied to all fields of the original CoAP message. 736 Note that since the Inner part of the message can only be decrypted 737 by the corresponding end-point, this end-point will also have to 738 implement Inner SCHC Compression/Decompression. 740 Outer Message OSCORE Plaintext 741 +-+-+---+--------+---------------+ +-------+ 742 |v|t|tkl|new code| Msg Id. | | code | 743 +-+-+---+--------+---------------+....+ +-------+-----......+ 744 | Token | | Options (E) | 745 +--------------------------------.....+ +-------+------.....+ 746 | Options (IU) | | OxFF | 747 . . +-------+-----------+ 748 . OSCORE Option . | | 749 +------+-------------------+ | Payload | 750 | 0xFF | | | 751 +------+------------+ +-------------------+ 752 | Ciphertext |<---------\ | 753 | | | v 754 +-------------------+ | +-----------------+ 755 | | | Inner SCHC | 756 v | | Compression | 757 +-----------------+ | +-----------------+ 758 | Outer SCHC | | | 759 | Compression | | v 760 +-----------------+ | +-------+ 761 | | |RuleID | 762 v | +-------+--+ 763 +--------+ +------------+ | Residue | 764 |RuleID' | | Encryption | <--- +----------+--------+ 765 +--------+--+ +------------+ | | 766 | Residue' | | Payload | 767 +-----------+-------+ | | 768 | Ciphertext | +-------------------+ 769 | | 770 +-------------------+ 772 Figure 8: OSCORE Compression Diagram 774 7.3. Example OSCORE Compression 776 An example is given with a GET Request and its consequent Content 777 Response from a device-based CoAP client to a cloud-based CoAP 778 server. A possible set of Rules for the Inner and Outer SCHC 779 Compression is shown. A dump of the results and a contrast between 780 SCHC + OSCORE performance with SCHC + COAP performance is also 781 listed. This gives an approximation to the cost of security with 782 SCHC-OSCORE. 784 Our first example CoAP message is the GET Request in Figure 9 786 Original message: 787 ================= 788 0x4101000182bb74656d7065726174757265 790 Header: 791 0x4101 792 01 Ver 793 00 CON 794 0001 tkl 795 00000001 Request Code 1 "GET" 797 0x0001 = mid 798 0x82 = token 800 Options: 801 0xbb74656d7065726174757265 802 Option 11: URI_PATH 803 Value = temperature 805 Original msg length: 17 bytes. 807 Figure 9: CoAP GET Request 809 Its corresponding response is the CONTENT Response in Figure 10. 811 Original message: 812 ================= 813 0x6145000182ff32332043 815 Header: 816 0x6145 817 01 Ver 818 10 ACK 819 0001 tkl 820 01000101 Successful Response Code 69 "2.05 Content" 822 0x0001 = mid 823 0x82 = token 825 0xFF Payload marker 826 Payload: 827 0x32332043 829 Original msg length: 10 831 Figure 10: CoAP CONTENT Response 833 The SCHC Rules for the Inner Compression include all fields that are 834 already present in a regular CoAP message. The methods described in 835 Section 4 applies to these fields. As an example, see Figure 11. 837 RuleID 0 838 +---------------+--+--+-----------+-----------+-----------++------+ 839 | Field |FP|DI| Target | MO | CDA || Sent | 840 | | | | Value | | ||[bits]| 841 +---------------+--+--+-----------+-----------+-----------++------+ 842 |CoAP Code | |up| 1 | equal |not-sent || | 843 |CoAP Code | |dw|[69,132] | match-map |match-sent || c | 844 |CoAP Uri-Path | |up|temperature| equal |not-sent || | 845 |COAP Option-End| |dw| 0xFF | equal |not-sent || | 846 +---------------+--+--+-----------+-----------+-----------++------+ 848 Figure 11: Inner SCHC Rules 850 Figure 12 shows the Plaintext obtained for our example GET Request 851 and follows the process of Inner Compression and Encryption until we 852 end up with the Payload to be added in the outer OSCORE Message. 854 In this case the original message has no payload and its resulting 855 Plaintext can be compressed up to only 1 byte (size of the RuleID). 856 The AEAD algorithm preserves this length in its first output, but 857 also yields a fixed-size tag which cannot be compressed and has to be 858 included in the OSCORE message. This translates into an overhead in 859 total message length, which limits the amount of compression that can 860 be achieved and plays into the cost of adding security to the 861 exchange. 863 ________________________________________________________ 864 | | 865 | OSCORE Plaintext | 866 | | 867 | 0x01bb74656d7065726174757265 (13 bytes) | 868 | | 869 | 0x01 Request Code GET | 870 | | 871 | bb74656d7065726174757265 Option 11: URI_PATH | 872 | Value = temperature | 873 |________________________________________________________| 875 | 876 | 877 | Inner SCHC Compression 878 | 879 v 880 _________________________________ 881 | | 882 | Compressed Plaintext | 883 | | 884 | 0x00 | 885 | | 886 | RuleID = 0x00 (1 byte) | 887 | (No residue) | 888 |_________________________________| 890 | 891 | AEAD Encryption 892 | (piv = 0x04) 893 v 894 _________________________________________________ 895 | | 896 | encrypted_plaintext = 0xa2 (1 byte) | 897 | tag = 0xc54fe1b434297b62 (8 bytes) | 898 | | 899 | ciphertext = 0xa2c54fe1b434297b62 (9 bytes) | 900 |_________________________________________________| 902 Figure 12: Plaintext compression and encryption for GET Request 904 In Figure 13 the process is repeated for the example CONTENT 905 Response. The residue is 1 bit long. Note that since SCHC adds 906 padding after the payload, this misalignment causes the hexadecimal 907 code from the payload to differ from the original, even though it has 908 not been compressed. 910 On top of this, the overhead from the tag bytes is incurred as 911 before. 913 ________________________________________________________ 914 | | 915 | OSCORE Plaintext | 916 | | 917 | 0x45ff32332043 (6 bytes) | 918 | | 919 | 0x45 Successful Response Code 69 "2.05 Content" | 920 | | 921 | ff Payload marker | 922 | | 923 | 32332043 Payload | 924 |________________________________________________________| 926 | 927 | 928 | Inner SCHC Compression 929 | 930 v 931 __________________________________________ 932 | | 933 | Compressed Plaintext | 934 | | 935 | 0x001919902180 (6 bytes) | 936 | | 937 | 00 RuleID | 938 | | 939 | 0b0 (1 bit match-map residue) | 940 | 0x32332043 >> 1 (shifted payload) | 941 | 0b0000000 Padding | 942 |__________________________________________| 944 | 945 | AEAD Encryption 946 | (piv = 0x04) 947 v 948 _________________________________________________________ 949 | | 950 | encrypted_plaintext = 0x10c6d7c26cc1 (6 bytes) | 951 | tag = 0xe9aef3f2461e0c29 (8 bytes) | 952 | | 953 | ciphertext = 0x10c6d7c26cc1e9aef3f2461e0c29 (14 bytes) | 954 |_________________________________________________________| 956 Figure 13: Plaintext compression and encryption for CONTENT Response 957 The Outer SCHC Rules (Figure 16) must process the OSCORE Options 958 fields. In Figure 14 and Figure 15 we show a dump of the OSCORE 959 Messages generated from our example messages once they have been 960 provided with the Inner Compressed Ciphertext in the payload. These 961 are the messages that have to be compressed by the Outer SCHC 962 Compression. 964 Protected message: 965 ================== 966 0x4102000182d8080904636c69656e74ffa2c54fe1b434297b62 967 (25 bytes) 969 Header: 970 0x4102 971 01 Ver 972 00 CON 973 0001 tkl 974 00000010 Request Code 2 "POST" 976 0x0001 = mid 977 0x82 = token 979 Options: 980 0xd8080904636c69656e74 (10 bytes) 981 Option 21: OBJECT_SECURITY 982 Value = 0x0904636c69656e74 983 09 = 000 0 1 001 Flag byte 984 h k n 985 04 piv 986 636c69656e74 kid 988 0xFF Payload marker 989 Payload: 990 0xa2c54fe1b434297b62 (9 bytes) 992 Figure 14: Protected and Inner SCHC Compressed GET Request 994 Protected message: 995 ================== 996 0x6144000182d008ff10c6d7c26cc1e9aef3f2461e0c29 997 (22 bytes) 999 Header: 1000 0x6144 1001 01 Ver 1002 10 ACK 1003 0001 tkl 1004 01000100 Successful Response Code 68 "2.04 Changed" 1006 0x0001 = mid 1007 0x82 = token 1009 Options: 1010 0xd008 (2 bytes) 1011 Option 21: OBJECT_SECURITY 1012 Value = b'' 1014 0xFF Payload marker 1015 Payload: 1016 0x10c6d7c26cc1e9aef3f2461e0c29 (14 bytes) 1018 Figure 15: Protected and Inner SCHC Compressed CONTENT Response 1020 For the flag bits, a number of compression methods has been shown to 1021 be useful depending on the application. The simplest alternative is 1022 to provide a fixed value for the flags, combining MO equal and CDA 1023 not- sent. This saves most bits but could prevent flexibility. 1024 Otherwise, match-mapping could be used to choose from an interested 1025 number of configurations to the exchange. Otherwise, MSB could be 1026 used to mask off the 3 hard-coded most significant bits. 1028 Note that fixing a flag bit will limit the choice of CoAP Options 1029 that can be used in the exchange, since their values are dependent on 1030 certain options. 1032 The piv field lends itself to having a number of bits masked off with 1033 MO MSB and CDA LSB. This could be useful in applications where the 1034 message frequency is low such as that found in LPWAN technologies. 1035 Note that compressing the sequence numbers effectively reduces the 1036 maximum amount of sequence numbers that can be used in an exchange. 1037 Once this amount is exceeded, the OSCORE keys need to be re- 1038 established. 1040 The size s included in the kid context field MAY be masked off with 1041 CDA MSB. The rest of the field could have additional bits masked 1042 off, or have the whole field be fixed with MO equal and CDA not-sent. 1043 The same holds for the kid field. 1045 Figure 16 shows a possible set of Outer Rules to compress the Outer 1046 Header. 1048 RuleID 0 1049 +-------------------+--+--+--------------+--------+---------++------+ 1050 | Field |FP|DI| Target | MO | CDA || Sent | 1051 | | | | Value | | ||[bits]| 1052 +-------------------+--+--+--------------+--------+---------++------+ 1053 |CoAP version | |bi| 01 |equal |not-sent || | 1054 |CoAP Type | |up| 0 |equal |not-sent || | 1055 |CoAP Type | |dw| 2 |equal |not-sent || | 1056 |CoAP TKL | |bi| 1 |equal |not-sent || | 1057 |CoAP Code | |up| 2 |equal |not-sent || | 1058 |CoAP Code | |dw| 68 |equal |not-sent || | 1059 |CoAP MID | |bi| 0000 |MSB(12) |LSB ||MMMM | 1060 |CoAP Token | |bi| 0x80 |MSB(5) |LSB ||TTT | 1061 |CoAP OSCORE_flags | |up| 0x09 |equal |not-sent || | 1062 |CoAP OSCORE_piv | |up| 0x00 |MSB(4) |LSB ||PPPP | 1063 |COAP OSCORE_kid | |up|0x636c69656e70|MSB(52) |LSB ||KKKK | 1064 |COAP OSCORE_kidctxt| |bi| b'' |equal |not-sent || | 1065 |CoAP OSCORE_flags | |dw| b'' |equal |not-sent || | 1066 |CoAP OSCORE_piv | |dw| b'' |equal |not-sent || | 1067 |CoAP OSCORE_kid | |dw| b'' |equal |not-sent || | 1068 |COAP Option-End | |dw| 0xFF |equal |not-sent || | 1069 +-------------------+--+--+--------------+--------+---------++------+ 1071 Figure 16: Outer SCHC Rules 1073 These Outer Rules are applied to the example GET Request and CONTENT 1074 Response. The resulting messages are shown in Figure 17 and 1075 Figure 18. 1077 Compressed message: 1078 ================== 1079 0x001489458a9fc3686852f6c4 (12 bytes) 1080 0x00 RuleID 1081 1489 Compression Residue 1082 458a9fc3686852f6c4 Padded payload 1084 Compression Residue: 1085 0b 0001 010 0100 0100 (15 bits -> 2 bytes with padding) 1086 mid tkn piv kid 1088 Payload 1089 0xa2c54fe1b434297b62 (9 bytes) 1091 Compressed message length: 12 bytes 1093 Figure 17: SCHC-OSCORE Compressed GET Request 1095 Compressed message: 1096 ================== 1097 0x0014218daf84d983d35de7e48c3c1852 (16 bytes) 1098 0x00 RuleID 1099 14 Compression Residue 1100 218daf84d983d35de7e48c3c1852 Padded payload 1101 Compression Residue: 1102 0b0001 010 (7 bits -> 1 byte with padding) 1103 mid tkn 1105 Payload 1106 0x10c6d7c26cc1e9aef3f2461e0c29 (14 bytes) 1108 Compressed msg length: 16 bytes 1110 Figure 18: SCHC-OSCORE Compressed CONTENT Response 1112 For contrast, we compare these results with what would be obtained by 1113 SCHC compressing the original CoAP messages without protecting them 1114 with OSCORE. To do this, we compress the CoAP messages according to 1115 the SCHC Rules in Figure 19. 1117 RuleID 1 1118 +---------------+--+--+-----------+---------+-----------++--------+ 1119 | Field |FP|DI| Target | MO | CDA || Sent | 1120 | | | | Value | | || [bits] | 1121 +---------------+--+--+-----------+---------+-----------++--------+ 1122 |CoAP version | |bi| 01 |equal |not-sent || | 1123 |CoAP Type | |up| 0 |equal |not-sent || | 1124 |CoAP Type | |dw| 2 |equal |not-sent || | 1125 |CoAP TKL | |bi| 1 |equal |not-sent || | 1126 |CoAP Code | |up| 2 |equal |not-sent || | 1127 |CoAP Code | |dw| [69,132] |match-map|map-sent ||C | 1128 |CoAP MID | |bi| 0000 |MSB(12) |LSB ||MMMM | 1129 |CoAP Token | |bi| 0x80 |MSB(5) |LSB ||TTT | 1130 |CoAP Uri-Path | |up|temperature|equal |not-sent || | 1131 |COAP Option-End| |dw| 0xFF |equal |not-sent || | 1132 +---------------+--+--+-----------+---------+-----------++--------+ 1134 Figure 19: SCHC-CoAP Rules (No OSCORE) 1136 This yields the results in Figure 20 for the Request, and Figure 21 1137 for the Response. 1139 Compressed message: 1140 ================== 1141 0x0114 1142 0x01 = RuleID 1144 Compression Residue: 1145 0b00010100 (1 byte) 1147 Compressed msg length: 2 1149 Figure 20: CoAP GET Compressed without OSCORE 1151 Compressed message: 1152 ================== 1153 0x010a32332043 1154 0x01 = RuleID 1156 Compression Residue: 1157 0b00001010 (1 byte) 1159 Payload 1160 0x32332043 1162 Compressed msg length: 6 1164 Figure 21: CoAP CONTENT Compressed without OSCORE 1166 As can be seen, the difference between applying SCHC + OSCORE as 1167 compared to regular SCHC + COAP is about 10 bytes of cost. 1169 8. IANA Considerations 1171 This document has no request to IANA. 1173 9. Security considerations 1175 The Security Considerations of SCHC header compression RFC8724 are 1176 valid for SCHC CoAP header compression. When CoAP uses OSCORE, the 1177 security considerations defined in RFC8613 does not change when SCHC 1178 header compression is applied. 1180 The definition of SCHC over CoAP header fields permits the 1181 compression of header information only. The SCHC header compression 1182 itself does not increase or reduce the level of security in the 1183 communication. When the communication does not use any security 1184 protocol as OSCORE, DTLS, or other. It is highly necessary to use a 1185 layer two security. 1187 DoS attacks are possible if an intruder can introduce a compressed 1188 SCHC corrupted packet onto the link and cause a compression 1189 efficiency reduction. However, an intruder having the ability to add 1190 corrupted packets at the link layer raises additional security issues 1191 than those related to the use of header compression. 1193 SCHC compression returns variable-length Residues for some CoAP 1194 fields. In the compressed header, the length sent is not the 1195 original header field length but the length of the Residue. So if a 1196 corrupted packet comes to the decompressor with a longer or shorter 1197 length than the one in the original header, SCHC decompression will 1198 detect an error and drops the packet. 1200 OSCORE compression is also based on the same compression method 1201 described in [rfc8724]. The size of the Initialisation Vector (IV) 1202 residue size must be considered carefully. A too large value has an 1203 impact on the compression efficiency and a too small value will force 1204 the device to renew its key more often. This operation may be long 1205 and energy consuming. The size of the compressed IV MUST be choosen 1206 regarding the highest expected traffic from the device. 1208 SCHC header and compression Rules MUST remain tightly coupled. 1209 Otherwise, an encrypted residue may be decompressed in a different 1210 way by the receiver. To avoid this situation, if the Rule is 1211 modified in one location, the OSCORE keys MUST be re-established. 1213 10. Acknowledgements 1215 The authors would like to thank (in alphabetic order): Christian 1216 Amsuss, Dominique Barthel, Carsten Bormann, Theresa Enghardt, Thomas 1217 Fossati, Klaus Hartke, Francesca Palombini, Alexander Pelov and Goran 1218 Selander. 1220 11. Normative References 1222 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 1223 Requirement Levels", BCP 14, RFC 2119, 1224 DOI 10.17487/RFC2119, March 1997, 1225 . 1227 [rfc7252] Shelby, Z., Hartke, K., and C. Bormann, "The Constrained 1228 Application Protocol (CoAP)", RFC 7252, 1229 DOI 10.17487/RFC7252, June 2014, 1230 . 1232 [rfc7641] Hartke, K., "Observing Resources in the Constrained 1233 Application Protocol (CoAP)", RFC 7641, 1234 DOI 10.17487/RFC7641, September 2015, 1235 . 1237 [rfc7959] Bormann, C. and Z. Shelby, Ed., "Block-Wise Transfers in 1238 the Constrained Application Protocol (CoAP)", RFC 7959, 1239 DOI 10.17487/RFC7959, August 2016, 1240 . 1242 [rfc7967] Bhattacharyya, A., Bandyopadhyay, S., Pal, A., and T. 1243 Bose, "Constrained Application Protocol (CoAP) Option for 1244 No Server Response", RFC 7967, DOI 10.17487/RFC7967, 1245 August 2016, . 1247 [rfc8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC 1248 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, 1249 May 2017, . 1251 [rfc8613] Selander, G., Mattsson, J., Palombini, F., and L. Seitz, 1252 "Object Security for Constrained RESTful Environments 1253 (OSCORE)", RFC 8613, DOI 10.17487/RFC8613, July 2019, 1254 . 1256 [rfc8724] Minaburo, A., Toutain, L., Gomez, C., Barthel, D., and JC. 1257 Zuniga, "SCHC: Generic Framework for Static Context Header 1258 Compression and Fragmentation", RFC 8724, 1259 DOI 10.17487/RFC8724, April 2020, 1260 . 1262 Appendix A. Extension to the RFC8724 Annex D. 1264 This section extends the RFC8724 Annex D list. 1266 o How to establish the End-to-End context initialization using SCHC 1267 for CoAP header only. 1269 Authors' Addresses 1271 Ana Minaburo 1272 Acklio 1273 1137A avenue des Champs Blancs 1274 35510 Cesson-Sevigne Cedex 1275 France 1277 Email: ana@ackl.io 1279 Laurent Toutain 1280 Institut MINES TELECOM; IMT Atlantique 1281 2 rue de la Chataigneraie 1282 CS 17607 1283 35576 Cesson-Sevigne Cedex 1284 France 1286 Email: Laurent.Toutain@imt-atlantique.fr 1287 Ricardo Andreasen 1288 Universidad de Buenos Aires 1289 Av. Paseo Colon 850 1290 C1063ACV Ciudad Autonoma de Buenos Aires 1291 Argentina 1293 Email: randreasen@fi.uba.ar