[lp-wan] Benjamin Kaduk's Discuss on draft-ietf-lpwan-coap-static-context-hc-13: (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-13: 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:
----------------------------------------------------------------------

Section 5.2 claims that Uri-Host and URI-Port are unidirectional from
server to client and "[are] never found in client requests", which seems
to contradict Section 5.10.1 of RFC 7252.  It seems like maybe this
section is supposed to only cover Max-Age, with Uri-Host and Uri-Port
rolled into Section 5.3 along with Uri-Path and Uri-Query?

Similarly, Section 5.4 says that size1 and size2 are unidirectional
(only in requests), which does not seem to be accurate given my reading
of RFCs 7252 and 7599.

I also think that we need some further discussion (e.g., in the security
considerations) about how the base LPWAN SCHC document assumes that
MAC-layer LPWAN security mechanisms are in use, but that CoAP is not
restricted to such contexts.  What additional security considerations
are relevant when this compression is used for CoAP without LPWAN
MAC-layer cryptographic protection?

Perhaps not really a Discuss on this document, but what is the planned
disposition of the tsv-art reviewer's comments regarding
draft-ietf-lpwan-ipv6-static-context-hc and UDP Options?  I did not see
anything pertinent in the mailarchive.


----------------------------------------------------------------------
COMMENT:
----------------------------------------------------------------------

Please respond to the secdir review; I don't trust my own response to be
a comprehensive one that addresses all the raised potential issues.

This document is targeting Proposed Standard status, but in some sense
it's not clear that it is specifying a protocol per se, as opposed to
illustrating a set of choices that can be made for applying the SCHC
technique to CoAP messages.  These choices are expected to be generally
useful, but since the SCHC rules must be preagreed by all entities in
advance, there's not really anything to prevent a deployment from using
a modified version of these procedures, in terms of lost
interoperability.  In addition, the shepherd writeup mentions that there
may be some desire to do a refresh in the future, after more
implementation experience is gained.  So I don't have a great sense as
to which parts of this document are better as Proposed Standard vs.
Informational.

Abstract

   This draft defines the way SCHC (Static Context Header Compression)
   header compression can be applied to the CoAP protocol.  SCHC is a
   header compression mechanism adapted for constrained devices.  SCHC

Is it also in some sense a key requirement that these constrained
devices produce a fairly consistent or deterministic class of output?

Section 1

   SCHC compresses and decompresses headers based on shared contexts
   between devices.  Each context consists of multiple Rules.  Each rule
   can match header fields and specific values or ranges of values.  If
   a rule matches, the matched header fields are substituted by the rule
   ID and optionally some residual bits.  Thus, different Rules may

Do I remember corectly that an SCHC rule matching implies that the
entire header structure matches (i.e., there are no fields in the header
not listed in the rule)?  If so, perhaps a slight rephrasing to "If a
packet header fully matches a rule" would be helpful.

   Compression mainly results in one of 4 actions: * send the field
   value, * send nothing, * send some least significant bits of the
   field or * send an index.  After applying the compression there may
   be some bits to be sent, these values are called Compression
   Residues.

[It looks like this is generated from Markdown and needs additional
blank lines between bullet points]

   SCHC is a general concept mechanism that can be applied to different

nit: "concept" is a noun, not an adjective, so this doesn't parse
properly.

   protocols, the exact Rules to be used depend on the protocol and the
   application, and CoAP differs from UDP and IPv6, see Section 3.

nit: comma splice ("the exact rules [...]" is a complete sentence).

Section 2

   In the third example, OSCORE [rfc8613] is used.  In this case, two
   rulesets are used to compress the CoAP message.  A first ruleset
   focused on the inner header and is applied end to end by both ends.
   A second ruleset compresses the outer header and the layers below and
   is done between the Sender and the Receiver.

Is it worth having a parllel style and mentioning that the outer
compression can be modified hop by hop (in contrast to the inner
end-to-end compression)?

Section 3

   SCHC with CoAP will be used exactly the same way as it is applied in
   any protocol as IP or UDP with the difference that the fields
   description needs to be defined based on both headers and target
   values of the request and the responses.  SCHC Rules description use

If there's a difference, it's not "exactly the same".

Section 3.1

      return path (e.g. source and destination addresses fields).  The
      CoAP headers instead are asymmetric, the headers are different for
      a request or a response.  For example, the URI-path option is

nit: comma splice

   o  Even when a field is "symmetric" (i.e. found in both directions)
      the values carried in each direction are different.  To performs
      the compression a matching list in the TV might be use because

nit: "used".

      field two cases may be raised after applying the CDA: * The result
      of the compression is of fixed length and the compressed value is
      sent in the residue.  * Or the result of the compression is of
      variable-length and in this case, the size is sent with the
      compressed value in the residue.

[another presumed-markdown list, though this one might be easier to
reformat just as running text, since there are only two options]

   o  In CoAP headers, a field can appear several times.  This is
      typical for elements of a URI (path or queries).  The SCHC
      specification [I-D.ietf-lpwan-ipv6-static-context-hc] allows a
      Field ID to appears several times in the rule, and uses the Field
      Position (FP) to identify the correct instance, and thereby
      removing the ambiguity of the matching operation.

draft-ietf-lpwan-ipv6-static-context-hc notes that there can be issues
when using a FP of zero for "don't care"; perhaps it's worth noting that
these issues are pretty certain to occur for URI-path?

   o  Field sizes defined in the CoAP protocol can be too large
      regarding LPWAN traffic constraints.  This is particularly true
      for the Message ID field and the Token field.  SCHC uses different
      Matching operators (MO) to performs the compression, see section
      7.4 of [I-D.ietf-lpwan-ipv6-static-context-hc].  In this case the
      Most Significant Bits (MSB) MO can be applied to reduce the
      information carried on LP

This text was a bit hard for me to unwind, especially "field sizes [...]
too large regarding LPWAN traffic constraints".  At first I thought it
was saying that CoAP fields were problematic for SCHC (though I can no
longer see why I would think that), and then that the "length" of
various length+value encodings in CoAP allowed me to pick a length that
would be problematic for LPWAN, before arriving to my current conclusion
that it's just saying "some fields in CoAP are large and will only take
on a narrow range of values in a LPWAN context, providing a lot of
static bits that can be compressed using the MSB MO".  In essence, I
don't know that the "regarding LPWAN traffic constraints" is the most
effective language to use; emphasizing that the fields are large and
mostly unchanging, and that LPWAN needs to care about those wasted bits,
seems to be the important part.

Section 4.3

   If the device only implements a CoAP client, the request code can be
   reduced to the set of requests the client is able to process.

nit(?): "process" or "produce"?

   A mapping list can be used for known values, for other values the
   field cannot be compressed an the value needs to be sent in the
   residue.

nit: s/an/and/

Section 4.4

It seems like some guidance is in order about choosing how many bits to
compress, based on the frequency of traffic generated,
EXCHANGE_LIFETIME, and any other factors used to pick a message ID range
for a given device.

Section 4.5

   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.
   [...]
   used to define the size of the 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.

I'm not sure I understand how these two parts fit together.  I
understand that CoAP places a tight binding betwen the TKL value and the
length of the token field, and so if SCHC tried to treat them
differently we could break a CoAP invariant (this seems to be the
"ambiguity" that we seek to avoid, per the trimmed quote).  But the last
part seems to say that the TKL function to give the actual token length
is part of the Rule, and the former part says that if the CoAP Token
Length is variable, it will be sent in the compression residue -- if the
Token Length is a compression residue then that seems to imply that it
is not fixed by the Rule, and thus I'm not sure what the procedure is
supposed to be with this "TKL function".  Furthermore, I don't see
specification of the TKL function later in the document.  I guess it's
supposed to take as input information from the Rule's definition and the
token length residue in order to output the length of the transmitted
token residue, but that does not seem very clearly spelled out.  (Also,
I'm not sure whether the token residue would necessarily be the entire
token or the rule could allow some prefix to be compressed...)

Section 5

Would it be appropriate to give some guidance about who will have to do
what in order to cope with new CoAP Options defined in the future?

I'm also not sure that there's much rhetorical benefit in trying to
distinguish between Options defined in the core CoAP spec and subsequent
additions Section 5 vs. Section 6); they seem to be functionally the
same from an implementor's point of view.  (Well, maybe not OSCORE.)

There are also a few of Options in the current registry that are not
given any treatment here (whether in Section 5 or Section 6); should we
mention that?  (Hop-Limit, OCF-*, ...)

Section 5.1

I see only "Content-Format" and "Accept" Options defined in RFC 7252, but
no "Content" option.

   used to limit the size of the residue.  Otherwise, the value has to
   be sent as a residue (fixed or variable length).

The content format is an integer in the range 0-65535, and if we don't
know enough about what can be used to have a match-list, how can we make
assumptions about a variable-length residue being better than a
fixed-length one?

Section 5.3

[Perhaps the interaction between FP and Uri-Path that I mentioned above
could be discussed here instead.]

This specification of the regrouping operation and the table in the
figure seem a bit in need of further clarification.  Perhaps "Even
though there are two distinct URI-Path fields to match, the target
values for all regrouped path components are consolidated into a single
logical "target value" (with the appropriate number of path components)
to be matched.  The components of the target value must individually
match with the URI-Path field values in the indicated field positions.
Note specifically that the FP values, as indicated in the example, are
not required to be consecutive values; in this case the path components
in the target value are a matter of convenience and would have
additional components inserted in order to match the actual resource
path in question.  For the subsequent Uri-Path fields in the rule, no
target value is given and the match operation is listed as "ignore" for
convenience; the actual matching has occured on the grouped value listed
in the first field's entry."  (I'm not sure why the CDA is listed as
"value-sent" for FP 3 in the example, though.)

Section 5.3.2

   be created to cover all the possibilities.  Another possibility is to
   define the length of Uri-Path to variable and send a compression
   residue with a length of 0 to indicate that this Uri-Path is empty.

I'm not sure I understand this proposal.  Is it to say that you could
have a single rule that lists the maximum expected number of path
components, and then use "empty component"s to represent the compressed
form of shorter paths?  It seems like this still has a hard cap on the
number of path components that could be represented by a given Rule,
which would be a significant limitation and needs to be called out.

Section 5.4

   [I-D.ietf-lpwan-ipv6-static-context-hc].  They are used only by the
   client to access a specific resource and are never found in server
   response.

nit: singular/plural mismatch "they are"/"server response"

   If the field value has to be sent, TV is not set, MO is set to
   "ignore" and CDA is set to "value-sent".  A mapping MAY also be used.

   Otherwise, the TV is set to the value, MO is set to "equal" and CDA
   is set to "not-sent".

Please reword/reformat to give equal treatment to the three options
(send full residue, mapping list, target value) in terms of the
formatting and the use of normative keywords.

Section  5.5

   These fields are unidirectional.

In which directions?

Section 6.1

I suggest using rhetoric that is consistent with the two different block
options, even though they conceptually fit together as a functional
unit.

   includes a fragmentation protocol.  They are compatible.  If a block
   option is used, its content MUST be sent as a compression residue.

Anything to say about fixed vs. variable length encoding?

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 it worth assembling a consolidated table of specific rules or rule
functionality that must be present to have a functional CoAP SCHC setup
(incorporating this and the base SCHC requirements for, e.g., a rule to
capture otherwise non-matching traffic that is sent without
compression)?

Section 6.3

   Otherwise, if the value is changing over time, TV is not set, MO is
   set to "ignore" and CDA to "value-sent".  A matching list can also be
   used to reduce the size.

Similarly to my comment above, it might be nice to give parallel
rhetorical treatment to the three options.

Section 6.4

This section feels more like a sketch of how someone could implement
SCHC with OSCORE, as compared to previous Options' handling that has a
pretty well-defined procedure.

Would it be desirable, for example, to have a separate Rule for each
value of the OSCORE flags that was expected?

Section 7.2

   The Plaintext is now encrypted by an AEAD algorithm which integrity
   protects Security Context parameters and eventually any class I
   options from the Outer Header.  Currently no CoAP options are marked
   class I.  The resulting Ciphertext becomes the new Payload of the

I suggest dropping "eventually", as it will no longer make sense if/when
class-I options are defined.

   Note that since the Inner part of the message can only be decrypted
   by the corresponding end-point, this end-point will also have to
   implement Inner SCHC Compression/Decompression.

It might be worth being even more explicit that the SCHC context for the
inner and outer parts may differ as well, since they may be processed by
different entities.

Section 7.3

   The piv field lends itself to having a number of bits masked off with
   MO MSB and CDA LSB.  This could be useful in applications where the
   message frequency is low such as that found in LPWAN technologies.
   Note that compressing the sequence numbers effectively reduces the
   maximum amount of sequence numbers that can be used in an exchange.
   Once this amount is exceeded, the OSCORE keys need to be re-
   established.

Just to check: one could also allocate additional Rules to match a
different prefix, and get additional sequence number space?

   Compression residue:
   0b0001 010 (7 bits -> 1 byte with padding)
     mid  tkn

We had a space after "0b" in the request portion, which seems to aid
readibility.

   As can be seen, the difference between applying SCHC + OSCORE as
   compared to regular SCHC + COAP is about 10 bytes of cost.

I'd suggest noting that this is about what one would expect, given the
fixed and uncompressible overhead of the 8-byte tag, plus the need for
the dual compression with inner and outer contexts (each of which have
their own octet for rule ID).


IIUC additional Rule information would be needed to handle Observer
responses/updates, but it's not really clear that we need to mention
that fact in the context of this specific example.

Section 9

   This document does not have any more Security consideration than the
   ones already raised on [I-D.ietf-lpwan-ipv6-static-context-hc].

Given that we then go on to talk about more stuff, am I to conclude that
the additional discussion is merely exposition on topics already covered
in the reference (vs. new content that would make this quoted statement
invalid)?

In particular, I think there is another new security consideration worth
discussion here, relating to the interaction of compression and OSCORE.
To illustrate how this might come intoi play, consider the example in
Section 7.3, where the response can be compressed to a single byte,
since there is only one request message defined/expected by the Rules.
In such a scenario where the number of potential plantexts is extremely
small, an attacker with knowledge that SCHC is in use (and, perhaps, the
Rules in question) will have a very easy time of traffic analysis, which
to some extent will defeat the message protection that OSCORE is
intended to provide.

   Variable length residues may be used to compress URI elements.  They
   cannot produce a packet expansion either on the LPWAN network or in
   the Internet network after decompression.  The length send is not

We should probably say why ("because the static context embedded in the
Rule used for compression can only remove/replace a static, fixed-length
prefix of the URI component")

nit: s/send/sent/

   used to indicate the information that should be reconstructed at the
   other end, but on the contrary the information sent as a Residue.

nit: "on the contrary the length of the information sent as a Residue",
I think.

   OSCORE compression is also based on the same compression method
   described in [I-D.ietf-lpwan-ipv6-static-context-hc].  The size of
   the Initialisation Vector residue size must be considered carefully.

I suggest adding a note that there is a tradeoff between the efficiency
of compression and the number of protected messages that can be sent
using a given key/SCHC context; the following two sentences don't seem
as clear as they could be.  So ...

   A too large value has a impact on the compression efficiency and a
   too small value will force the device to renew its key more often.
   This operation may be long and energy consuming.

Perhaps,

% The OSCORE initialization vector holds a message sequence number, and
% a unique such number is needed for each distinct message.  The SCHC
% procedure gives compression efficiency by assuming that a fixed prefix
% of the IV remains static and eliding that fixed prefix from the
% transmitted message.  However, such compression has the corresponding
% effect of reducing the number of distinct sequence numbers available
% to the sender.  When the usable sequence number space is exhausted,
% the OSCORE security context must be rekeyed; since this rekeying can
% be an expensive operation in terms of time and energy consumption, the
% creation of SCHC Rules for OSCORE compression should take into
% consideration the tradeoff between (amortized )rekeying cost and the
% recurring transmission overhead for the uncompressed portion of the
% initialization vector.