Subject: [lp-wan] Genart last call review of draft-ietf-lpwan-coap-static-context-hc-12

From: Theresa Enghardt via Datatracker <[email-masked]>
Date: Mon, 10 Feb 2020 07:12:55 -0800

Reviewer: Theresa Enghardt
Review result: Almost Ready

I am the assigned Gen-ART reviewer for this draft. The General Area
Review Team (Gen-ART) reviews all IETF documents being processed
by the IESG for the IETF Chair.  Please treat these comments just
like any other last call comments.

For more information, please see the FAQ at

<https://trac.ietf.org/trac/gen/wiki/GenArtfaq>.

Document: draft-ietf-lpwan-coap-static-context-hc-??
Reviewer: Theresa Enghardt
Review Date: 2020-02-10
IETF LC End Date: 2020-02-20
IESG Telechat date: Not scheduled for a telechat

Summary:

Thanks for this work. This document is clear in the problem to be solved, the
challenges, and how to address these challenges. I think the details and
examples will help implementers tremendously. However, some parts would benefit
from more explanation to make the document easier to understand. Moreover, the
authors should double-check whether the document contains all the normative
language that is needed, and they need to revisit the security considerations.

Major issues:

Section 9, Security considerations
I find it difficult to believe that compressing CoAP headers in addition to
UDP/IP does not add any new security considerations and does not modify the
existing ones. As an application-layer protocol, the information contained in
CoAP might be more sensitive than the information in the UDP and IP headers,
thus, its security considerations should be carefully examined. For example,
does compression improve security by making it more difficult for an observer
to parse the packet, as the observer does not have the context? Does
compression make the existing security problems better or worse if you compress
the CoAP header as well? Do the possible threats mentioned in RFC 7252 still
apply if headers are compressed? Might compressing the CoAP headers affect
computational resources, like an attacker sending forged packets, if the
protocol has variable length fields and multiple occurences of the same field?

Minor issues:

Abstract
To make the abstract more self-contained, I suggest adding a brief description
of what SCHC is, then stating explicitly that so far SCHC has been defined for
UDP and IPv6, and this document defines it for CoAP. Then the abstract can keep
the two examples of how CoAP presents some unique challenges for using SCHC,
but it should clearly say that these are examples, as Section 3 later lists
more differences. Finally, perhaps it's worth making the last sentence more
concrete to say how the document addresses these challenges. Maybe something
like: The document gives guidance on how to apply SCHC to flexible headers and
how to leverage the asymmetry for more efficient compression rules.

Section 1
"CoAP [rfc7252] is an implementation of the REST architecture for constrained
devices." - From a protocol perspective, maybe "REST architecture" could be
phrased more accurately, like saying that CoAP is a web transfer protocol that
implements a subset of HTTP and is optimized for REST-based services? Also,
please expand REST on first use.

"[…] the field description composing the Rules […]" - At this point, Rules have
not yet been introduced.

The paragraph that describes how SCHC works was difficult to understand as a
reader not yet familiar with SCHC. For example, I was confused for a while why
a rule matches an entire packet and not just one header field, as I was missing
the big picture. Maybe here a top-down approach would help, e.g., something
like: "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 correspond to different types of
packets that a device expects to send or receive."

Additionally, perhaps the text should describe what match operations and what
header compression/decompression operations are possible, as the document
refers to these operations later in the text. Alternatively, the document could
refer to specific sections of draft-ietf-lpwan-ipv6-static-context-hc where
these operations are explained.

"The context(s) is(are) known by both ends before transmission." - As someone
not yet familiar with SCHC, it would be really helpful to have one or two
sentences here explaining how this usually works. Are the contexts typically
configured on the devices when installing the application? Are contexts
exchanged out of band and/or using some kind of protocol exchange?

As the abstract emphasizes that CoAP is different from UDP and IPv6, I was
expecting the Introduction to have some content on this. Later I saw that
Section 3 lists differences and resulting challenges, and then the document
explains how to address these challenges. But I think it makes sense to briefly
mention this already in the Introduction, e.g., by saying that SCHC is a
general concept that can be applied to different protocols, the exact rules to
be used depend on the protocol and perhaps the application, and that CoAP
differs from UDP and IPv6 in some aspects, see Section 3.

Section 2
While the heading of this section is "SCHC Compression Process", it does not
seem to describe the compression process, but instead this section seems to
focus on the architecture or deployment schemes of where SCHC is applied, i.e.,
on what headers. Please consider changing the section heading to better reflect
the content, e.g., to something like "Architecture for applying SCHC to CoAP"
or just "Applying SCHC to CoAP".

"In this case, SCHC C/D (Static Context Header Compression
Compressor/Decompressor) is performed at the device and at the LPWAN boundary."
- As someone not familir with LPWAN, to me it came as a surprise that SCHC can
not just be performed at the device, but apparently also somewhere in the
network. Would this be at a router or some kind of gateway? Is there a
reference for this? Perhaps it's worth briefly stating and explaining this at
the beginning of this section or maybe already in Section 1.

Section 3 and following:
Please check that you have all the normative language you need in there to make
sure you separate what is needed for SCHC to function correctly from any
suggestions how one could optimize their rule tables for a specific
deployment/application.

Section 3
"CoAP differs from IPv6 and UDP protocols on the following aspects" - As this
section does not just describe differences, but also points to how to deal with
them, perhaps it's a good idea to reflect this in both this introducing
sentence. Also, the section heading could be more explicit about the contents,
e.g., "Differences between CoAP and UDP/IP".

"IPv6 and UDP are symmetrical protocols.  The same fields are found in the
request and in the response" - IPv6 and UDP do not have requests and responses,
but packets and datagrams. Maybe instead you could say that there are the same
header fields in all packets/datagrams or "in a CoAP request and response".

"A CoAP request is intrinsically different from a response." - What exactly
does "intrinsically different" mean here? The examples give an idea, but I
think it's good to say explicitly what the difference is, e.g., that there's
different header fields in CoAP requests/responses.

"[I-D.ietf-lpwan-ipv6-static-context-hc] defines the use of a message direction
(DI) in the Field Description, which allows a single Rule to process message
headers differently depending of the direction." - I think here it makes sense
to say how this point relates to the point before, that CoAP is asymmetric. Is
this in conflict, so it makes SCHC more difficult to use for CoAP? Or does this
just mean that the SCHC rules have to be different for CoAP?

"The same behavior can be applied to the CoAP Code field 0.0X code Format is
found in the request and Y.ZZ code format in the answer." - Broken sentence and
hard to parse. Maybe rephrase?

"The direction allows splitting in two parts the possible values for each
direction in the same Rule." - Sentence is hard to parse. What does "the
direction" refer to here - a part of the rule? the direction the packet is sent?

"In IPv6 and UDP, header fields have a fixed size and it is not sent." - What
does "it" refer to here? The size?

"More systematically, the CoAP options are described using the
Type-Length-Value." - Maybe refer to it as the "Type-Length-Value encoding
scheme" or "format".

"[I-D.ietf-lpwan-ipv6-static-context-hc] offers the possibility to define a
function for the Field Length in the Field Description." - I think it makes
sense to add a sentence stating explicitly how this fact relates to your
document, e.g., that you use this possibility for CoAP.

"The MSB MO can be applied to reduce the information carried on LPWANs." - "MSB
MO" has not been defined or mentioned before in the document. Perhaps it makes
sense to either introduce it in Section 1, if you choose to add a description
of the match operations that exist, or you could add a reference.

"CoAP also obeys the client/server paradigm and the compression ratio can be
different if the request is issued from an LPWAN device or from a non LPWAN
device." - The overall point of the paragraph is not clear from this sentence.
What is the relationship between client/server and LPWAN/non-LPWAN, as they are
mentioned in the same sentence? Is it that compression can be optimized based
what kind of device sends the data?

Should the point regarding the proxy placed before the compressor also be
mentioned in Section 2, which talks about different deployment schemes?

"If no valid Rule was found, then the packet MUST be sent uncompressed using
the RuleID dedicated to this purpose and the Compression Residue is the
complete header of the packet.  See section 6 of
[I-D.ietf-lpwan-ipv6-static-context-hc]." - Is this a different between CoAP
and UDP/IP? It is part of the list of differences between CoAP and UDP/IP, but
it seems different from the other list items.

Section 4.2

"In any case, a rule MUST be defined to carry RST to a client." -> This says
that you MUST NOT assume that a server only sends ACK, right? Should this MUST
apply to RST in general, i.e., also apply to carrying RST to a server?

Section 4.4
"In case where the Device is a client, the size of the Message ID field may be
too large regarding the number of messages sent." - "too large" sounds like it
doesn't work, but it's just inefficient, right? Maybe this should be rephrased
to directly say that the field is 16 bit, but if a client sends less messages,
it would need less bits.

"The client SHOULD use only small Message ID values, for instance 4 bit long."
- Maybe rephrase "4 bit long" to say "Message IDs that can be encoded using
only 4 bits".

This part refers to MSB and LSB CDA, but neither has been introduced before in
the document.

Section 4.5
"Token Value size cannot be defined directly in the rule in the Field Length
(FL).  Instead, a specific function designated as "TKL" MUST be used and length
does not have to be sent with the residue. During the decompression, this
function returns the value contained in the Token Length field." - Why can the
Token Value size (is this the length of this header field?) not be defined
directly? And what is this specific function "TKL" supposed to do? Is there a
reference for it? From this sentence, it's also not clear why length does have
to be sent.

Section 5.2
"Otherwise these options SHOULD be sent as a residue (fixed or variable
length)." - Well if you can't compress it, you don't have any other choice than
to send it as residue, right? So is this a SHOULD or do you want to simply say
"these options can be sent as a residue"?

Section 5.3
Here the document starts giving examples for rules and contexts, which is a
good idea, but the first example is difficult to follow. Maybe it's a good idea
to briefly describe the rule that is shown in Figure 2 and the URI that it
would match, and maybe it's worth showing the alternative without regrouping to
make clear why a 2 bit residue would be needed without regrouping. In general,
it might be worth adding a reference to
draft-ietf-lpwan-ipv6-static-context-hc, where Section 7.1 uses a similar table
for showing rules and provides more explanation of the table fields.

Section 5.3.1
"and the unit is set to bytes." - Is this a SHOULD or a MUST?

Section 5.3.2
"[…] send a compression residue with a length of 0 to indicate that this
Uri-Path is empty. This adds 4 bits to the compression residue." - This appears
to be contradictory: Either you send 0 bits of compression residue or 4 bits.

Section 5.5
"These fields are unidirectional." - For other unidirectional fields, the
document says that it "MUST NOT be set to bidirectional". Does it need to add
this restriction here, too?

Section 6
The heading is not really clear, please change. What "Other RFCs" is this about
- Extensions to CoAP? More CoAP fields, features, or options?

Section 6.4
"This draft recommends to implement a parser that is able to identify the
OSCORE Option and the fields it contains." - Why is a parser needed and how
does such a parser interact with the SCHC rule matching? Is this parser
something that already exists in SCHC or is this something additional, meaning
you can't compress OSCORE using SCHC as it exists? How does this section relate
to Section 7.2, which discusses OSCORE in detail? Should there be a reference
to Section 7.2 here?

Section 7.3
"The SCHC Rules for the Inner Compression include all fields that are already
present in a regular CoAP message, what is important is their order and the
definition of only those CoAP fields are into Plaintext, Figure 11." - This
sentence is hard to parse. Maybe split into two sentences.

For compressing the response, it is not obvious why the compression residue
produces a misalignment which changes the hexcode. I would assume that the
padding would just added after the residue. Why is this shifted instead? Does
this come from the OSCORE spec? If so, it's worth saying so explicitly.

Figure 14 contains Options "0xd8080904636c69656e74" but in the above "Protected
message" (for the request) the substring is "d7080904636c69656e74" - This might
be a copy-paste-error.

"The SCHC context would need to be reestablished" - This reads like there might
be some kind of protocol exchange to establish a context, while the earlier
text gave the impression that a SCHC context is pre-configured on the device.
Does this simply mean that the SCHC context would need to change, e.g., by
adjusting the compression rules to mask less bits?

Nits/Editorial:

Please expand SCHC on first use.

Section 1
"The context is said static" - Perhaps rephrase to "called" static? or just
cross the "said"? Please check consistency: "Rules" or "rules"?

Section 2
"focused on the inner header" → "focuses"?

Section 3
"CoAP differs from IPv6 and UDP protocols " - strike "protocols" from this
sentence

"For instance, if a client sends only CON request" -> "requests"?

"The SCHC compression-decompression process never modifies the Values it only
reduces their sizes." - missing comma

"If no valid Rule was found" -> "is found"

Section 4.2
"CoAP Protocol" -> "CoAP" or "The CoAP Protocol"?

Section 4.4
"The client will generate Message ID" -> "a Message ID"? "Message IDs"?

Section 6.4
"This draft" will no longer be a good way to refer to the document once the
document becomes an RFC, so maybe change it to "This document" or
"specification".

---

From: Ana Minaburo <[email-masked]>
Date: Tue, 25 Feb 2020 23:26:55 +0100

Thank you very much for your deeply and interesting revision. Please see
our comments and answers inside yours. We plan to submit a new version of
the draft with a security response after the next interim meeting that will
be next week.
We are also working on the OSCORE part, and we will come to you with our
responses.

Ana

> language that is needed, and they need to revisit the security

Ana: We have added references to RFC8724 (SCHC document) also we have
rephrased some parts, and
used the SCHC terminology as in RFC8724, we also added the significance of
the abbreviations.

> computational resources, like an attacker sending forged packets if the
> protocol has variable length fields and multiple occurrences of the same
> field?
>
> Ana: We have taken into consideration this issue, we will answer it in a
specific message.

Minor issues:
> Ana: Thanks for this input, the new version of the abstract is:

"This draft defines the way SCHC (Static Context Header Compression) header
compression can be applied to CoAP protocol. SCHC is a header compression
mechanism adapted for constrained devices. SCHC uses a static description
of the header to reduce the redundancy and the size of the information in
the header. While the RFC8724 describes the SCHC compression and
fragmentation framework, and its application for IPv6/UDP headers, this
document applies the use of SCHC for CoAP headers. The CoAP header
structure differs from IPv6 and UDP one since CoAP uses a flexible header
with a variable number of options, themselves of variable length. The CoAP
protocol messages format is asymmetric: the request messages have a header
format different from the one in the response messages. This specification
gives guidance on how to apply SCHC to flexible headers and how to leverage
the asymmetry for more efficient compression Rules."

> Ana: Done

> Ana: Done

> Ana: Done

> Ana: Reference to SCHC document and description has been added

> Ana: The way the context is configured or exchanged is out of the scope of
this document because we are trying to explain the problem of CoAP header
compression.

> Ana: Done

> or just "Applying SCHC to CoAP".

Ana: Done, we have changed the title

> Ana: Chapter 5 of the SCHC document gives the Architecture for SCHC, we
have added a reference to this section.

> suggestions how one could optimize their rule tables for a specific

Ana: Done, we have aligned our terminology with the SCHC document

> e.g., "Differences between CoAP and UDP/IP".

Ana: Good point, we have created a new section

> different header fields in CoAP requests/responses.

Ana: Good point, yes intrinsically means different header fields in
Request/Responses packets

> Ana: It is not a conflict neither more difficult nor different, as SCHC
includes the DI in the Rule the CoAP asymmetric problem is solved. Because
the value in DI will be used to define which fields are in which direction
in the same Rule. So instead of describing two Rules, one for each
direction, we only have to define one Rule for both directions, paying
attention to give the correct field description.

> Ana: Done

> Ana: Direction is the Request or Response format (up, down,
bidirectional). Yes is part of the Rule and yes
it describes the direction the packet is sent from client to server or from
server to client, request/response format headers

> does "it" refer to here? The size?
Ana: Yes, each field in the header has a length in bits or bytes; when a
field in the header format has a fixed length, you know it, and it has been
defined in the protocol document.
Example: The IPv6 version is 4-bit length and the value is 6, so in SCHC
field description this field will have a size of 4 bits and the target
value will be 6

> Ana: Done

> document, e.g., that you use this possibility for CoAP.

Ana: We have added the following explanation:
When doing SCHC compression of a variable-length 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 the size is
sent with the compressed value in the residue.

> Ana: We have added all the definitions when they appear first.

> what kind of device sends the data?
Ana: Yes, this is an optimization of the SCHC compression, and after
discussion in the group, we think this is not part of this document.

> Ana: Yes, it is also part of optimization, we have moved out this part
also from the document.

> it seems different from the other list items.

Ana: This was an issue added from the IoTDIR. I have moved this input to
the new section CoAP Compression with SCHC.

> ana: Yes, so a new Rule may be used

> Ana: Yes, done

> Ana: Done

> Ana: Changed, the MSB has been introduced now in section 1.

> Ana: Token is defined through two CoAP fields, Token-Length in the
mandatory header and Token-Value directly following the mandatory CoAP
header.
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.
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 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.

> Ana: Yes, done

> Ana: Done

> Ana: Must

> Ana: This adds the 4 bits of the variable residue size. See section 7.5.2
{{rfc8724}}

> this restriction here, too?
Ana: yes, because these fields are only in the client request and the
server response does not use them

> Ana: We have changed to "SCHC compression of CoAP extension RFCs."

> to Section 7.2, which discusses OSCORE in detail? Should there be a
Ana: SCHC compression parse the header in order to collect the information,
and to select the correct Rule, the parser exists and is used for any
protocol. But the terminology is not described like this. We have changed
the sentence to "This specification recommends to identify the OSCORE
Option and the fields it contains."

> Ana: Done

Figure 14 contains Options "0xd8080904636c69656e74" but in the above
> "Protected
Ana: Yes, well caught, thanks

> Ana: Done, thanks