Skip to main content

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