]> RISE AB

Isafjordsgatan 22 Kista 16440 Sweden marco.tiloca@ri.se

IMT Atlantique

CS 17607, 2 rue de la Chataigneraie Cesson-Sevigne Cedex 35576 France Laurent.Toutain@imt-atlantique.fr

Nokia Bell Labs

12 Rue Jean Bart Massy 91300 France ivan.martinez_bolivar@nokia-bell-labs.com

Consultant

Rue de Rennes Cesson-Sevigne 35510 France anaminaburo@gmail.com

Internet SCHC Working Group Internet-Draft This document clarifies, updates and extends the method specified in RFC 8824 for compressing Constrained Application Protocol (CoAP) headers using the Static Context Header Compression and fragmentation (SCHC) framework. In particular, it considers recently defined CoAP options and specifies how CoAP headers are compressed in the presence of intermediaries. Therefore, this document updates RFC 8824. Discussion Venues Discussion of this document takes place on the Static Context Header Compression Working Group mailing list (schc@ietf.org), which is archived at . Source for this draft and an issue tracker can be found at .

Introduction The Constrained Application Protocol (CoAP) is a web-transfer protocol intended for applications based on the REST (Representational State Transfer) paradigm, and designed to be affordable also for resource-constrained devices. In order to enable the use of CoAP in LPWANs (Low-Power Wide-Area Networks) as well as to improve performance, defines how to use the Static Context Header Compression and fragmentation (SCHC) framework for compressing CoAP headers. This document clarifies, updates and extends the SCHC compression of CoAP headers defined in at the application level, by: providing specific clarifications; updating specific details of the compression processing, based on recent developments related to the security protocol OSCORE for end-to-end protection of CoAP messages; and extending the compression processing to take into account additional CoAP options and the presence of CoAP proxies. In particular, this document updates as follows.

• It clarifies the SCHC compression for the CoAP options Size1, Size2, Proxy-Uri and Proxy-Scheme (see ).
• It defines the SCHC compression for the CoAP option Hop-Limit (see ).
• It defines the SCHC compression for the recently defined CoAP options Echo (see ), Request-Tag (see ), EDHOC (see ), as well as Q-Block1 and Q-Block2 (see ).
• It updates the SCHC compression processing for the CoAP option OSCORE (see ), in the light of recent developments related to the security protocol OSCORE as defined in and .
• It clarifies how the SCHC compression handles the CoAP payload marker (see ).
• It defines the SCHC compression of CoAP headers in the presence of CoAP proxies (see ).

This document does not alter the core approach, design choices and features of the SCHC compression applied to CoAP headers.

Terminology The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in BCP 14 when, and only when, they appear in all capitals, as shown here. Readers are expected to be familiar with the terms and concepts related to the SCHC framework , the web-transfer protocol CoAP , the security protocol OSCORE and the use of SCHC for CoAP .

CoAP Options This section updates and extends , as to how SCHC compresses some specific CoAP options. In particular, updates .

CoAP Option Size1, Size2, Proxy-Uri, and Proxy-Scheme Fields The SCHC Rule description MAY define sending some field values by not setting the TV, while setting the MO to "ignore" and the CDA to "value-sent". A Rule MAY also use a "match-mapping" MO when there are different options for the same FID. Otherwise, the Rule sets the TV to the value, the MO to "equal", and the CDA to "not-sent".

CoAP Option Hop-Limit Field The Hop-Limit field is an option defined in that can be used to detect forwarding loops through a chain of CoAP proxies. The first proxy in the chain that understands the option includes it in a received request with a proper value set, before forwarding the request. Any following proxy that understands the option decrements the option value and forwards the request if the new value is different than zero, or returns a 5.08 (Hop Limit Reached) error response otherwise. When a packet uses the Hop-Limit option, SCHC compression SHOULD send its content in the Compression Residue. That is, in the SCHC Rule, the TV is not set, while the MO is set to "ignore", and the CDA is set to "value-sent". As an exception, and consistently with the default value 16 defined for the Hop-Limit option in , a Rule MAY describe a TV with value 16, with the MO set to "equal" and the CDA set to "not-sent".

CoAP Option Echo Field The Echo field is an option defined in that a server can include in a response as a challenge to the client, and that the client echoes back to the server in one or more requests. This enables the server to verify the freshness of a request and to cryptographically verify the aliveness of the client. Also, it forces the client to demonstrate reachability at its claimed network address. When a packet uses the Echo option, SCHC compression SHOULD send its content in the Compression Residue. That is, in the SCHC Rule, the TV is not set, while the MO is set to "ignore", and the CDA is set to "value-sent". An exception applies in case the server generates the values to use for the Echo option by means of a persistent counter (see ). In such a case, a Rule MAY use the "MSB" MO and the "LSB" CDA. This would be effectively applicable until the persistent counter at the server becomes greater than the maximum threshold value that produces an MSB-matching.

CoAP Option Request-Tag Field The Request-Tag field is an option defined in that the client can set in request messages of block-wise operations, with value an ephemeral short-lived identifier of the specific block-wise operation in question. This allows the server to match message fragments belonging to the same request operation and, if the server supports it, to reliably process simultaneous block-wise request operations on a single resource. If requests are integrity protected, this also protects against interchange of fragments between different block-wise request operations. When a packet uses the Request-Tag option, SCHC compression MAY send its content in the Compression Residue. That is, in the SCHC Rule, the TV is not set, while the MO is set to "ignore", and the CDA is set to "value-sent". Alternatively, if a pre-defined set of Request-Tag values used by the client is known, a Rule MAY use a "match-mapping" MO when there are different options for the same FID.

CoAP Option EDHOC Field The EDHOC field is an option defined in that a client can include in a request, in order to perform an optimized, shortened execution of the authenticated key establishment protocol EDHOC . Such a request conveys both the final EDHOC message and actual application data, where the latter is protected with OSCORE using a Security Context derived from the result of the current EDHOC execution. The option occurs at most once and is always empty. The SCHC Rule MUST describe an empty TV, with the MO set to "equal" and the CDA set to "not-sent".

SCHC Compression of CoAP Extensions This section updates and extends , as to how SCHC compresses some specific CoAP options providing protocol extensions. In particular, updates , while updates .

Block When a packet uses a Block1 or Block2 option or a Q-Block1 or Q-Block2 option , SCHC compression MUST send its content in the Compression Residue. In the SCHC Rule, the TV is not set, while the MO is set to "ignore" and the CDA is set to "value-sent". The Block1, Block2, Q-Block1 and Q-Block2 options allow fragmentation at the CoAP level that is compatible with SCHC fragmentation. Both fragmentation mechanisms are complementary, and the node may use them for the same packet as needed.

OSCORE The security protocol OSCORE provides end-to-end protection for CoAP messages. Group OSCORE builds on OSCORE and defines end-to-end protection of CoAP messages in group communication . This section describes how SCHC Rules can be applied to compress messages protected with OSCORE or Group OSCORE. shows the OSCORE option value encoding, which was originally defined in and has been extended in . The first byte of the OSCORE option value specifies the content of the OSCORE option using flags, as follows.

• As defined in , the eight least significant bit, when set, indicates that the OSCORE option includes a second byte of flags. The seventh least significant bit is currently unassigned.
• As defined in , the sixth least significant bit, when set, indicates that the message including the OSCORE option is protected with the group mode of Group OSCORE (see ). When not set, the bit indicates that the message is protected either with OSCORE, or with the pairwise mode of Group OSCORE (see ), while the specific OSCORE Security Context used to protect the message determines which of the two cases applies.
• As defined in , bit h, when set, indicates the presence of the kid context field in the option. Also, bit k, when set, indicates the presence of a kid field. Finally, the three least significant bits form the field n, which indicates the length of the piv (Partial Initialization Vector) field in bytes. When n = 0, no piv is present.

Assuming the presence of a single flag byte, this is followed by the piv field, the kid context field, and the kid field, in that order. Also, if present, the kid context field's length (in bytes) is encoded in the first byte, denoted by "s".

OSCORE Option +-+-+-+-+-+-+-+-+---------------------------------+ |0 0 0|h|k| n | Partial IV (if any) | +-+-+-+-+-+-+-+-+---------------------------------+ | | | |<-- CoAP -->|<------- CoAP OSCORE_piv ------> | OSCORE_flags <-- 1 byte --> <------ s bytes -----> +--------------+----------------------+-----------------------+ | s (if any) | kid context (if any) | kid (if any) ... | +--------------+----------------------+-----------------------+ | | | |<-------- CoAP OSCORE_kidctx ------->|<-- CoAP OSCORE_kid -->| ]]>

shows the OSCORE option value encoding, with the second byte of flags also present. As defined in , the least significant bit d of this byte, when set, indicates that two additional fields are included in the option, following the kid context field (if any). These two fields, namely x and nonce, are used when running the key update protocol KUDOS defined in , with x specifying the length of the nonce field in bytes as well as the specific behavior to adopt during the KUDOS execution. In particular, the figure provides the breakdown of the x field, where its three least significant bits form the sub-field m, which specifies the size of nonce in bytes, minus 1.

OSCORE Option during a KUDOS execution +-+-+-+-+-+-+-+-+---+---+---+---+---+---+---+---+---------------------+ |1|0|0|h|k| n | 0 | 0 | 0 | 0 | 0 | 0 | 0 | d | Partial IV (if any) | +-+-+-+-+-+-+-+-+---+---+---+---+---+---+---+---+---------------------+ | | | |<------------------- CoAP -------------------->|<- CoAP OSCORE_piv ->| OSCORE_flags <- 1 byte -> <----------- s bytes ------------> <------ 1 byte -----> +------------+----------------------------------+---------------------+ | s (if any) | kid context (if any) | x (if any) | +------------+----------------------------------+---------------------+ | | | |<------------- CoAP OSCORE_kidctx ------------>|<-- CoAP OSCORE_x -->| | | | 0 1 2 3 4 5 6 7 | | +-+-+-+-+-+-+-+-+ | | |0|0|b|p| m | | | +-+-+-+-+-+-+-+-+ | <----- m + 1 bytes -----> +-------------------------+-----------------------+ | nonce (if any) | kid (if any) ... | +-------------------------+-----------------------+ | | | |<-- CoAP OSCORE_nonce -->|<-- CoAP OSCORE_kid -->| ]]>

To better perform OSCORE SCHC compression, the Rule description needs to identify the OSCORE option and the fields it contains. Conceptually, it discerns up to six distinct pieces of information within the OSCORE option: the flag bits, the piv, the kid context, the x byte, the nonce, and the kid. The SCHC Rule splits the OSCORE option into six Field Descriptors in order to compress them:

• CoAP OSCORE_flags
• CoAP OSCORE_piv
• CoAP OSCORE_kidctx
• CoAP OSCORE_x
• CoAP OSCORE_nonce
• CoAP OSCORE_kid

shows the OSCORE option format with the four fields OSCORE_flags, OSCORE_piv, OSCORE_kidctx and OSCORE_kid superimposed on it. Also, shows the OSCORE option format with all the six fields superimposed on it, with reference to a message exchanged during an execution of the KUDOS key update protocol. In both cases, the CoAP OSCORE_kidctx field directly includes the size octet, s. In the latter case, the following applies.

• For the x field, if both endpoints know the value, then the SCHC Rule will describe a TV to this value, with the MO set to "equal" and the CDA set to "not-sent". This models the case where the two endpoints run KUDOS with a pre-agreed size of the nonce field, as well as with a pre-agreed combination of its modes of operations, as per the bits b and p of the m sub-field. Otherwise, if the value is changing over time, the SCHC Rule will set the MO to "ignore" and the CDA to "value-sent". The Rule may also use a "match-mapping" MO to compress this field, in case the two endpoints pre-agree on a set of alternative ways to run KUDOS, with respect to the size of the nonce field and the combination of the KUDOS modes of operation to use.
• For the nonce field, the SCHC Rule has the TV not set, while the MO is set to "ignore" and the CDA is set to "value-sent". In addition, for the value of the nonce field, SCHC MUST NOT send it as variable-length data in the Compression Residue, to avoid ambiguity with the length of the nonce field encoded in the x field. Therefore, SCHC MUST use the m sub-field of the x field to define the size of the Compression Residue. SCHC designates a specific function, "osc.x.m", that the Rule MUST use to complete the Field Descriptor. During the decompression, this function returns the length of the nonce field in bytes, as the value of the three least significant bits of the m sub-field of the x field, plus 1.

Compression of the CoAP Payload Marker As originally intended in , the following applies with respect to the 0xFF payload marker. A SCHC compression Rule for CoAP includes all the expected CoAP options, therefore the payload marker does not have to be specified.

Without End-to-End Security If the CoAP message to compress with SCHC is not going to be protected with OSCORE and includes a payload, then the 0xFF payload marker MUST NOT be included in the compressed message, which is composed of the Compression RuleID, the Compression Residue (if any), and the CoAP payload. After having decompressed an incoming message, the recipient endpoint MUST prepend the 0xFF payload marker to the CoAP payload, if any was present after the consumed Compression Residue.

With End-to-End Security If the CoAP message has to be protected with OSCORE, the same rationale described in applies to both the Inner SCHC Compression and the Outer SCHC Compression defined in . That is:

• After the Inner SCHC Compression of a CoAP message including a payload, the payload marker MUST NOT be included in the input to the AEAD Encryption, which is composed of the Inner Compression RuleID, the Inner Compression Residue (if any), and the CoAP payload.
• The Outer SCHC Compression takes as input the OSCORE-protected message, which always includes a payload (i.e., the OSCORE Ciphertext) preceded by the payload marker.
• After the Outer SCHC Compression, the payload marker MUST NOT be included in the final compressed message, which is composed of the Outer Compression RuleID, the Outer Compression Residue (if any), and the OSCORE Ciphertext.

After having completed the Outer SCHC Decompression of an incoming message, the recipient endpoint MUST prepend the 0xFF payload marker to the OSCORE Ciphertext. After having completed the Inner SCHC Decompression of an incoming message, the recipient endpoint MUST prepend the 0xFF payload marker to the CoAP payload, if any was present after the consumed Compression Residue.

CoAP Header Compression with Proxies Building on , this section clarifies how SCHC Compression/Decompression is performed when CoAP proxies are deployed. The following refers to the origin client and origin server as application endpoints. Note that SCHC Compression/Decompression of CoAP headers is not necessarily used between each pair of hops in the communication chain. For example, if a proxy is deployed between an origin client and an origin server, SCHC might be used on the communication leg between the origin client and the proxy, but not on the communication leg between the proxy and the origin server.

Without End-to-End Security In case OSCORE is not used end-to-end between client and server, the SCHC processing occurs hop-by-hop, by relying on SCHC Rules that are consistently shared between two adjacent hops. In particular, SCHC is used as defined below.

• The sender application endpoint compresses the CoAP message, by using the SCHC Rules that it shares with the next hop towards the recipient application endpoint. The resulting, compressed message is sent to the next hop towards the recipient application endpoint.
• Each proxy decompresses the incoming compressed message, by using the SCHC Rules that it shares with the (previous hop towards the) sender application endpoint. Then, the proxy compresses the CoAP message to be forwarded, by using the SCHC Rules that it shares with the (next hop towards the) recipient application endpoint. The resulting, compressed message is sent to the (next hop towards the) recipient application endpoint.
• The recipient application endpoint decompresses the incoming compressed message, by using the SCHC Rules that it shares with the previous hop towards the sender application endpoint.

With End-to-End Security In case OSCORE is used end-to-end between client and server (see ), the following applies. The SCHC processing occurs end-to-end as to the Inner SCHC Compression/Decompression, by relying on Inner SCHC Rules that are consistently shared between the two application endpoints acting as OSCORE endpoints and sharing the used OSCORE Security Context. Instead, the SCHC processing occurs hop-by-hop as to the Outer SCHC Compression/Decompression, by relying on Outer SCHC Rules that are consistently shared between two adjacent hops. In particular, SCHC is used as defined below.

• The sender application endpoint performs the Inner SCHC Compression on the original CoAP message, by using the Inner SCHC Rules that it shares with the recipient application endpoint. Following the AEAD Encryption of the compressed input obtained from the previous step, the sender application endpoint performs the Outer SCHC Compression on the resulting OSCORE-protected message, by using the Outer SCHC Rules that it shares with the next hop towards the recipient application endpoint. The resulting, compressed message is sent to the next hop towards the recipient application endpoint.
• Each proxy performs the Outer SCHC Decompression on the incoming compressed message, by using the SCHC Rules that it shares with the (previous hop towards the) sender application endpoint. Then, the proxy performs the Outer SCHC Compression of the OSCORE-protected message to be forwarded, by using the SCHC Rules that it shares with the (next hop towards the) recipient application endpoint. The resulting, compressed message is sent to the (next hop towards the) recipient application endpoint.
• The recipient application endpoint performs the Outer SCHC Decompression on the incoming compressed message, by using the Outer SCHC Rules that it shares with the previous hop towards the sender application endpoint. Then, the recipient application endpoint performs the AEAD Decryption of the OSCORE-protected message obtained from the previous step. Finally, the recipient application endpoint performs the Inner SCHC Decompression on the compressed input obtained from the previous step, by using the Inner SCHC Rules that it shares with the sender application endpoint. The result is the original CoAP message produced by the sender application endpoint.

Examples of CoAP Header Compression with Proxies This section provides examples of SCHC Compression/Decompression in the presence of a CoAP proxy. The presented examples refer to the same deployment considered in , including a Device communicating over LPWAN with a Network Gateway (NGW), which in turn communicates with an Application Server over the Internet. The Application Server and the Device exchange CoAP messages through the NGW. In addition, the following also applies in the presented examples.

• CoAP request messages are sent only by the Device as targeting the Application Server (uplink traffic), which replies to the Device with corresponding CoAP response messages (downlink traffic). That is, the Device acts as CoAP client, while the Application Server acts as CoAP server.
• A CoAP proxy is co-located on the Network Gateway (NGW) deployed between the Application Server and the Device.
• SCHC is used also on the communication leg between the Application Server and the proxy.

Like , the presented examples focus on SCHC Compression/Decompression of CoAP headers, i.e., irrespective of possible SCHC Compression/Decompression applied to further protocol headers. The example in considers an exchange of two unprotected messages, while the example in considers an exchange of two messages protected end-to-end with OSCORE. In the examples, the character | denotes bit concatenation. and show the two CoAP messages exchanged between the Device and the Application Server, via the proxy. The figures show the two messages as originally generated by the application at the two origin endpoints, i.e., before they are possibly protected end-to-end with OSCORE as considered by the example in . In particular, note that:

• On the communication leg between the Device and the proxy, the CoAP Message ID has value 0x0001 and the CoAP Token has value 0x82.
• On the communication leg between the proxy and the Application Server, the CoAP Message ID has value 0x0004 and the CoAP Token has value 0x75.

CoAP GET Request

CoAP Content Response

Without End-to-End Security In case OSCORE is not used end-to-end between the Device and the Application Server, the following SCHC Rules are shared between the different entities. Based on those Rules, the SCHC Compression/Decompression is performed as per . The Device and the proxy share the SCHC Rule shown in , with RuleID 0.

SCHC Rule between the Device and the Proxy

Instead, the proxy and the Application Server share the SCHC Rule shown in , with RuleID 1.

SCHC Rule between the Proxy and the Application Server

First, the Device applies the Rule in shared with the proxy to the CoAP request in . The result is the compressed CoAP request in , which the Device sends to the proxy.

CoAP GET Request Compressed for the Proxy 13 bytes with padding) 0b 00 0001 010 1011 | 0x6578616d706c652e636f6d code mid tkn Uri-Host (residue size and residue) Compressed message length: 14 bytes ]]>

Upon receiving the message in , the proxy decompresses it with the Rule in shared with the Device, and obtains the same CoAP request in . After that, the proxy removes the Proxy-Scheme Option from the decompressed CoAP request. Also, the proxy replaces the values of the CoAP Message ID and of the CoAP Token to 0x0004 and 0x75, respectively. The result is the CoAP request shown in .

CoAP GET Request to be Compressed by the Proxy

Then, the proxy applies the Rule in shared with the Application Server to the CoAP request in . The result is the compressed CoAP request in , which the proxy forwards to the Application Server.

CoAP GET Request Forwarded by the Proxy 13 bytes with padding) 0b 00 0100 101 1011 | 0x6578616d706c652e636f6d code mid tkn Uri-Host (residue size and residue) Compressed message length: 14 bytes ]]>

Upon receiving the message in , the Application Server decompresses it using the Rule in shared with the proxy. The result is the same CoAP request in , which the Application Server delivers to the application. After that, the Application Server produces the CoAP response in , and compresses it using the Rule in shared with the proxy. The result is the compressed CoAP response shown in , which the Application Server sends to the proxy.

CoAP Content Response Compressed for the Proxy 2 bytes with padding) 0b 1 10 0100 101 type code mid tkn Payload 0x32332043 (4 bytes) Compressed message length: 7 bytes ]]>

Upon receiving the message in , the proxy decompresses it using the Rule in shared with the Application Server. The result is the same CoAP response in . Then, the proxy replaces the values of the CoAP Message ID and of the CoAP Token to 0x0001 and 0x82, respectively. The result is the CoAP response shown in .

CoAP Content Response to be Compressed by the Proxy

Then, the proxy compresses the CoAP response in with the Rule in shared with the Device. The result is the compressed CoAP response shown in , which the proxy forwards to the Device.

CoAP Content Response Forwarded by the Proxy 2 bytes with padding) 0b 1 10 0001 010 type code mid tkn Payload 0x32332043 (4 bytes) Compressed message length: 7 bytes ]]>

Upon receiving the message in , the Device decompresses it using the Rule in shared with the proxy. The result is the same CoAP request in , which the Device delivers to the application.

With End-to-End Security In case OSCORE is used end-to-end between the Device and the Application Server, the following SCHC Rules are shared between the different entities. Based on those Rules, the SCHC Compression/Decompression is performed as per . The Device and the Application Server share the SCHC Rule shown in , with RuleID 2. The Device and the Application Server use this Rule to perform the Inner SCHC Compression/Decompression end-to-end.

Inner SCHC Rule between the Device and the Application Server

The Device and the proxy share the SCHC Rule shown in , with RuleID 3. The Device and the proxy use this Rule to perform the Outer SCHC Compression/Decompression hop-by-hop on their communication leg.

Outer SCHC Rule between the Device and the Proxy

The proxy and the Application Server share the SCHC Rule shown in , with RuleID 4. The proxy and the Application Server use this Rule to perform the Outer SCHC Compression/Decompression hop-by-hop on their communication leg.

Outer SCHC Rule between the Proxy and the Application Server

When the Device applies the Rule in shared with the Application Server to the CoAP request in , this results in the Compressed Plaintext shown in . As per , the message follows the process of SCHC Inner Compression and encryption until the payload (if any). The ciphertext resulting from the overall Inner process is used as payload of the Outer OSCORE message.

Plaintext Compression and Encryption for the GET Request

When the Application Server applies the Rule in shared with the Device to the CoAP response in , this results in the Compressed Plaintext shown in . As per , the message follows the process of SCHC Inner Compression and encryption until the payload (if any). The ciphertext resulting from the overall Inner process is used as payload of the Outer OSCORE message.

Plaintext Compression and Encryption for the Content Response > 2 (shifted payload) | | 0b000000 Padding | |_________________________________________________| | | AEAD Encryption | (piv = 0x04) | v _________________________________________________________ | | | encrypted_plaintext = 0x10c6d7c26cc1 (6 bytes) | | tag = 0xe9aef3f2461e0c29 (8 bytes) | | | | ciphertext = 0x10c6d7c26cc1e9aef3f2461e0c29 (14 bytes) | |_________________________________________________________| ]]>

After having performed the SCHC Inner Compression of the CoAP request in , the Device protects it with OSCORE by considering the Compressed Plaintext in . The result is the OSCORE-protected CoAP request shown in .

Protected and Inner SCHC Compressed CoAP GET Request

Then, the Device applies the Rule in shared with the proxy to the OSCORE-protected CoAP request in , thus performing the SCHC Outer Compression of such request. The result is the OSCORE-protected and Outer Compressed CoAP request shown in , which the Device sends to the proxy.

SCHC-OSCORE CoAP GET Request Compressed for the Proxy 14 bytes with padding) 0b 0001 010 1011 | 0x6578616d706c652e636f6d | 0b 0100 0101 mid tkn Uri-Host (residue size and residue) piv kid Payload 0xa2cfc54fe1b434297b62 (10 bytes) Compressed message length: 25 bytes ]]>

Upon receiving the message in , the proxy decompresses it with the Rule in shared with the Device, thus performing the SCHC Outer Decompression. The result is the same OSCORE-protected CoAP request in . After that, the proxy removes the Proxy-Scheme Option from the decompressed OSCORE-protected CoAP request. Also, the proxy replaces the values of the CoAP Message ID and of the CoAP Token to 0x0004 and 0x75, respectively. The result is the OSCORE-protected CoAP request shown in .

SCHC-OSCORE CoAP GET Request to be Compressed by the Proxy

Then, the proxy applies the Rule in shared with the Application Server to the OSCORE-protected CoAP request in , thus performing the SCHC Outer Compression of such request. The result is the OSCORE-protected and Outer Compressed CoAP request shown in , which the proxy forwards to the Application Server.

SCHC-OSCORE CoAP GET Request Forwarded by the Proxy 14 bytes with padding) 0b 0100 101 1011 | 0x6578616d706c652e636f6d | 0b 0100 0101 mid tkn Uri-Host (residue size and residue) piv kid Payload 0xa2cfc54fe1b434297b62 (10 bytes) Compressed message length: 25 bytes ]]>

Upon receiving the message in , the Application Server decompresses it using the Rule in shared with the proxy, thus performing the SCHC Outer Decompression. The result is the same OSCORE-protected CoAP request in . The Application Server decrypts and verifies such a request, which results in the same Compressed Plaintext in . Then, the Application Server applies the Rule in shared with the Device to such a Compressed Plaintext, thus performing the SCHC Inner Decompression. The result is used to rebuild the same CoAP request in , which the Application Server delivers to the application. After having performed the SCHC Inner Compression of the CoAP response in , the Application Server protects it with OSCORE by considering the Compressed Plaintext in . The result is the OSCORE-protected CoAP response shown in .

Protected and Inner SCHC Compressed CoAP Content Response

Then, the Application Server applies the Rule in shared with the proxy to the OSCORE-protected CoAP response in , thus performing the SCHC Outer Compression of such response. The result is the OSCORE-protected and Outer Compressed CoAP response shown in , which the Application Server sends to the proxy.

SCHC-OSCORE CoAP Content Response Compressed for the Proxy 1 byte with padding) 0b 1 0100 101 type mid tkn Payload 0x10c6d7c26cc1e9aef3f2461e0c29 (14 bytes) Compressed message length: 16 bytes ]]>

Upon receiving the message in , the proxy decompresses it with the Rule in shared with the Application Server, thus performing the SCHC Outer Decompression. The result is the same OSCORE-protected CoAP response in . After that, the proxy replaces the values of the CoAP Message ID and of the CoAP Token to 0x0001 and 0x82, respectively. The result is the OSCORE-protected CoAP response shown in .

SCHC-OSCORE CoAP Content Response to be Compressed by the Proxy

Then, the proxy applies the Rule in shared with the Device to the OSCORE-protected CoAP response in , thus performing the SCHC Outer Compression of such response. The result is the OSCORE-protected and Outer Compressed CoAP response shown in , which the proxy forwards to the Device.

SCHC-OSCORE CoAP Content Response Forwarded by the Proxy 1 byte with padding) 0b 1 0001 010 type mid tkn Payload 0x10c6d7c26cc1e9aef3f2461e0c29 (14 bytes) Compressed message length: 15 bytes ]]>

Upon receiving the message in , the Device decompresses it using the Rule in shared with the proxy, thus performing the SCHC Outer Decompression. The result is the same OSCORE-protected CoAP response in . The Device decrypts and verifies such a response, which results in the same Compressed Plaintext in . Then, the Device applies the Rule in shared with the Application Server to such a Compressed Plaintext, thus performing the SCHC Inner Decompression. The result is used to rebuild the same CoAP response in , which the Device delivers to the application.

Security Considerations The security considerations discussed in and continue to apply. When SCHC is used in the presence of CoAP proxies, the security considerations discussed in continue to apply. When SCHC is used with OSCORE, the security considerations discussed in continue to apply. The security considerations in specifically discuss how the use of SCHC for CoAP when OSCORE is also used may result in (more frequently) triggering key-renewal operations for the two endpoints. This can be due to an earlier exhaustion of the OSCORE Sender Sequence Number space, or to the installation of new compression Rules on one of the endpoints. In either case, the two endpoints can run the key update protocol KUDOS defined in , as the recommended method to update their shared OSCORE Security Context.

IANA Considerations This document has no actions for IANA.

References Normative References In many standards track documents several words are used to signify the requirements in the specification. These words are often capitalized. This document defines these words as they should be interpreted in IETF documents. This document specifies an Internet Best Current Practices for the Internet Community, and requests discussion and suggestions for improvements. The Constrained Application Protocol (CoAP) is a specialized web transfer protocol for use with constrained nodes and constrained (e.g., low-power, lossy) networks. The nodes often have 8-bit microcontrollers with small amounts of ROM and RAM, while constrained networks such as IPv6 over Low-Power Wireless Personal Area Networks (6LoWPANs) often have high packet error rates and a typical throughput of 10s of kbit/s. The protocol is designed for machine- to-machine (M2M) applications such as smart energy and building automation. CoAP provides a request/response interaction model between application endpoints, supports built-in discovery of services and resources, and includes key concepts of the Web such as URIs and Internet media types. CoAP is designed to easily interface with HTTP for integration with the Web while meeting specialized requirements such as multicast support, very low overhead, and simplicity for constrained environments. The Constrained Application Protocol (CoAP) is a RESTful transfer protocol for constrained nodes and networks. Basic CoAP messages work well for small payloads from sensors and actuators; however, applications will need to transfer larger payloads occasionally -- for instance, for firmware updates. In contrast to HTTP, where TCP does the grunt work of segmenting and resequencing, CoAP is based on datagram transports such as UDP or Datagram Transport Layer Security (DTLS). These transports only offer fragmentation, which is even more problematic in constrained nodes and networks, limiting the maximum size of resource representations that can practically be transferred. Instead of relying on IP fragmentation, this specification extends basic CoAP with a pair of "Block" options for transferring multiple blocks of information from a resource representation in multiple request-response pairs. In many important cases, the Block options enable a server to be truly stateless: the server can handle each block transfer separately, with no need for a connection setup or other server-side memory of previous block transfers. Essentially, the Block options provide a minimal way to transfer larger representations in a block-wise fashion. A CoAP implementation that does not support these options generally is limited in the size of the representations that can be exchanged, so there is an expectation that the Block options will be widely used in CoAP implementations. Therefore, this specification updates RFC 7252. RFC 2119 specifies common key words that may be used in protocol specifications. This document aims to reduce the ambiguity by clarifying that only UPPERCASE usage of the key words have the defined special meanings. This document defines the Static Context Header Compression and fragmentation (SCHC) framework, which provides both a header compression mechanism and an optional fragmentation mechanism. SCHC has been designed with Low-Power Wide Area Networks (LPWANs) in mind. SCHC compression is based on a common static context stored both in the LPWAN device and in the network infrastructure side. This document defines a generic header compression mechanism and its application to compress IPv6/UDP headers. This document also specifies an optional fragmentation and reassembly mechanism. It can be used to support the IPv6 MTU requirement over the LPWAN technologies. Fragmentation is needed for IPv6 datagrams that, after SCHC compression or when such compression was not possible, still exceed the Layer 2 maximum payload size. The SCHC header compression and fragmentation mechanisms are independent of the specific LPWAN technology over which they are used. This document defines generic functionalities and offers flexibility with regard to parameter settings and mechanism choices. This document standardizes the exchange over the LPWAN between two SCHC entities. Settings and choices specific to a technology or a product are expected to be grouped into profiles, which are specified in other documents. Data models for the context and profiles are out of scope. This document defines Object Security for Constrained RESTful Environments (OSCORE), a method for application-layer protection of the Constrained Application Protocol (CoAP), using CBOR Object Signing and Encryption (COSE). OSCORE provides end-to-end protection between endpoints communicating using CoAP or CoAP-mappable HTTP. OSCORE is designed for constrained nodes and networks supporting a range of proxy operations, including translation between different transport protocols. Although an optional functionality of CoAP, OSCORE alters CoAP options processing and IANA registration. Therefore, this document updates RFC 7252. The presence of Constrained Application Protocol (CoAP) proxies may lead to infinite forwarding loops, which is undesirable. To prevent and detect such loops, this document specifies the Hop-Limit CoAP option. This document defines how to compress Constrained Application Protocol (CoAP) headers using the Static Context Header Compression and fragmentation (SCHC) framework. SCHC defines a header compression mechanism adapted for Constrained Devices. SCHC uses a static description of the header to reduce the header's redundancy and size. While RFC 8724 describes the SCHC compression and fragmentation framework, and its application for IPv6/UDP headers, this document applies SCHC to CoAP headers. The CoAP header structure differs from IPv6 and UDP, since CoAP uses a flexible header with a variable number of options, themselves of variable length. The CoAP message format is asymmetric: the request messages have a header format different from the format in the response messages. This specification gives guidance on applying SCHC to flexible headers and how to leverage the asymmetry for more efficient compression Rules. This document specifies enhancements to the Constrained Application Protocol (CoAP) that mitigate security issues in particular use cases. The Echo option enables a CoAP server to verify the freshness of a request or to force a client to demonstrate reachability at its claimed network address. The Request-Tag option allows the CoAP server to match block-wise message fragments belonging to the same request. This document updates RFC 7252 with respect to the following: processing requirements for client Tokens, forbidding non-secure reuse of Tokens to ensure response-to-request binding when CoAP is used with a security protocol, and amplification mitigation (where the use of the Echo option is now recommended). This document specifies alternative Constrained Application Protocol (CoAP) block-wise transfer options: Q-Block1 and Q-Block2. These options are similar to, but distinct from, the CoAP Block1 and Block2 options defined in RFC 7959. The Q-Block1 and Q-Block2 options are not intended to replace the Block1 and Block2 options but rather have the goal of supporting Non-confirmable (NON) messages for large amounts of data with fewer packet interchanges. Also, the Q-Block1 and Q-Block2 options support faster recovery should any of the blocks get lost in transmission. Ericsson RISE AB RISE AB Fraunhofer AISEC Ericsson The lightweight authenticated key exchange protocol EDHOC can be run over CoAP and used by two peers to establish an OSCORE Security Context. This document details this use of the EDHOC protocol, by specifying a number of additional and optional mechanisms. These especially include an optimization approach for combining the execution of EDHOC with the first OSCORE transaction. This combination reduces the number of round trips required to set up an OSCORE Security Context and to complete an OSCORE transaction using that Security Context. RISE AB Ericsson AB Ericsson AB Ericsson AB Universitaet Duisburg-Essen This document defines the security protocol Group Object Security for Constrained RESTful Environments (Group OSCORE), providing end-to-end security of CoAP messages exchanged between members of a group, e.g., sent over IP multicast. In particular, the described protocol defines how OSCORE is used in a group communication setting to provide source authentication for CoAP group requests, sent by a client to multiple servers, and for protection of the corresponding CoAP responses. Group OSCORE also defines a pairwise mode where each member of the group can efficiently derive a symmetric pairwise key with any other member of the group for pairwise OSCORE communication. Group OSCORE can be used between endpoints communicating with CoAP or CoAP-mappable HTTP. RISE AB RISE AB This document defines Key Update for OSCORE (KUDOS), a lightweight procedure that two CoAP endpoints can use to update their keying material by establishing a new OSCORE Security Context. Accordingly, it updates the use of the OSCORE flag bits in the CoAP OSCORE Option as well as the protection of CoAP response messages with OSCORE, and it deprecates the key update procedure specified in Appendix B.2 of RFC 8613. Thus, this document updates RFC 8613. Also, this document defines a procedure that two endpoints can use to update their OSCORE identifiers, run either stand-alone or during a KUDOS execution. Informative References IoTconsultancy.nl InterDigital RISE AB This document specifies the use of the Constrained Application Protocol (CoAP) for group communication, including the use of UDP/IP multicast as the default underlying data transport. Both unsecured and secured CoAP group communication are specified. Security is achieved by use of the Group Object Security for Constrained RESTful Environments (Group OSCORE) protocol. The target application area of this specification is any group communication use cases that involve resource-constrained devices or networks that support CoAP. This document replaces RFC 7390, while it updates RFC 7252 and RFC 7641. Ericsson AB Ericsson AB Ericsson AB This document specifies Ephemeral Diffie-Hellman Over COSE (EDHOC), a very compact and lightweight authenticated Diffie-Hellman key exchange with ephemeral keys. EDHOC provides mutual authentication, forward secrecy, and identity protection. EDHOC is intended for usage in constrained scenarios and a main use case is to establish an OSCORE security context. By reusing COSE for cryptography, CBOR for encoding, and CoAP for transport, the additional code size can be kept very low.

YANG Data Model TBD

Acknowledgments The authors sincerely thank , , , , , , and for their comments and feedback. The work on this document has been partly supported by the H2020 projects SIFIS-Home (Grant agreement 952652) and ARCADIAN-IoT (Grant agreement 101020259).