Summary: Needs a YES. Has 3 DISCUSSes. Needs 3 more YES or NO OBJECTION positions to pass.
** Section 9. (as Paul Wouters mentioned in his SECDIR review, thanks Paul!) Per “This document does not have any more Security consideration than the ones already raised on [I-D.ietf-lpwan-ipv6-static-context-hc]”, this reference in Section 12 (Security Considerations) contains the statement that “SCHC is expected to be implemented on top of LPWAN technologies, which are expected to implement security measures.”, this assumption doesn't necessarily seem valid here? What are the implications? ** Section 9. Per “The size of the Initialisation Vector residue size must be considered carefully. A too large value has a impact on the compression efficiency and a too small value will force the device to renew its key more often.”, can you be a bit clearer on the tradeoff: -- how small is still acceptable given the security properties that still need to be preserved in the AEAD nonce? -- Given a particular smaller size, what factors would would influence more frequent key renewal?
I support Ben Kaduk's DISCUSS position. ** Section 9. Does it make sense to: s/the packet must be dropped by the decompressor/the packet MUST be dropped by the decompressor/? ** Editorial Nits: -- Section 3.1. s/knwoledge/knowledge/ -- Section 3. Typo. s/optmize/optimize/
Section 5.2 claims that Uri-Host and URI-Port are unidirectional from server to client and "[are] never found in client requests", which seems to contradict Section 5.10.1 of RFC 7252. It seems like maybe this section is supposed to only cover Max-Age, with Uri-Host and Uri-Port rolled into Section 5.3 along with Uri-Path and Uri-Query? Similarly, Section 5.4 says that size1 and size2 are unidirectional (only in requests), which does not seem to be accurate given my reading of RFCs 7252 and 7599. I also think that we need some further discussion (e.g., in the security considerations) about how the base LPWAN SCHC document assumes that MAC-layer LPWAN security mechanisms are in use, but that CoAP is not restricted to such contexts. What additional security considerations are relevant when this compression is used for CoAP without LPWAN MAC-layer cryptographic protection? Perhaps not really a Discuss on this document, but what is the planned disposition of the tsv-art reviewer's comments regarding draft-ietf-lpwan-ipv6-static-context-hc and UDP Options? I did not see anything pertinent in the mailarchive.
Please respond to the secdir review; I don't trust my own response to be a comprehensive one that addresses all the raised potential issues. This document is targeting Proposed Standard status, but in some sense it's not clear that it is specifying a protocol per se, as opposed to illustrating a set of choices that can be made for applying the SCHC technique to CoAP messages. These choices are expected to be generally useful, but since the SCHC rules must be preagreed by all entities in advance, there's not really anything to prevent a deployment from using a modified version of these procedures, in terms of lost interoperability. In addition, the shepherd writeup mentions that there may be some desire to do a refresh in the future, after more implementation experience is gained. So I don't have a great sense as to which parts of this document are better as Proposed Standard vs. Informational. Abstract This draft defines the way SCHC (Static Context Header Compression) header compression can be applied to the CoAP protocol. SCHC is a header compression mechanism adapted for constrained devices. SCHC Is it also in some sense a key requirement that these constrained devices produce a fairly consistent or deterministic class of output? Section 1 SCHC compresses and decompresses headers based on shared contexts between devices. Each context consists of multiple Rules. Each rule can match header fields and specific values or ranges of values. If a rule matches, the matched header fields are substituted by the rule ID and optionally some residual bits. Thus, different Rules may Do I remember corectly that an SCHC rule matching implies that the entire header structure matches (i.e., there are no fields in the header not listed in the rule)? If so, perhaps a slight rephrasing to "If a packet header fully matches a rule" would be helpful. Compression mainly results in one of 4 actions: * send the field value, * send nothing, * send some least significant bits of the field or * send an index. After applying the compression there may be some bits to be sent, these values are called Compression Residues. [It looks like this is generated from Markdown and needs additional blank lines between bullet points] SCHC is a general concept mechanism that can be applied to different nit: "concept" is a noun, not an adjective, so this doesn't parse properly. protocols, the exact Rules to be used depend on the protocol and the application, and CoAP differs from UDP and IPv6, see Section 3. nit: comma splice ("the exact rules [...]" is a complete sentence). Section 2 In the third example, OSCORE [rfc8613] is used. In this case, two rulesets are used to compress the CoAP message. A first ruleset focused on the inner header and is applied end to end by both ends. A second ruleset compresses the outer header and the layers below and is done between the Sender and the Receiver. Is it worth having a parllel style and mentioning that the outer compression can be modified hop by hop (in contrast to the inner end-to-end compression)? Section 3 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 If there's a difference, it's not "exactly the same". Section 3.1 return path (e.g. source and destination addresses fields). The CoAP headers instead are asymmetric, the headers are different for a request or a response. For example, the URI-path option is nit: comma splice o Even when a field is "symmetric" (i.e. found in both directions) the values carried in each direction are different. To performs the compression a matching list in the TV might be use because nit: "used". field two cases may be raised after applying the CDA: * The result of the compression is of fixed length and the compressed value is sent in the residue. * Or the result of the compression is of variable-length and in this case, the size is sent with the compressed value in the residue. [another presumed-markdown list, though this one might be easier to reformat just as running text, since there are only two options] o In CoAP headers, a field can appear several times. This is typical for elements of a URI (path or queries). The SCHC specification [I-D.ietf-lpwan-ipv6-static-context-hc] allows a Field ID to appears several times in the rule, and uses the Field Position (FP) to identify the correct instance, and thereby removing the ambiguity of the matching operation. draft-ietf-lpwan-ipv6-static-context-hc notes that there can be issues when using a FP of zero for "don't care"; perhaps it's worth noting that these issues are pretty certain to occur for URI-path? o Field sizes defined in the CoAP protocol can be too large regarding LPWAN traffic constraints. This is particularly true for the Message ID field and the Token field. SCHC uses different Matching operators (MO) to performs the compression, see section 7.4 of [I-D.ietf-lpwan-ipv6-static-context-hc]. In this case the Most Significant Bits (MSB) MO can be applied to reduce the information carried on LP This text was a bit hard for me to unwind, especially "field sizes [...] too large regarding LPWAN traffic constraints". At first I thought it was saying that CoAP fields were problematic for SCHC (though I can no longer see why I would think that), and then that the "length" of various length+value encodings in CoAP allowed me to pick a length that would be problematic for LPWAN, before arriving to my current conclusion that it's just saying "some fields in CoAP are large and will only take on a narrow range of values in a LPWAN context, providing a lot of static bits that can be compressed using the MSB MO". In essence, I don't know that the "regarding LPWAN traffic constraints" is the most effective language to use; emphasizing that the fields are large and mostly unchanging, and that LPWAN needs to care about those wasted bits, seems to be the important part. Section 4.3 If the device only implements a CoAP client, the request code can be reduced to the set of requests the client is able to process. nit(?): "process" or "produce"? A mapping list can be used for known values, for other values the field cannot be compressed an the value needs to be sent in the residue. nit: s/an/and/ Section 4.4 It seems like some guidance is in order about choosing how many bits to compress, based on the frequency of traffic generated, EXCHANGE_LIFETIME, and any other factors used to pick a message ID range for a given device. Section 4.5 Token Length is processed as any protocol field. If the value does not change, the size can be stored in the TV and elided during the transmission. Otherwise, it will have to be sent in the compression residue. [...] used to define the size of the residue. A specific function designated as "TKL" MUST be used in the Rule. During the decompression, this function returns the value contained in the Token Length field. I'm not sure I understand how these two parts fit together. I understand that CoAP places a tight binding betwen the TKL value and the length of the token field, and so if SCHC tried to treat them differently we could break a CoAP invariant (this seems to be the "ambiguity" that we seek to avoid, per the trimmed quote). But the last part seems to say that the TKL function to give the actual token length is part of the Rule, and the former part says that if the CoAP Token Length is variable, it will be sent in the compression residue -- if the Token Length is a compression residue then that seems to imply that it is not fixed by the Rule, and thus I'm not sure what the procedure is supposed to be with this "TKL function". Furthermore, I don't see specification of the TKL function later in the document. I guess it's supposed to take as input information from the Rule's definition and the token length residue in order to output the length of the transmitted token residue, but that does not seem very clearly spelled out. (Also, I'm not sure whether the token residue would necessarily be the entire token or the rule could allow some prefix to be compressed...) Section 5 Would it be appropriate to give some guidance about who will have to do what in order to cope with new CoAP Options defined in the future? I'm also not sure that there's much rhetorical benefit in trying to distinguish between Options defined in the core CoAP spec and subsequent additions Section 5 vs. Section 6); they seem to be functionally the same from an implementor's point of view. (Well, maybe not OSCORE.) There are also a few of Options in the current registry that are not given any treatment here (whether in Section 5 or Section 6); should we mention that? (Hop-Limit, OCF-*, ...) Section 5.1 I see only "Content-Format" and "Accept" Options defined in RFC 7252, but no "Content" option. used to limit the size of the residue. Otherwise, the value has to be sent as a residue (fixed or variable length). The content format is an integer in the range 0-65535, and if we don't know enough about what can be used to have a match-list, how can we make assumptions about a variable-length residue being better than a fixed-length one? Section 5.3 [Perhaps the interaction between FP and Uri-Path that I mentioned above could be discussed here instead.] This specification of the regrouping operation and the table in the figure seem a bit in need of further clarification. Perhaps "Even though there are two distinct URI-Path fields to match, the target values for all regrouped path components are consolidated into a single logical "target value" (with the appropriate number of path components) to be matched. The components of the target value must individually match with the URI-Path field values in the indicated field positions. Note specifically that the FP values, as indicated in the example, are not required to be consecutive values; in this case the path components in the target value are a matter of convenience and would have additional components inserted in order to match the actual resource path in question. For the subsequent Uri-Path fields in the rule, no target value is given and the match operation is listed as "ignore" for convenience; the actual matching has occured on the grouped value listed in the first field's entry." (I'm not sure why the CDA is listed as "value-sent" for FP 3 in the example, though.) Section 5.3.2 be created to cover all the possibilities. Another possibility is to define the length of Uri-Path to variable and send a compression residue with a length of 0 to indicate that this Uri-Path is empty. I'm not sure I understand this proposal. Is it to say that you could have a single rule that lists the maximum expected number of path components, and then use "empty component"s to represent the compressed form of shorter paths? It seems like this still has a hard cap on the number of path components that could be represented by a given Rule, which would be a significant limitation and needs to be called out. Section 5.4 [I-D.ietf-lpwan-ipv6-static-context-hc]. They are used only by the client to access a specific resource and are never found in server response. nit: singular/plural mismatch "they are"/"server response" If the field value has to be sent, TV is not set, MO is set to "ignore" and CDA is set to "value-sent". A mapping MAY also be used. Otherwise, the TV is set to the value, MO is set to "equal" and CDA is set to "not-sent". Please reword/reformat to give equal treatment to the three options (send full residue, mapping list, target value) in terms of the formatting and the use of normative keywords. Section 5.5 These fields are unidirectional. In which directions? Section 6.1 I suggest using rhetoric that is consistent with the two different block options, even though they conceptually fit together as a functional unit. includes a fragmentation protocol. They are compatible. If a block option is used, its content MUST be sent as a compression residue. Anything to say about fixed vs. variable length encoding? Section 6.2 Since an RST message may be sent to inform a server that the client does not require Observe response, a rule MUST allow the transmission of this message. Is it worth assembling a consolidated table of specific rules or rule functionality that must be present to have a functional CoAP SCHC setup (incorporating this and the base SCHC requirements for, e.g., a rule to capture otherwise non-matching traffic that is sent without compression)? Section 6.3 Otherwise, if the value is changing over time, TV is not set, MO is set to "ignore" and CDA to "value-sent". A matching list can also be used to reduce the size. Similarly to my comment above, it might be nice to give parallel rhetorical treatment to the three options. Section 6.4 This section feels more like a sketch of how someone could implement SCHC with OSCORE, as compared to previous Options' handling that has a pretty well-defined procedure. Would it be desirable, for example, to have a separate Rule for each value of the OSCORE flags that was expected? Section 7.2 The Plaintext is now encrypted by an AEAD algorithm which integrity protects Security Context parameters and eventually any class I options from the Outer Header. Currently no CoAP options are marked class I. The resulting Ciphertext becomes the new Payload of the I suggest dropping "eventually", as it will no longer make sense if/when class-I options are defined. Note that since the Inner part of the message can only be decrypted by the corresponding end-point, this end-point will also have to implement Inner SCHC Compression/Decompression. It might be worth being even more explicit that the SCHC context for the inner and outer parts may differ as well, since they may be processed by different entities. Section 7.3 The piv field lends itself to having a number of bits masked off with MO MSB and CDA LSB. This could be useful in applications where the message frequency is low such as that found in LPWAN technologies. Note that compressing the sequence numbers effectively reduces the maximum amount of sequence numbers that can be used in an exchange. Once this amount is exceeded, the OSCORE keys need to be re- established. Just to check: one could also allocate additional Rules to match a different prefix, and get additional sequence number space? Compression residue: 0b0001 010 (7 bits -> 1 byte with padding) mid tkn We had a space after "0b" in the request portion, which seems to aid readibility. As can be seen, the difference between applying SCHC + OSCORE as compared to regular SCHC + COAP is about 10 bytes of cost. I'd suggest noting that this is about what one would expect, given the fixed and uncompressible overhead of the 8-byte tag, plus the need for the dual compression with inner and outer contexts (each of which have their own octet for rule ID). IIUC additional Rule information would be needed to handle Observer responses/updates, but it's not really clear that we need to mention that fact in the context of this specific example. Section 9 This document does not have any more Security consideration than the ones already raised on [I-D.ietf-lpwan-ipv6-static-context-hc]. Given that we then go on to talk about more stuff, am I to conclude that the additional discussion is merely exposition on topics already covered in the reference (vs. new content that would make this quoted statement invalid)? In particular, I think there is another new security consideration worth discussion here, relating to the interaction of compression and OSCORE. To illustrate how this might come intoi play, consider the example in Section 7.3, where the response can be compressed to a single byte, since there is only one request message defined/expected by the Rules. In such a scenario where the number of potential plantexts is extremely small, an attacker with knowledge that SCHC is in use (and, perhaps, the Rules in question) will have a very easy time of traffic analysis, which to some extent will defeat the message protection that OSCORE is intended to provide. Variable length residues may be used to compress URI elements. They cannot produce a packet expansion either on the LPWAN network or in the Internet network after decompression. The length send is not We should probably say why ("because the static context embedded in the Rule used for compression can only remove/replace a static, fixed-length prefix of the URI component") nit: s/send/sent/ used to indicate the information that should be reconstructed at the other end, but on the contrary the information sent as a Residue. nit: "on the contrary the length of the information sent as a Residue", I think. OSCORE compression is also based on the same compression method described in [I-D.ietf-lpwan-ipv6-static-context-hc]. The size of the Initialisation Vector residue size must be considered carefully. I suggest adding a note that there is a tradeoff between the efficiency of compression and the number of protected messages that can be sent using a given key/SCHC context; the following two sentences don't seem as clear as they could be. So ... A too large value has a impact on the compression efficiency and a too small value will force the device to renew its key more often. This operation may be long and energy consuming. Perhaps, % The OSCORE initialization vector holds a message sequence number, and % a unique such number is needed for each distinct message. The SCHC % procedure gives compression efficiency by assuming that a fixed prefix % of the IV remains static and eliding that fixed prefix from the % transmitted message. However, such compression has the corresponding % effect of reducing the number of distinct sequence numbers available % to the sender. When the usable sequence number space is exhausted, % the OSCORE security context must be rekeyed; since this rekeying can % be an expensive operation in terms of time and energy consumption, the % creation of SCHC Rules for OSCORE compression should take into % consideration the tradeoff between (amortized )rekeying cost and the % recurring transmission overhead for the uncompressed portion of the % initialization vector.
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 <firstname.lastname@example.org>. 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 184.108.40.206 and 220.127.116.11) 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.
Francesca also provided the following comments: Comment: Section 4.2 CoAP type field: better to reference the IANA registry rather than this section, as additional Code fields not defined in RFC7252 can be registered. Section 7.4 : s/CONTENT/Content
Reviewing this document and its application to compress case two and three stacks in Figure 1, i.e. with some end-to-end encryption appears to significantly change an assumption from the SCHC for IPv6/UDP. Namely, the assumption about context establishment. In normal SCHC the contexts are established between the Device and the NGW. In these end-to-end encrypted case the context establishing party for the COAP compression is the APP and the APP layer in the device. This difference appear completely ignored in this document. I think this is a significant difference as having the device and NGW run a protocol for establishing context over the L2 or L3 with the local context knowledge is fairly straightforward. However, in this case when the COAP peer on the internet side of the NGW this determination and configuration is a different matter. From my perspective some more discussion of the fact that this is a different context and that it have different challenges in establishing the context should be made clear in the document.
I would also note that the TSV-ART review did find an issue with the an underlying assumption in draft-ietf-lpwan-ipv6-static-context-hc which is not yet published. The issue is that the assumption that the UDP length field is redundant will not be true when https://datatracker.ietf.org/doc/draft-ietf-tsvwg-udp-options/ gets approved. Thus the question arises if this assumption should be amended or not in the underlying technology. I note this here primarily so that it is discussed by the WG and the responsible AD.
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.
Thank you to Linda for the OpsDir review.
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.
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”.
Thank you for the work put into this document. With the heavy load on this week telechat and all meetings related to the cancellation of the IETF-107 in-person meeting, I must admit that this review was not as thorough as I would hope :-( I am also trusting the ART AD for their review of the CoAP protocol compression. Please find below some non-blocking COMMENTs and NITs. Regards, -éric == COMMENTS == I support Barry's COMMENT on the section 1. -- Section 2 -- Would benefit from a clear explanation of the "Sender" and "Receiver" probably in the terminology section. == NITS == In many places, the acronyms are followed by their expansions, I recommend to use the other way: expansion (acronym) -- section 1 -- Fix the bullet list that appears broken in the text "one of 4 actions:..." -- Section 3.1 -- Same as above for "applying the CDA:..."