Subject: Re: [Gen-art] Genart last call review of draft-ietf-lpwan-coap-static-context-hc-12

From: Theresa Enghardt <[email-masked]>
Date: Mon, 2 Mar 2020 14:10:10 +0100

Dear Ana,

Thank you for the responses to my comments and for the improvements to
the document.

Please find responses to some of your points and some suggestions inline:

On 25.02.20 23:26, Ana Minaburo wrote:
>
>     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."

TE: Thanks, this makes the abstract much more self-contained. Some
suggested nits here:
"can be applied to CoAP protocol" --> "can be applied to the CoAP protocol"
"While the RFC8724 describes" --> "While RFC8724 describes"
"differs from IPv6 and UDP one" --> "differs from IPv6 and UDP" or
"differs from the IPv6 and UDP one"

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

TE: I see. Could you briefly point this out in the document, i.e., say
"The way the context is configured or exchanged is out of the scope for
this document", please?

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

TE: Thanks for the explanation. Maybe here it's worth rephrasing "which
allows a single Rule to process message headers differently depending of
the direction" to make this more explicit.

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

TE: I see. Suggested new phrasing:
"The direction allows splitting the range of values in two parts, one
for each direction, and allows the same rule to handle traffic in both
directions."

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

TE: I see. Suggested new phrasing:
"In IPv6 and UDP, header fields have a fixed size, which is not sent."

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

TE: Makes sense. I suggest adding this explanation to the document.

I'm looking forward to the next revision.

Best,
Theresa

---

From: Laurent Toutain <[email-masked]>
Date: Fri, 6 Mar 2020 08:50:46 +0100

Hi Theresa,

Thank you again for your in-depth review. We have published a version 13
with the modifications, see below:

On Mon, Mar 2, 2020 at 2:10 PM Theresa Enghardt <[email-masked]> wrote:

> Dear Ana,
>
> Thank you for the responses to my comments and for the improvements to the
> document.
>
>> 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
> 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."
>
> LT: Done

>
> "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
>> configured on the devices when installing the application? Are contexts
>> 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.
>
> LT: Done

>
>> "[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
>> this in conflict, so it makes SCHC more difficult to use for CoAP? Or
>> does this
>> 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 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?
>>
> "The direction allows splitting the range of values in two parts, one for
> each direction, and allows the same rule to handle traffic in both
> directions."
>
>
> LT: Done

>
>
>> "In IPv6 and UDP, header fields have a fixed size and it is not sent." -
>> What
> 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
>
> LT: Added: In IPv6 and UDP, header fields have a fixed size, defined in
the Rule, which is not sent.

>
>
>> 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.
>>
> transmission. Otherwise, it will have to be sent in the compression residue.
> 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.
>

LT: perfect, done

> I'm looking forward to the next revision.

For the security section after discussion in the intermin meeting, we
propose to add this:

*This document does not have any more Security consideration than the ones
already raised on {{rfc8724}}. 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 used to indicate the information that should be reconstructed
at the other end, but on the contrary the information sent as a Residue.
Therefore, if a length is set to a high value, but the number of bits on
the SCHC packet is smaller, the packet must be dropped by the decompressor.*

*OSCORE compression is also based on the same compression method described
in {{rfc8427}}. 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. This operation may be long and energy consuming.*

Laurent

---

From: Theresa Enghardt <[email-masked]>
Date: Mon, 9 Mar 2020 20:26:03 -0700

Hi Laurent,

Thanks for the new revision, which greatly improves the document.

However, I have a few comments on your new text:

In the text at the beginning of Section 3, you added text to give more
context, which is a great idea.
However, I'm not sure about the first sentence:
"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."
To me the last part of this sentence sounds like for CoAP you have to
define a rule to match both a request and a reply packet, so you would
have to match two packets (in a single rule?). Is this really the case?
I thought a single rule always matches one packet, but maybe I
misunderstood. In any case, could you rephrase this to make it more
clear, please?

Also, I saw some typos and grammar errors in Section 3:
s/optmize/optimize/
s/To performs/To perform/
s/TV might be use/TV might be used/
s/Resulting in a smaller compression residue./This results in a smaller
compression residue./

Some more nits in Section 7.3:
s/TheSCHC/The SCHC/
s/alreadypresent/already present/
s/in section Section 4/in Section 4/

Regarding the Security Considerations, thanks for discussing this in
your interim meeting and for adding text.

I'll leave the judgment of whether any security aspects are still
missing etc. to the Secdir reviewer and/or ADs.

Regarding the text you added:

On 05.03.20 23:50, Laurent Toutain wrote:
> /This document does not have any more Security consideration than the
> ones already raised on {{rfc8724}}. 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 used to indicate the information
> that should be reconstructed at the other end, but on the contrary the
> information sent as a Residue. Therefore, if a length is set to a high
> value, but the number of bits on the SCHC packet is smaller, the
> packet must be dropped by the decompressor./
>
Overall, I find this paragraph difficult to follow.

What is the relationship between the first sentence and the rest of the
paragraph?
First you say there are not more Security Considerations, then you say
that there are?

Please add a sentence that provides a context for your statements. Is
this a consideration that implementations need to be aware of in case
variable residues are used? Or is this a suggestion to use variable
length residues to make something more/less secure?

What is a packet expansion? I haven't seen this term in the rest of the
document. Is it a problem if they (the variable length residues or the
URI elements?) cannot produce a packet expanision?
This sentence is hard to parse and seems gramatically broken: "The
length send is not used to indicate the information that should be
reconstructed at the other end, but on the contrary the information sent
as a Residue."

> //
>
> /OSCORE compression is also based on the same compression method
> described in {{rfc8427}}. 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. This operation may be long and
> energy consuming./
>
"This operation may be long and energy consuming." - Which operation?
The previous sentence talks about the size of an initialization vector,
not about an operation.

Thanks,
Theresa

---

From: Alissa Cooper <[email-masked]>
Date: Wed, 11 Mar 2020 15:44:10 -0400

Theresa, thanks for your review. Authors, thanks for your responses. I entered a No Objection ballot pointing out the remaining issues with the security considerations.

Alissa

> On Mar 9, 2020, at 11:26 PM, Theresa Enghardt <[email-masked]> wrote:
> 
> Hi Laurent,
> 
> In the text at the beginning of Section 3, you added text to give more context, which is a great idea.
> "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."
> To me the last part of this sentence sounds like for CoAP you have to define a rule to match both a request and a reply packet, so you would have to match two packets (in a single rule?). Is this really the case? I thought a single rule always matches one packet, but maybe I misunderstood. In any case, could you rephrase this to make it more clear, please?
> 
> s/Resulting in a smaller compression residue./This results in a smaller compression residue./
> 
> Regarding the Security Considerations, thanks for discussing this in your interim meeting and for adding text.
> 
> I'll leave the judgment of whether any security aspects are still missing etc. to the Secdir reviewer and/or ADs.
> 
>> For the security section after discussion in the intermin meeting, we propose to add this:
>> 
>> This document does not have any more Security consideration than the ones already raised on {{rfc8724}}. 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 used to indicate the information that should be reconstructed at the other end, but on the contrary the information sent as a Residue. Therefore, if a length is set to a high value, but the number of bits on the SCHC packet is smaller, the packet must be dropped by the decompressor.
>> 
> What is the relationship between the first sentence and the rest of the paragraph?
> First you say there are not more Security Considerations, then you say that there are?
> 
> Please add a sentence that provides a context for your statements. Is this a consideration that implementations need to be aware of in case variable residues are used? Or is this a suggestion to use variable length residues to make something more/less secure?
> 
> What is a packet expansion? I haven't seen this term in the rest of the document. Is it a problem if they (the variable length residues or the URI elements?) cannot produce a packet expanision?
> This sentence is hard to parse and seems gramatically broken: "The length send is not used to indicate the information that should be reconstructed at the other end, but on the contrary the information sent as a Residue."
> 
> 
>> OSCORE compression is also based on the same compression method described in {{rfc8427}}. 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. This operation may be long and energy consuming.
>> 
> "This operation may be long and energy consuming." - Which operation? The previous sentence talks about the size of an initialization vector, not about an operation.
> 
> 
> Thanks,
> Theresa
> _______________________________________________
> Gen-art mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/gen-art