Re: [lp-wan] Benjamin Kaduk's Discuss on draft-ietf-lpwan-coap-static-context-hc-15: (with DISCUSS and COMMENT)

[Ana Minaburo <[e-mail]>]

Thanks again for your comments, here you will find our modifications to
your requests.

===========
COMMENTS
===========

Thank you for the updates in response to my comments on the -13; they do

help.  I have a smaller volume of comments this time around :)



Abstract



References are not allowed in the abstract, so you should probably just

write out "RFC 8724".



ð  Changed





Introduction



   CoAP [rfc7252] is designed to easily interop with HTTP (Hypertext



What does "designed to easily interop with" mean?  CoAP and HTTP don't

interoperate directly, given that they are different protocols...



   done.  The context is known by both ends before transmission.  The

   way the context is configured, provisioned or exchanged is out of the

   scope of this document.



Changed to : CoAP [rfc7252] is a command/response protocol, designed for
micro-controllers with small amount of RAM and ROM, and is optimized for
REST-based (Representational

   state transfer) services.  Although CoAP was designed for Low-Power
Wireless Personal Area Networks (6LoWPAN), the size of a CoAP header still
is too large for

   LPWAN (Low Power Wide Area Networks) and some compression of the CoAP
header is required either to increase performances or allow CoAP other some
LPWAN technologies.







(editorial) I'd suggest rephrasing to something more like "The SCHC

compression scheme assumes as a prerequisite that the static context is

known to both endpoints before transmission."



ð  Done



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

   SCHC compression may apply at two different levels, one to compress

   IP and UDP as described in [rfc8724] in the LPWAN network and another

   at the application level.  These two compressions may be independent.



I think you want to reframe this in terms of the potential for there to

be multiple IP (UDP seems perhaps less likely?) entities processing the

packet between CoAP entities that process the packet, and note that the

IP compression may be removed by an intermediary in situations where

configured to do so.



ð  We changed to : CoAP is an application protocol, so CoAP

   compression requires to install common rules between the two SCHC
instances.

   SCHC compression may apply at two different levels: one to compress

   IP and UDP in the LPWAN network and another

   at the application level for CoAP.  These two compressions may be
independent.





   The Compression Rules can be set up by two independent entities and

   are out of the scope of this document.  In both cases, SCHC mechanism

   remains the same.



(nit) I don't think "remains the same" is the best wording here; there

are clearly going to be differences of some form between compression at

the UDP layer and compression at the CoAP layer, even though the overall

structure/procedures for compressing/decompressing at those layers are

analogous to each other.



ð  Changed to : SCHC compression may apply at two different levels: one to
compress IP and UDP in the LPWAN network and another at the application
level for CoAP.  These two compressions may be independent. Both follow the
same principle described in RFC 8724. SCHC rules driving the
compression/decompression are different and may be managed by different
entities. The [rfc8724] describes how the IP and UDP headers may be
compressed. This document specifies how the SCHC compression rules can be
applied to CoAP traffic.





   A Matching Operator (MO) is associated to each header field

   description.  The Rule is selected if all the MOs fit the TVs for all

   fields of the incoming header.



I strongly suggest reiterating that the presence of a header field that

does not have a corresponding MO in the Rule means that the Rule does

not apply to that packet.



ð  Adding the follows: A Matching Operator (MO) is associated to each
header field

   description.  The Rule is selected if all the MOs fit the TVs for all

   fields of the incoming header. *A rule cannot be selected if the message
contains a field unknown to the SCHC compressor.*





   After applying the compression there may be some bits to be sent,

   these values are called Compression Residues.



nit: comma splice.



ð  Done



Section 2



I think that these examples would benefit from a fair bit more

description/discussion text.  For example, if SCHC in Figure 1 is

supposed to be compressing everything from IPv6 to CoAP, why is SCHC

beween LPWAN and IPv6 (vs above IPv6), and why does the full stack still

appear at the 'device'?  If the Sender and Receiver are to be the device

and App, then why is SCHC not apparent at the Receiver (app)?  I can't

find a consistent way to interpret the text and the figure.

(Figures 2 and 3 have both dotted lines and dashed lines.  Why are they

different?  Etc.)



ð  All the section has been reviewed.



Section 3.1



   o  The CoAP protocol is asymmetric, the headers are different for a

      request or a response.  For example, the URI-path option is



nit: comma splice.

ð  Done



   o  Headers in IPv6 and UDP have a fixed size.  The size is not sent

      as part of the Compression Residue, but is defined in the Rule.

      Some CoAP header fields have variable lengths, so the length is

      also specified in the Field Description.  For example, the Token



RFC 8724 uses "Field Descriptor", not "Field Description".



ð  Done



Section 5



   the description of the Option by using in the Field ID the Option

   Number built from D-T; in TV, the Option Value; and the Option Length

   uses section 7.4 of RFC8724.  When the Option Length has a wellknown



(It looks like the subsections of 7.4 are also important, though we

probably don't need to literally say "section 7.4 and subsections".)



ð  We kept section 7.4 of RFC8724



Section 5.2



I'm still confused why Max-Age, Uri-Host, and Uri-Port are in the same

section.  We talk about "the duration", but that seems to only apply to

Max-Age.



   Otherwise these options can be sent as a Compression Residue (fixed

   or variable length).



I'm not sure that there's going to be a practical scenario where a

fixed-length residue is workable for anay of these three CoAP Options.



ð  We changed duration to value which common to all these options

ð  We removed the text in parenthesis





Section 5.4



As far as I can tell, Proxy-URI and Proxy-Scheme are indeed

unidirectional (only sent in requests).  It would perhaps be appropriate

to codify this restirction in the compression rules, though I can

understand if the general desire is to not add an additional layer of

restrictions beyond the core CoAP specificiation.



ð  We keep as it is, because it is an implementation issue.



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 this saying that if you have a rule that allows sending Observe, you

MUST also have a rule allowing RST?  It might be worth making that more

explicit.



ð  Changed to : Since an RST message may be sent to inform a server that
the client does not require Observe response; a Rule SHOULD exist to allow
the compression of the message with the RST type.



Section 6.4



   The first byte specifies the content of the OSCORE options using

   flags.  The three most significant bits of this byte are reserved and



nit: s/options/option/.

ð  Done



   This specification recommends identifying the OSCORE Option and the

   fields it contains Conceptually, it discerns up to 4 distinct pieces

   of information within the OSCORE option: the flag bits, the piv, the



I'm not sure what was intended to happen here.  Either there's a missing

full stop or a wrongly capitalized word, at a start, but perhaps there

was also supposed to be some additional rewording to join the sentences

together more fluidly.

ð  Done



   The OSCORE Option shows superimposed these four fields using the

   format Figure 6, the CoAP OSCORE_kidctxt field includes the size bits

   s.



The rewording went awry here.  I think it's supposed to be more like

"Figure 6 shows the OSCORE Option format with those four fields

superimposed on it.  Note that the CoAP OSCORE_kidctxt field includes

the size octet s".



(Also, I am not sure I've seen the "ctxt" abbreviation anywhere other

than this document.  Just "ctx" seems much more common in my

experience.)



ð  Done



Section 7.1



   immediately acknowledged by the Device.  For this simple scenario,

   the Rules are described Figure 7.



nit: "described in".



ð  Done



Section 9



The need for additional English review is particularly pronounced in the

new text here.  (I am not attempting to note all instances that would

benefit from extra attention.)



   DoS attacks are possible if an intruder can introduce a compressed

   SCHC corrupted packet onto the link and cause a compression



nit: I think this would be "introduce a corrupted SCHC compressed

packet".



ð  Done



   efficiency reduction.  However, an intruder having the ability to add



Usually I think of "compression efficiency" as relating to the ratio of

sizes between compressed and uncompressed form.  What seems to be

described here is instead the resource efficiency of the entity

performing the decompression function, so I'd suggest using a different

phrasing, such as "excessive resource consumption at the decompressor".



   SCHC compression returns variable-length Residues for some CoAP

   fields.  In the compressed header, the length sent is not the

   original header field length but the length of the Residue.  So if a

   corrupted packet comes to the decompressor with a longer or shorter

   length than the one in the original header, SCHC decompression will

   detect an error and drops the packet.



I don't think I understand the mechanism being described here.  It

sounds as if there is supposed to be some error-checking ability between

the recovered (uncompressed) text and the original header, but I don't

see such a mechanism.  The length in the compressed packet is used to

interpret the residue and produce the recovered (uncompressed) value,

but the original packet is not available for comparison at that time.

If the length in the compressed packet is modified, then the

decompressor will get desychronized from the bit stream and start trying

to parse "random" data as the rest of the packet; that would be expected

to usually produce an error eventually, but I'm not convinced that this

is the mechanism referred to by "detect an error and drops [sic] the

packet".



ð  We have simplified to : SCHC compression returns variable-length
Residues for some CoAP

   fields. Since this length indicates the number of bytes send, an
attacker modifying this value will not be allowed to produce larger packet
than initially compressed.





The secdir review of the -15 made some good points and suggestions,

including pointing out in the security considerations that the typical

compression attacks we worry about aren't an issue here (and why).


 => All nits have been changed. thanks for this review too.



On Thu, Jul 16, 2020 at 3:30 AM Benjamin Kaduk via Datatracker <
[e-mail]> wrote:

> Benjamin Kaduk has entered the following ballot position for
> draft-ietf-lpwan-coap-static-context-hc-15: Discuss
>
> When responding, please keep the subject line intact and reply to all
> email addresses included in the To and CC lines. (Feel free to cut this
> introductory paragraph, however.)
>
>
> Please refer to https://www.ietf.org/iesg/statement/discuss-criteria.html
> for more information about IESG DISCUSS and COMMENT positions.
>
>
> The document, along with other ballot positions, can be found here:
> https://datatracker.ietf.org/doc/draft-ietf-lpwan-coap-static-context-hc/
>
>
>
> ----------------------------------------------------------------------
> DISCUSS:
> ----------------------------------------------------------------------
>
> I don't think we quite managed to catch all the collatoral damage from
> my previous discuss points on the -13.  In particular, while Sections
> 5.x no longer attempt to discuss directionality of CoAP Options, there
> are some in-passing references to them in Section 3.1:
>
> - There's a claim that URI-Path (though, spelled as "URI-path") is not
>   present in the response, which is incorrect.
>
> - There's a reference to a nonexistent "Content" option as being present
>   only in a response, but the "Content-Format" option is allowed in both
>   requests and responses.  (See, e.g., the PUT method for use of
>   Content-Format in a request.)
>
> - The "Accept" option is referenced as only being present in requests.
>   This seems to be accurate as far as I can see in RFC 7252, though in
>   light of the near-complete removal of such references from this
>   document, perhaps it should also be removed.
>
> While the expanded security considerations do cover several important
> points, I think it's important to specifically state that the RFC 8724
> procedures assume that SCHC is implemented on top of LPWAN technologies
> that implement security mechanisms.  I think we also need to specify
> that either (a) this assumption remains for the CoAP usage of SCHC, or
> that (b) CoAP has use cases outside of LPWAN, and when SCHC is used in
> those non-LPWAN cases, the attacks (such as are now described in the
> -15) are more readily performed than in the secure LPWAN environment
> when no other integrity protection mechanism is in place for the
> compressed packets.
>
> As Francesca noted on the -13, we need to acknowledge that there are and
> will be in the future CoAP options that are not included in this
> document and provide some indication of how they might be handled.
> Whether that's to define new compression rules/guidance for them, always
> send them as full residuals, or some other behavior can be decided in
> the future on a per-option basis, but we can give some guidance here on
> how we plan to support extensibility of options.
>
> ---
>
> The -15 introduced some new text in the Introduction:
>
>    CoAP is an End-to-End protocol at the application level, so CoAP
>    compression requires to install common Rules between two hosts and IP
>
> It's not entirely clear to me that this is true, given that CoAP proxies
> are a first-class protocol feature.  OSCORE is probably fair to describe
> as end-to-end, but CoAP itself may not be.
>
> Also, the new examples in Section 2 are sufficiently hard to follow that
> I can't be sure the figures and the prose descriptions are internally
> consistent.  (See COMMENT for a few more specifics.)
>
>
> ----------------------------------------------------------------------
> COMMENT:
> ----------------------------------------------------------------------
>
> Thank you for the updates in response to my comments on the -13; they do
> help.  I have a smaller volume of comments this time around :)
>
> Abstract
>
> References are not allowed in the abstract, so you should probably just
> write out "RFC 8724".
>
> Introduction
>
>    CoAP [rfc7252] is designed to easily interop with HTTP (Hypertext
>
> What does "designed to easily interop with" mean?  CoAP and HTTP don't
> interoperate directly, given that they are different protocols...
>
>    done.  The context is known by both ends before transmission.  The
>    way the context is configured, provisioned or exchanged is out of the
>    scope of this document.
>
> (editorial) I'd suggest rephrasing to something more like "The SCHC
> compression scheme assumes as a prerequisite that the static context is
> known to both endpoints before transmission."
>
>    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.  Therefore,
>    SCHC compression may apply at two different levels, one to compress
>    IP and UDP as described in [rfc8724] in the LPWAN network and another
>    at the application level.  These two compressions may be independent.
>
> I think you want to reframe this in terms of the potential for there to
> be multiple IP (UDP seems perhaps less likely?) entities processing the
> packet between CoAP entities that process the packet, and note that the
> IP compression may be removed by an intermediary in situations where
> configured to do so.
>
>    The Compression Rules can be set up by two independent entities and
>    are out of the scope of this document.  In both cases, SCHC mechanism
>    remains the same.
>
> (nit) I don't think "remains the same" is the best wording here; there
> are clearly going to be differences of some form between compression at
> the UDP layer and compression at the CoAP layer, even though the overall
> structure/procedures for compressing/decompressing at those layers are
> analogous to each other.
>
>    A Matching Operator (MO) is associated to each header field
>    description.  The Rule is selected if all the MOs fit the TVs for all
>    fields of the incoming header.
>
> I strongly suggest reiterating that the presence of a header field that
> does not have a corresponding MO in the Rule means that the Rule does
> not apply to that packet.
>
>    After applying the compression there may be some bits to be sent,
>    these values are called Compression Residues.
>
> nit: comma splice.
>
> Section 2
>
> I think that these examples would benefit from a fair bit more
> description/discussion text.  For example, if SCHC in Figure 1 is
> supposed to be compressing everything from IPv6 to CoAP, why is SCHC
> beween LPWAN and IPv6 (vs above IPv6), and why does the full stack still
> appear at the 'device'?  If the Sender and Receiver are to be the device
> and App, then why is SCHC not apparent at the Receiver (app)?  I can't
> find a consistent way to interpret the text and the figure.
> (Figures 2 and 3 have both dotted lines and dashed lines.  Why are they
> different?  Etc.)
>
> Section 3.1
>
>    o  The CoAP protocol is asymmetric, the headers are different for a
>       request or a response.  For example, the URI-path option is
>
> nit: comma splice.
>
>    o  Headers in IPv6 and UDP have a fixed size.  The size is not sent
>       as part of the Compression Residue, but is defined in the Rule.
>       Some CoAP header fields have variable lengths, so the length is
>       also specified in the Field Description.  For example, the Token
>
> RFC 8724 uses "Field Descriptor", not "Field Description".
>
> Section 5
>
>    the description of the Option by using in the Field ID the Option
>    Number built from D-T; in TV, the Option Value; and the Option Length
>    uses section 7.4 of RFC8724.  When the Option Length has a wellknown
>
> (It looks like the subsections of 7.4 are also important, though we
> probably don't need to literally say "section 7.4 and subsections".)
>
> Section 5.2
>
> I'm still confused why Max-Age, Uri-Host, and Uri-Port are in the same
> section.  We talk about "the duration", but that seems to only apply to
> Max-Age.
>
>    Otherwise these options can be sent as a Compression Residue (fixed
>    or variable length).
>
> I'm not sure that there's going to be a practical scenario where a
> fixed-length residue is workable for anay of these three CoAP Options.
>
> Section 5.4
>
> As far as I can tell, Proxy-URI and Proxy-Scheme are indeed
> unidirectional (only sent in requests).  It would perhaps be appropriate
> to codify this restirction in the compression rules, though I can
> understand if the general desire is to not add an additional layer of
> restrictions beyond the core CoAP specificiation.
>
> 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 this saying that if you have a rule that allows sending Observe, you
> MUST also have a rule allowing RST?  It might be worth making that more
> explicit.
>
> Section 6.4
>
>    The first byte specifies the content of the OSCORE options using
>    flags.  The three most significant bits of this byte are reserved and
>
> nit: s/options/option/.
>
>    This specification recommends identifying the OSCORE Option and the
>    fields it contains Conceptually, it discerns up to 4 distinct pieces
>    of information within the OSCORE option: the flag bits, the piv, the
>
> I'm not sure what was intended to happen here.  Either there's a missing
> full stop or a wrongly capitalized word, at a start, but perhaps there
> was also supposed to be some additional rewording to join the sentences
> together more fluidly.
>
>    The OSCORE Option shows superimposed these four fields using the
>    format Figure 6, the CoAP OSCORE_kidctxt field includes the size bits
>    s.
>
> The rewording went awry here.  I think it's supposed to be more like
> "Figure 6 shows the OSCORE Option format with those four fields
> superimposed on it.  Note that the CoAP OSCORE_kidctxt field includes
> the size octet s".
>
> (Also, I am not sure I've seen the "ctxt" abbreviation anywhere other
> than this document.  Just "ctx" seems much more common in my
> experience.)
>
> Section 7.1
>
>    immediately acknowledged by the Device.  For this simple scenario,
>    the Rules are described Figure 7.
>
> nit: "described in".
>
> Section 9
>
> The need for additional English review is particularly pronounced in the
> new text here.  (I am not attempting to note all instances that would
> benefit from extra attention.)
>
>    DoS attacks are possible if an intruder can introduce a compressed
>    SCHC corrupted packet onto the link and cause a compression
>
> nit: I think this would be "introduce a corrupted SCHC compressed
> packet".
>
>    efficiency reduction.  However, an intruder having the ability to add
>
> Usually I think of "compression efficiency" as relating to the ratio of
> sizes between compressed and uncompressed form.  What seems to be
> described here is instead the resource efficiency of the entity
> performing the decompression function, so I'd suggest using a different
> phrasing, such as "excessive resource consumption at the decompressor".
>
>    SCHC compression returns variable-length Residues for some CoAP
>    fields.  In the compressed header, the length sent is not the
>    original header field length but the length of the Residue.  So if a
>    corrupted packet comes to the decompressor with a longer or shorter
>    length than the one in the original header, SCHC decompression will
>    detect an error and drops the packet.
>
> I don't think I understand the mechanism being described here.  It
> sounds as if there is supposed to be some error-checking ability between
> the recovered (uncompressed) text and the original header, but I don't
> see such a mechanism.  The length in the compressed packet is used to
> interpret the residue and produce the recovered (uncompressed) value,
> but the original packet is not available for comparison at that time.
> If the length in the compressed packet is modified, then the
> decompressor will get desychronized from the bit stream and start trying
> to parse "random" data as the rest of the packet; that would be expected
> to usually produce an error eventually, but I'm not convinced that this
> is the mechanism referred to by "detect an error and drops [sic] the
> packet".
>
> The secdir review of the -15 made some good points and suggestions,
> including pointing out in the security considerations that the typical
> compression attacks we worry about aren't an issue here (and why).
>
>
>
>