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

[Ana Minaburo <[e-mail]>]

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

On Mon, Feb 10, 2020 at 4:12 PM Theresa Enghardt via Datatracker <
[e-mail]> wrote:

> 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.
>

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.

>
> 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 occurrences of the same
> field?
>
> Ana: We have taken into consideration this issue, we will answer it in a
specific message.

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.
>
> 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."


> 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.
>
> Ana: Done


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


> 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."
>
> Ana: Done


> 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.
>
> Ana: Reference to SCHC document and description has been added


> "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?
>
> 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.

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.
>
> Ana: Done


> 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".
>

Ana: Done, we have changed the title

>
> "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.
>
> Ana: Chapter 5 of the SCHC document gives the Architecture for SCHC, we
have added a reference to this section.


> 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.
>

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

>
> 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".
>

Ana: Good point, we have created a new section

>
> "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.
>

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

>
> "[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?
>
> 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.


> "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?
>
> Ana: Done


> "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?
>
> 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


> "In IPv6 and UDP, header fields have a fixed size and it is not sent." -
> What
> 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

>
> "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".
>
> Ana: Done


> "[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.
>

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.

>
> "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.
>
> Ana: We have added all the definitions when they appear first.


> "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?
>
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.

>
> Should the point regarding the proxy placed before the compressor also be
> mentioned in Section 2, which talks about different deployment schemes?
>
> Ana: Yes, it is also part of optimization, we have moved out this part
also from the document.

"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.
>

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

>
> 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?
>
> ana: Yes, so a new Rule may be used


> 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.
>
> Ana: Yes, done


> "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".
>
> Ana: Done


> This part refers to MSB and LSB CDA, but neither has been introduced
> before in
> the document.
>
> Ana: Changed, the MSB has been introduced now in section 1.


> 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.
>
> 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.


> 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"?
>
> Ana: Yes, done


> 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.
>
> Ana: Done


> Section 5.3.1
> "and the unit is set to bytes." - Is this a SHOULD or a MUST?
>
> Ana: 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.
>
> Ana: This adds the 4 bits of the variable residue size. See section 7.5.2
{{rfc8724}}


> 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?
>
Ana: yes, because these fields are only in the client request and the
server response does not use them


>
> 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?
>
> Ana: We have changed to "SCHC compression of CoAP extension RFCs."


> 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?
>
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."

>
> 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.
>
> Ana: Done

> 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.
>
Ana: Yes, well caught, thanks

>
> "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:
>
> Ana: Done, thanks