Static Context Header Compression (SCHC) for the Constrained Application Protocol (CoAP)
draft-ietf-lpwan-coap-static-context-hc-19
Discuss
Yes
(Suresh Krishnan)
No Objection
(Adam Roach)
(Alvaro Retana)
(Deborah Brungard)
(Martin Vigoureux)
Note: This ballot was opened for revision 12 and is now closed.
Éric Vyncke
(was No Objection)
Yes
Comment
(2020-07-08 for -15)
Sent
Thank you for addressing my COMMENTs raised in March 2020 and thank you for also addressing other DISCUSS and COMMENT from the March 2020 IEGS evaluation. Regards -éric
Erik Kline
No Objection
Comment
(2020-07-15 for -15)
Not sent
[[ comments ]] [ section 1 ] * "interop" -> "inter-operate" [ section 2 ] * "The host ... do not implement" -> "does not implement" * Figure 2: "ene-to-end" -> "end-to-end" * "and that they do not include" -> "and they do not include" [ section 4.3 ] * "cannot be compressed an the value" -> "cannot be compressed and the value" [ section 5.0 ] * "these assymetry" -> "this asymmetry" [ section 5.3 ] * "are a repeatable options" -> "are repeatable options" [ section 9 ] * "decompression will detect an error and drops the packet" -> "decompression will detect an error and drop the packet"
Murray Kucherawy
No Objection
Comment
(2020-07-16 for -15)
Sent for earlier
Thanks for addressing Alexey's and Francesca's earlier DISCUSS positions. Abstract: OLD: This draft defines the way Static Context Header Compression (SCHC) header compression can be applied to the Constrained Application Protocol (CoAP). [...] NEW: This draft defines the way Static Context Header Compression (SCHC) can be applied to the Constrained Application Protocol (CoAP). [...] Generally, "SCHC header compression" everywhere beyond the Abstract seems redundant to me and can be replaced with just "SCHC". Section 1: * The text here introduces several terms with curious capitalization, such as "End-to-End" and "Rules". If they have special meaning, they should be explicitly defined somewhere, otherwise I suggest just leaving them all lowercase. * "... some bits to be sent, these values are ..." -- comma splice; start a new sentence here * "... applied to different protocols, the exact Rules to be used ..." -- same Section 2: * "... defined in [rfc8724] document." -- remove "document" Section 3.1: * "The field Code have as well the same behavior, the 0.0X code format value in the request and Y.ZZ code format in the response." -- I'm afraid I don't understand this. Section 4.3: * "The code field indicates the Request Method used in CoAP, a IANA registry [rfc7252]." -- I can't parse this. Does that mean the code field's possible values are listed in an IANA registry? Which one? Section 4.4: * "... and the Least Significant Bits (LSB) CDA, see section ..." -- the stuff after the comma should be parenthesized instead; there are several instances of this in the document
Roman Danyliw
(was Discuss)
No Objection
Comment
(2020-07-13 for -15)
Sent for earlier
I support Ben Kaduk's DISCUSS position. Thank you for addressing my DISCUSS and COMMENT points.
Warren Kumari
No Objection
Comment
(2020-03-09 for -13)
Not sent
Thank you to Linda for the OpsDir review.
Alexey Melnikov Former IESG member
(was No Objection)
Discuss
Discuss
[Treat as non-blocking comment]
(2020-03-12 for -13)
Sent
I agree with Ben's first 2 DISCUSS points. ********************************************************************** * Note, that I am conducting an experiment when people aspiring to be* * Area Directors get exposed to AD work ("AD shadowing experiment"). * * As a part of this experiment they get to review documents on IESG * * telechats according to IESG Discuss criteria document and their * * comments get relayed pretty much verbatim to relevant editors/WGs. * * As an AD I retain responsibility in defending their position when * * I agree with it. * * Recipients of these reviews are encouraged to reply to me directly * * about perceived successes or failures of this experiment. * ********************************************************************** The following comments were provided by Francesca Palombini <francesca.palombini@ericsson.com>. My comments are marked with [[Alexey:]] below. Francesca would have balloted *DISCUSS* on this document. She wrote: Discuss: Either I am missing something about "unirectional" and "bidirectional" definition (which I read as can either be present in only one direction request/response or both), or the following sections are wrong: section 5.1 - assuming it is Content-Format, the option is bidirectional, it can be set either in a request or response, for example a PUT request can contain a Content-Format section 5.4 - Size1 and Size2 are bidirectional, and can be used both in req and resp (see RFC7959 sect 4) Section 5.5 - ETag is also Bidirectional (see RFC7252 section 5.10.6.1 and 5.10.6.2) There are more options being defined and not specified in the document: https://www.iana.org/assignments/core-parameters/core-parameters.xhtml#option-numbers for example, Hop-Limit is one. There needs to be some discussion about those, or some considerations on those being out of scope.
Suresh Krishnan Former IESG member
Yes
Yes
(for -12)
Unknown
Adam Roach Former IESG member
No Objection
No Objection
(for -13)
Not sent
Alissa Cooper Former IESG member
No Objection
No Objection
(2020-03-11 for -13)
Sent
I support Roman's and Benjamin's DISCUSS positions about the security considerations. The Gen-ART reviewer raised concerns about this as well that have not been fully addressed.
Alvaro Retana Former IESG member
No Objection
No Objection
(for -13)
Not sent
Barry Leiba Former IESG member
No Objection
No Objection
(2020-03-11 for -13)
Sent
This first item is almost a DISCUSS, but as I'm sure it's not a controversial point and just an editorial thing that will get fixed, I'm just putting it down here. — Section 1 — CoAP [rfc7252] is a transfer protocol that implements a subset of HTTP (Hypertext Transfer Protocol) and is optimized for REST-based (Representational state transfer) services. Important: this statement is not true. CoAP is not a subset of HTTP, and nowhere does CoAP claim that. You might instead combine some of these statements from the CoAP spec: 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. One of the main goals of CoAP is to design a generic web protocol for the special requirements of this constrained environment The goal of CoAP is not to blindly compress HTTP, but rather to realize a subset of REST common with HTTP but optimized for M2M applications. However you fix this, please do fix it. — Section 3 — It appears as if a different author wrote this, compared with the earlier text. I’m not calling out every issue, in the interest of review time, but am only citing some examples. In general, it would be good to have someone go through and edit this sections 3 and 3.1 for clarity. If you wait for the RFC Editor staff to do it, we could end up with errors that we miss catching, because they don’t have the technical background in this topic. SCHC with CoAP will be used exactly the same way as it is applied in any protocol as IP or UDP with the difference that the fields description needs to be defined based on both headers and target values of the request and the responses. SCHC Rules description use the direction information to optmize the compression by reducing the number of Rules needed to compress traffic. I’ve tried several times to understand the first sentence, and I can’t. It isn’t parseable, and I don’t know what you’re trying to say. The second sentence also needs work to make it readable. Can you please try to reword these? — Section 3.1 — The title and the first sentence stopped me for a bit: why would you be comparing CoAP with IPv6? You should be clear right up front that you’re talking about differences in compressing CoAP compared with compressing the other protocols, to explain why there’s a difference in how the compression works. Please say that at the start. (Perhaps that’s part of what you tried to say in Section 3, which I didn’t understand?) o In IPv6 and UDP, header fields have a fixed size, defined in the Rule, which is not sent. The Rule is not sent? Or do you mean the size is not sent? I think you want to say something like, “Header fields in IPv6 and UDP have fixed sizes. The size is not sent as part of the header, but is defined in the Rule.” In CoAP, some fields in the header have a variable length, for example the Token size may vary from 0 to 8 bytes, the length is given by a field in the header. Sentences like this are actually multiple sentences glued together, and are hard to read. In this example, I suggest this: “Some CoAP header fields have variable lengths, so the length is also specified in a header field. For example, the Token field can vary from 0 to 8 bytes in length.” — Section 4.5 — Token Value MUST not be sent as a variable length residue Make it “MUST NOT”.
Benjamin Kaduk Former IESG member
(was Discuss)
No Objection
No Objection
(2021-03-01 for -18)
Sent
Thanks for the updates in the -17 and -18, they do address my remaining Discuss points and most of my comments. I do have a few further remarks, most notably a suggested rephrasing for the security considerations section, but I believe they are all editorial in nature. Section 5 nit: s/based header/basic header/ nit: s/stock/incorporate/ (or similar) Section 5.3.1 SCHC will send the second element of the URI-Path with the length (i.e., 0x2 X 6) followed by the query option (i.e., 0x05 "eth0"). I don't think I understand where the 0x05 comes from -- aren't there only four non-NUL characters in "eth0"? Section 6.3 (nit) I think the "The [RFC7967] defines a No-Response option limiting the responses made by a server to a request" was better than the current "The [RFC7967] defines a No-Response". Section 7.1 Note that a client located in an Application Server sending a request to a server located in the Device may not be compressed through this Rule since the MID will not start with 7 bits equal to 0. A CoAP nit(?): I am not 100% sure I understand the specifics here, but I think the concern is just that the CoAP client in the Application Server might be using the simple "single Message ID" strategy for all its outbound requests, and thus might use more than 9 bits of message-ID space and achieve the "not start with 7 bits equal to 0" condition. As far as I can tell, though, there is no fundamental reason why such requests would *always* have a MID that does not start with 7 bits equal to zero, so I would suggest s/will not/might not/. Section 7.3 I recognize the width constraints of the table, but in Figure 13 the "mapp-sent" CDA is not a term that seems to be used anywhere else in the document. I believe that it is okay to format this with a line break, so that "mapping-" is on the first line and "sent" on the second. must include it without compression. The use of integrity translates into an overhead in total message length, limiting the amount of compression that can be achieved and plays into the cost of adding security to the exchange. nit: s/integrity/integrity protection/ The piv field lends itself to having some bits masked off with "MSB" MO and "LSB" CDA. This SCHC description could be useful in applications where the message frequency is low such as LPWAN technologies. Note that compressing the sequence numbers may reduce the maximum number of sequence numbers used in an exchange. Once the sequence number exceeds the maximum value, the OSCORE keys need to be re-established. nit: s/maximum number of sequence numbers used in an exchange/maximum number of sequence numbers that can be used in an exchange/ Section 9 The change to say that "when using another layer two, integrity protection is mandatory" is enough to address my discuss point, but the section as a whole is still fairly inscrutable in general. If it's useful, here's my take on how it could be written -- feel free to ignore or take whichever parts you do/don't want. %%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%% The use of SCHC header compression for CoAP header fields only affects the representation of the header information. SCHC header compression itself does not increase or decrease the overall level of security of the communication. When the connection does not use a security protocol (such as OSCORE, DTLS, etc.), it is necessary to use a layer-two security mechanism to protect the SCHC messages. If LPWAN is the layer-two technology, the SCHC security considerations of [RFC8724] continue to apply. When using another layer-two protocol, use of a cryptographic integrity-protection mechanisms to protect the SCHC headers is REQUIRED. Such cryptographic integrity protection is necessary in order to continue to provide the properties that [RFC8724] relies upon. When SCHC is used with OSCORE, the security considerations of [RFC8613] continue to apply. When SCHC is used with the OSCORE outer headers, the Initialization Vector (IV) size in the Compression Residue must be carefully selected. There is a tradeoff between compression efficiency (with a longer "MSB" MO prefix) and the frequency at which the Device must renew its key material (in order to prevent the IV from expanding to an uncompressable value). The key renewal operation itself requires several message exchanges and requires energy-intensive computation, but the optimal tradeoff will depend on the specifics of the device and expected usage patterns. If an attacker can introduce a corrupted SCHC-compressed packet onto a link, DoS attacks are possible by causing excessive resource consumption at the decompressor. However, an attacker able to inject packets at the link layer is also capable of other, potentially more damaging, attacks. SCHC compression emits variable-length Compression Residues for some CoAP fields. In the compressed header representation, the length field that is sent is not the length of the original header field but rather the length of the Compression Residue that is being transmitted. If a corrupted packet arrives at the decompressor with a longer or shorter length than the original compressed representation possessed, the SCHC decompression procedures will detect an error and drop the packet. SCHC header compression rules MUST remain tightly coupled between compressor and decompressor. If the compression rules get out of sync, a Compression Residue might be decompressed differently at the receiver than the initial message submitted to compression procedures. Accordingly, any time the context Rules are updated on an OSCORE endpoint, that endpoint MUST trigger OSCORE key re-establishment. Similar procedures may be appropriate to signal Rule udpates when other message-protection mechanisms are in use.
Deborah Brungard Former IESG member
No Objection
No Objection
(for -13)
Not sent
Magnus Westerlund Former IESG member
(was Discuss)
No Objection
No Objection
(2020-07-03 for -15)
Sent
Thanks for addressing my issues.
Martin Duke Former IESG member
No Objection
No Objection
(2020-07-15 for -15)
Sent
Being new to both CoAP and SCHC, I found parts of this draft extremely tough going. Thanks very much for the examples; I would have been totally lost without them. I trust that my comments here are mostly due to limited understanding, rather than some deeper issue... Sec 1. I cannot parse this sentence at all: "CoAP is an End-to-End protocol at the application level, so CoAP compression requires to install common Rules between two hosts and IP Routing may be needed to allow End-to-End communication." What are you trying to say here? Sec 2. I do not understand the symbolism of these figures. - What are the many parentheses and dashed lines at the bottom of each one? - I take it that the "SCHC" box implies that everything above it is header-compressed, up until it hits another "SCHC?" IIUC SCHC compresses one or two layers in the stack, rather than being a layer below. - Finally, the explanation of dashed boxes vs dotted boxes is at the very end of the section. Please move it to before the first figure. Sec 3. Expand "TV" on first use. Sec 4.5. " Token Value MUST NOT be sent as a variable length residue to avoid ambiguity with Token Length. Therefore, Token Length value MUST be used to define the size of the Compression Residue." After looking through the example, I think this means that because the Token Length is being repurposed, it is not available to define variable token lengths. Maybe switch the order of the sentences. It seems like the first flows from the second. In addition, for Token Value not to be sent as variable length, that imposes constraints on the rule set, right? It would be good to clarify exactly what a rule set must do to create this outcome. Sec.5. s/these assmetry/this asymmetry
Martin Vigoureux Former IESG member
No Objection
No Objection
(for -13)
Not sent
Mirja Kühlewind Former IESG member
No Objection
No Objection
(2020-03-12 for -13)
Sent
The TSV-ART review flagged a problem with draft-ietf-lpwan-ipv6-static-context-hc (Thanks Joe) which is a normative dependency but is already in RFC editor state. Ben also already captured this in his ballot. I also think it would be important to address this problem before final publication (of both docs) and the TSV ADs will coordinate with the INT ADs on this. Minor comment: Sec 7.3: " The Outer SCHC Rules (Figure 16) MUST process the OSCORE Options fields. " The example section should probably not have normative language.
Robert Wilton Former IESG member
No Objection
No Objection
(2020-07-16 for -15)
Sent
Thanks for this document. A couple of minor comments: 1. Introduction SCHC is a general mechanism that can be applied to different protocols, the exact Rules to be used depend on the protocol and the application. The section 10 of the [rfc8724] describes the compression scheme for IPv6 and UDP headers. This document targets the CoAP header compression using SCHC. So what does this document actually define? I read it as providing a mix of constraints that apply when encoding some CoAP fields in SDHC rules, and in other cases it provides guidance on how CoAP fields can be encoded in SDHC rules. Is my understanding correct? If so, a bit of text at the end of the introduction might be helpful. Related to this, I note that some of the sub-sections in section 5 make use of RFC 2119 language and others don't. Possibly the document would be more internally consistent if all the sub-sections in section 5 used 2119 language. 2. Applying SCHC to CoAP headers In the second example, Figure 2, ... This use case realizes an End-to- End context initialization between the sender and the receiver and is out-of-scope of this document. ... This document focuses on CoAP compression represented in the dashed boxes in the previous figures. These two comments seem to conflict with each other as to whether the second use case is covered or not? 7.3. Example OSCORE Compression Plaintext can be compressed up to only 1 byte (size of the RuleID). "compressed down" would read better than "compressed up" Thanks, Rob