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

[Benjamin Kaduk via Datatracker <[e-mail]>]

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