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 again (and thanks for splitting the DISCUSS and COMMENTS; it's easier to
keep track of this way).  Just a few notes inline...

On Tue, Oct 20, 2020 at 03:08:30PM +0200, Ana Minaburo wrote:
>    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".
> 
>     
> 
>    d-  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.

This is generally good, though I myself am not 100% sure that 6LoWPAN was
the sole focus for CoAP development.  Going back to the more generic
"constrained devices" might be safer, if you're not sure about it, either.

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


Thank you!!

>     
> 
>     
> 
>       After applying the compression there may be some bits to be sent,
> 
>       these values are called Compression Residues.
> 
>     
> 
>    nit: comma splice.
> 
>     
> 
>    d-  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.)
> 
>     
> 
>    d-  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.
> 
>    d-  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".
> 
>     
> 
>    d-  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".)
> 
>     
> 
>    d-  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.
> 
>     
> 
>    d-  We changed duration to value which common to all these options
> 
>    d-  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.
> 
>     
> 
>    d-  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.
> 
>     
> 
>    d-  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/.
> 
>    d-  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.
> 
>    d-  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.)
> 
>     
> 
>    d-  Done
> 
>     
> 
>    Section 7.1
> 
>     
> 
>       immediately acknowledged by the Device.  For this simple scenario,
> 
>       the Rules are described Figure 7.
> 
>     
> 
>    nit: "described in".
> 
>     
> 
>    d-  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".
> 
>     
> 
>    d-  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".
> 
>     
> 
>    d-  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. 

Ah, this helps me see what was intended here.  Could I suggest:

SCHC compression returns variable-length Residues for some CoAP fields.  In
the compressed header, the length that is sent is not the length of the
original header field, but rathe the length of the Residue that is
transmitted.  If a corrupted packet arrives at a decompressor that does not
match the length from the original packet, SCHC decompression will detect
an error and drop the packet.

(I don't see your version in the -16, for what it's worth.)

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

I'm not sure that these fixes made it into the published -16, either -- the
security considerations section is only a few words different than it was
in the -15.

I look forward to seeing the rest of the planned updates in a -17, and will
try to be faster to look at that than I was for the -16.

Thanks again,

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