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

[Ana Minaburo <[e-mail]>]

Dear Benjamin,

I hope you are well and safe.
We had an interim meeting today, and as there is no new review nor a change
on the IESG site. I want to ask you if you have some inputs to our version
16.

Thank you
Ana and authors.






On Mon, Nov 2, 2020 at 3:58 PM Eric Vyncke (evyncke) <[e-mail]>
wrote:

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