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

[Ana Minaburo <[e-mail]>]

Dear Benjamin, Dear Charlie

We wish you a Happy New Year! We want to thank you for all your work
reading and giving valuable inputs.

We are trying to finish all the DISCUSS and COMMENT points, and before
publishing version -17, we would like to clarify some of them.

See my answers and questions below

On Fri, Dec 11, 2020, at 3:18 AM Benjamin Kaduk via Datatracker <
[e-mail]> wrote:

> Benjamin Kaduk has entered the following ballot position for
> draft-ietf-lpwan-coap-static-context-hc-16: 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:
> ----------------------------------------------------------------------
>
> This point from my previous review does not seem to be addressed:
>
> 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.
>

AM: I think there is an error here, we made the following changes to the
first paragraph of section 9. Please tell us what is missing at this point?

Text -15:

When applied to LPWAN, the Security Considerations of SCHC header
   compression [rfc8724] are valid for SCHC CoAP header compression.
   When CoAP uses OSCORE, the security considerations defined in
   [rfc8613] does not change when SCHC header compression is applied.

Text -16:
"When applied *on top of LPWAN*, 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."


>
> I'm also still a bit confused by the examples in Section 2 -- the prose
> says:
>
>    In the first example, Figure 1, a Rule compresses the complete header
>    stack from IPv6 to CoAP.  In this case, SCHC C/D (Static Context
>    Header Compression Compressor/Decompressor) is performed at the
>    device and the application.  The host communicating with the device
>    does not implement SCHC C/D.
>
> but the figure itself shows a box for SCHC in the NGW, and does not show
> such a box in the Application.  How is the figure consistent with the
> quoted prose?  (The new paragraph added after the figure seems to match
> up more naturally with the figure; was the paragraph before the figure
> intended to be deleted?)
>
> AM: You are right the text must be updated to explain Figure 1.
Text -16:

In the first example, Figure 1, a Rule compresses the complete header
   stack from IPv6 to CoAP.  In this case, SCHC C/D (Static Context
   Header Compression Compressor/Decompressor) is performed at the
   device and the application.  The host communicating with the device
   does not implement SCHC C/D.


New Text to appear -17:
In the first example, {{Fig-SCHCCOAP1}}, a Rule compresses the complete
header stack from IPv6 to CoAP. In this case, SCHC C/D (Static Context
Header Compression Compressor/Decompressor) is performed at the device and
the *NGW*. The *Application* communicating with the device does not
implement SCHC C/D.


> ----------------------------------------------------------------------
> COMMENT:
> ----------------------------------------------------------------------
>
> A few final editorial notes/nits.
>
> Section 1
>
>    REST-based (Representational state transfer) services.  Although CoAP
>    was designed for Low-Power Wireless Personal Area Networks (6LoWPAN),
>    a CoAP header's size is still too large for LPWAN (Low Power Wide
>    Area Networks) and some compression of the CoAP header is required
>
> I confess I read this too fast the first time and thought the "6LoWPAN"
> was another "LPWAN" (which would be a pretty strange thing to say,
> effectively that CoAP failed at its mission).  I can't speak with
> certainty one way or the other whether 6LoWPAN was the sole focus of
> CoAP development, so if you can't speak with certainty either, the more
> generic "constrained devices" might be a better choice.
>

AM: Changed
New Text to appear -17:
"... REST-based (Representational state transfer) services. Although CoAP
was designed for *constrained devices*, a CoAP header's size is still 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 over
some LPWAN technologies. "


>    RuleID and some residual bits.  Thus, different Rules may correspond
>    to divers protocols packets that a device expects to send or receive.
>
> nits: s/divers protocols/diverse protocol/
>
AM: Done

>
>    In that case, a Compression/Decompression Action (CDA) associated
>    with each field give the method to compress and decompress each
>
> nit: s/give/gives/
>
AM: Done

>
> Section 2
>
>    This use case needs an end-to-end context initialization between the
>    device and the application and is out-of-scope of this document.
>
> nit: s/and is out-of-scope/that is out of scope/
>
AM: Done

>
>    In the case of several SCHC instances, as shown in Figure 3 and
>    Figure 3, the rulesets may come from different provisioning domains.
>
> Was one of the '3's supposed to be a '2'?
>
AM: Yes, thanks, good catch! Changed
Nex text to appear -17:
"In the case of several SCHC instances, as shown in {{Fig-SCHCCOAP2}} and
{{Fig-SCHCCOAP3}}, the rulesets may come from different provisioning
domains."

>
> 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
>       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.  [...]
>
> I'd suggest to replace all the "may"s with "might"s, but that's mostly
> editorial.  ("Might" is much less likely to be misread as granting
> permission as opposed to indicating a possibility.)
>

AM: Done
New text to appear -17
"The CoAP protocol is asymmetric; the headers are different for a
  request or a response. For example, the URI-Path option is mandatory in
the request, and it *might* not be present in the response.  A
  request *might* contain an Accept option, and the response *might*
include a Content-Format option. "


> Section 7.3
>
> nitty nit: Figures 18 and 21 list the FL for CoAP Token as just "tkl",
> but "tkl" measures bytes and FL measures bits, so in some sense it is
> off by a factor of 8.  (Indicating this while still fitting in the table
> width seems nearly impossible, though.  Perhaps just some prose to
> relate TKL to tkl would be enough.)
>

AM: There were some TKL in lowercase that may be in Uppercase because they
are the Token Length value. The tkl is a function that gives the variable
length of the Token value in bytes. Section 4.5 CoAP Token fields explain
this point:

"A Token is defined through two CoAP fields, Token Length in the mandatory
header and
Token Value directly following the mandatory CoAP header.

Token Length is processed as any protocol field. If the value does not
change, the size can be stored in the TV and elided during the
transmission. Otherwise, it will have to be sent in the Compression Residue.

Token Value MUST NOT be sent as a variable-length residue to avoid
ambiguity with Token
Length. Therefore, the Token Length value MUST be used to define the size
of the Compression Residue.
A specific function designated as "tkl" MUST be used in the Rule. During
the decompression, this function returns the value contained in the Token
Length field."



> Section 9
>
> My previous comments on the security considerations section do not
> appear to have been acted upon; I believe they remain relevant and will
> duplicate them here:


> 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".
>
AM: Changed

>
>    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".
>
> AM: Yes, you are right. Changed
New text to appear -17:
"DoS attacks are possible if an intruder can introduce a corrupted SCHC
compressed packet onto the link and cause an excessive resource consumption
at the decompressor. However, an intruder having the ability to add
corrupted packets at the link layer raises additional security issues than
those related to the use of header compression."


>    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".
>
> AM: We were asked to explain how SCHC would react in the case it receives
a ZIP bomb, and as you say the decompressor will start parsing data as part
of the header. When it runs out of data, it will drop the packet. But when
there is enough data, the packet will be sent to the upper layers. The SCHC
decompressor will not be desynchronized because SCHC
compresses/decompresses each packet independently. We clearly lack words to
explain this problem and show that SCHC will not be affected.


> 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).
>
>
> First, point SECDIR-15: "This draft defines how SCHC (Static Context
Header Compression) should be applied to the CoAP (Constrained Application
Protocol). It appears that CoAP is designed for low-end devices speaking
standard protocols with a lot of static content they would like to suppress
to avoid wasting processing time and communications overhead. That means
that these devices are likely to be generating and parsing the compressed
content directly rather than generating the full content and then
compressing it. One security considerations worth noting is that whenever
compression is used with a protocol intended to be encrypted (which this
one is), the question should be raised as to whether the compression can be
leveraged by an attacker to make traffic analysis more effective. In this
case, I don't believe it can, but there should probably be an explanation
of why in the security considerations. (The explanation is that the values
in earlier fields do not affect the compression of later fields, so an
attacker cannot supply values whose length after compression will leak the
values of other compressed fields)."

AM: If you refer to BREACH and CRIME attacks, this point has been treated
in the RFC8724 section 12.1.2. We don't know if it is valuable to add in
the security section, that since SCHC CoAP compression doesn't modify the
RFC8724 SCHC compression mechanism then we are not introducing this kind of
threats.

Second Point:
"This document is very difficult to read and could use an editing pass by a
native English speaker, but I suspect that is not its only problem.
Synchronizing the compression parameters is explicitly out of scope for
this document, but this document allows for so many different variations in
the parameter settings that it's not clear whether these settings are
intended to by dynamically negotiated."

AM: In the Interim Meeting of January the 5th, the WG is preparing a
document with the Architecture and this document will raise these problems
of synchronization and parameter settings. So for us, this point is also
out of scope.

Third Point:

While there are lots of aspects of this specification that I'm
uncertain about, I am fairly certain it does not introduce any
security problems.


Many Nits:
AM: Changed

On Fri, Dec 11, 2020 at 3:18 AM Benjamin Kaduk via Datatracker <
[e-mail]> wrote:

> Benjamin Kaduk has entered the following ballot position for
> draft-ietf-lpwan-coap-static-context-hc-16: 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:
> ----------------------------------------------------------------------
>
> This point from my previous review does not seem to be addressed:
>
> 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.
>
> I'm also still a bit confused by the examples in Section 2 -- the prose
> says:
>
>    In the first example, Figure 1, a Rule compresses the complete header
>    stack from IPv6 to CoAP.  In this case, SCHC C/D (Static Context
>    Header Compression Compressor/Decompressor) is performed at the
>    device and the application.  The host communicating with the device
>    does not implement SCHC C/D.
>
> but the figure itself shows a box for SCHC in the NGW, and does not show
> such a box in the Application.  How is the figure consistent with the
> quoted prose?  (The new paragraph added after the figure seems to match
> up more naturally with the figure; was the paragraph before the figure
> intended to be deleted?)
>
>
> ----------------------------------------------------------------------
> COMMENT:
> ----------------------------------------------------------------------
>
> A few final editorial notes/nits.
>
> Section 1
>
>    REST-based (Representational state transfer) services.  Although CoAP
>    was designed for Low-Power Wireless Personal Area Networks (6LoWPAN),
>    a CoAP header's size is still too large for LPWAN (Low Power Wide
>    Area Networks) and some compression of the CoAP header is required
>
> I confess I read this too fast the first time and thought the "6LoWPAN"
> was another "LPWAN" (which would be a pretty strange thing to say,
> effectively that CoAP failed at its mission).  I can't speak with
> certainty one way or the other whether 6LoWPAN was the sole focus of
> CoAP development, so if you can't speak with certainty either, the more
> generic "constrained devices" might be a better choice.
>
>    RuleID and some residual bits.  Thus, different Rules may correspond
>    to divers protocols packets that a device expects to send or receive.
>
> nits: s/divers protocols/diverse protocol/
>
>    In that case, a Compression/Decompression Action (CDA) associated
>    with each field give the method to compress and decompress each
>
> nit: s/give/gives/
>
> Section 2
>
>    This use case needs an end-to-end context initialization between the
>    device and the application and is out-of-scope of this document.
>
> nit: s/and is out-of-scope/that is out of scope/
>
>    In the case of several SCHC instances, as shown in Figure 3 and
>    Figure 3, the rulesets may come from different provisioning domains.
>
> Was one of the '3's supposed to be a '2'?
>
> 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
>       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.  [...]
>
> I'd suggest to replace all the "may"s with "might"s, but that's mostly
> editorial.  ("Might" is much less likely to be misread as granting
> permission as opposed to indicating a possibility.)
>
> Section 7.3
>
> nitty nit: Figures 18 and 21 list the FL for CoAP Token as just "tkl",
> but "tkl" measures bytes and FL measures bits, so in some sense it is
> off by a factor of 8.  (Indicating this while still fitting in the table
> width seems nearly impossible, though.  Perhaps just some prose to
> relate TKL to tkl would be enough.)
>
> Section 9
>
> My previous comments on the security considerations section do not
> appear to have been acted upon; I believe they remain relevant and will
> duplicate them here:
>
> 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).
>
>
>
>