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

[Benjamin Kaduk <[e-mail]>]

Hi Ana,

My apologies for the slow response here; I have been a bit overwhelmed.

The changes in the -16 are generally improvements, but I think we are not
quite done (in particular, some of the changes proposed here did not make
it into the -16).  More inline...

On Tue, Oct 20, 2020 at 03:05:04PM +0200, Ana Minaburo wrote:
>    Dear Benjamin, 
>    Thank you very much for your inputs and your detailed review. We have been
>    working hard to answer all your requests.
>    For the DISCUSSION part, here are our modifications made on version 16.
> 
>    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.
> 
>     
> 
>    d-  We have changed the first bullet in section 3.1. Instead of 
> 
>    o   it is not present 
> 
>    o   it may not be
> 
>    New Text : the URI-Path option is mandatory in the request, and it may not
>    be present in the response.
> 
>     
> 
>    - 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.)
> 
>    d-  Changed
> 
>     
> 
>     
> 
>    - 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.
> 
>    d-  We have split into two different examples.
> 
>    New text : For example, the URI-Path option is mandatory in the request,
>    and it may not be present in the response.  A request may contain an
>    Accept option, and the response may include a Content-Format option.  In
>    comparison, IPv6 and UDP returning path swap the value of some fields in
>    the header.

This part looks like it will work; thanks.

>     
> 
>     
> 
>    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.
> 
>    d-  You'are rigth, we have added the option when there is not LPWAN
>    technology at L2.
> 
>    New Text: When applied on top of LPWAN technologies, the Security
>    Considerations of SCHC header
> 
>       compression [rfc8724] are valid for SCHC CoAP header compression. When
>    other technologies are used, an integrity protection mechanism must be
>    defined to carry SCHC compressed packets.
> 
>       When CoAP uses OSCORE, the security considerations defined in
> 
>       [rfc8613] does not change when SCHC header compression is applied.

This text looks pretty good (I would change the "must" to "MUST" in "MUST
be defined" though reasonable people might disagree).
I don't see it anywhere in the -16, though.

>     
> 
>     
> 
>     
> 
>    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.
> 
>     
> 
>    d-  We have added the following new text :
> 
>    d-  At the end of Section 5
> 
>    If a new option is introduced in CoAP, a new Field ID has to be assigned
>    in the Rules to allow its compression. Otherwise, if no Rule describes
>    this Option the SCHC compression is not possible and the CoAP header is
>    sent without compression.
> 
>     
> 
>    ---
> 
>     
> 
>    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.
> 
>    d-  We have changed to this new text :
> 
>    CoAP is an application protocol, so CoAP compression requires to install
>    common rules between the two SCHC instances. 

These bits look good.

>     
> 
>     
> 
>    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.)
> 
>    d-  We've updated all the section

The new descriptions do help quite a bit; thank you!
I think that perhaps the intent was to remove the paragraph before Figure
1, though, since it seems to be describing something quite different from
both the figure and the (new) paragraph after the figure.

Thanks, and sorry again for the delay,

Ben

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