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

["Eric Vyncke (evyncke)" <[e-mail]>]

Hello Ben,

Ana and the authors have uploaded -16 with the changes as indicated below.

So, allow me to send a gentle nudge for your review of the changes and the replies below ;-)

Regards

-éric

From: lp-wan <[e-mail]> on behalf of Ana Minaburo <[e-mail]>
Date: Tuesday, 20 October 2020 at 15:09
To: Benjamin Kaduk <[e-mail]>
Cc: lp-wan <[e-mail]>, "[e-mail]" <[e-mail]>, Pascal Thubert <[e-mail]>, "[e-mail]" <[e-mail]>, The IESG <[e-mail]>
Subject: Re: [lp-wan] Benjamin Kaduk's Discuss on draft-ietf-lpwan-coap-static-context-hc-15: (with DISCUSS and COMMENT)

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]<mailto:[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).