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

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

Benjamin Kaduk has entered the following ballot position for
draft-ietf-lpwan-ipv6-static-context-hc-21: 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-ipv6-static-context-hc/



----------------------------------------------------------------------
DISCUSS:
----------------------------------------------------------------------

I wavered a lot about whether to ballot Discuss or No Objection; there
are a lot of important technical and clarity-of-writing points that
remain in the Comment section, but only a few points seemed to merit
elevating to the Discuss level.  That said, this remains a generally
clear and useful document, so I'm looking forward to seeing it further
improved.

(1) I'm concerned about Section 8.2.4's recommendation for the use of a
sequential counter:

      A sequence counter that is incremented for each new fragmented
      SCHC Packet, counting from 0 to up to (2^T)-1 and wrapping back to
      0 is RECOMMENDED for maximum traceability and avoidance of
      ambiguity.

It seems like there may be substantial privacy and security
considerations, here -- draft-gont-numeric-ids-history has some
background about similar cases in the past and links to other documents
with analysis and guidance for future protocols.  Shall we discuss to
what extent those concerns apply here?

(2) In Section 8.3.1.2, does the use of the All-1 fragment to signify
the end of the packet, combined with the lack of an explicit "number of
fragments" field, imply that the RCS value is the only thing (at this
protocol level) preventing an attacker from inserting, from off-path,
additional fragments between the penultimate "legitimate" fragment and
the final fragment?  (I understand that the LPWAN radio technologies
generally do have some physical-layer cryptographic mechanisms, though
they sometimes involve shared symmetric keys.)  If the RCS is to play
this pivotal a role, we need to at least document that, and arguably
give stronger guidance about how it should be computed.

(3) There are several places (noted, for the most part, in the Comment
section) where we say that some field is optional.  I think this means
"optional at the profile level" as opposed to "optional at runtime", but
we should be clear in the document about that.

(4) There's an internal inconsistency in Section 8.4.3:

   In ACK-on-Error mode, windows are used.  All tiles MUST be of equal
   size, except for the last one, which MUST be of the same size or
   smaller than the regular ones.  If allowed in a Profile, the
   penultimate tile MAY be exactly one L2 Word smaller than the regular
   tile size.

We need to reword this, as the subsequent text contradicts the initial
"MUST".


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

It's perhaps a little interesting/surprising to see this document
describe itself as just "header compression [with some fragmentation
support]".  Is this intended (after profiling) to be the entire IPv6
adaptation layer for the LPWAN technologies in question, or would there
need to be an additional adaptation layer?  If yes, would the
fragmentation be a better fit there?  If no, perhaps the document should
reframe itself as such?

Some discussion in the security considerations about detecting malformed
packets by unknown Rule ID prompted me to wonder about whether there is
any possibility of SCHC (i.e., IPv6) traffic coexisting with non-IP
LPWAN traffic on the same (device) interface.  My naive expectation is
that a device would need separate interfaces for IP and non-IP traffic,
but I'm not sure.  Is there any benefit from mentioning such scenarios
in this document?

Section 1

   Header compression is needed for efficient Internet connectivity to
   the node within an LPWAN network.  The following properties of LPWAN

nit: s/the node/a node/ or s/the node/nodes/ -- there's more than one
node within a given LPWAN network, in the general case.

   This document defines generic functionality and offers flexibility
   with regard to parameters settings and mechanism choices.
   Technology-specific settings and product-specific choices are
   expected to be grouped into Profiles specified in other documents.

Having looked briefly at RFC 8376 and the rest of this document, I worry
a little bit about enabling vendor-locked "walled gardens" there a
specific product defines a custom protcol and does not provide
sufficient information for others to interoperate with networks of the
corresponding devices.  Can we do more to ensure that the resulting
profiles/protocols will be interoperable with independent
implementations?

Section 4

   o  Padding (P).  Extra bits that may be appended by SCHC to a data
      unit that it passes to the underlying Layer 2 for transmission.
      SCHC itself operates on bits, not bytes, and does not have any
      alignment prerequisite.  See Section 9.

Do we mandate the value of the padding bits?  A forward-reference to
Section 9 might be helpful.

Section 5

Should there be an indication in Figure 3 that the SCHC ACK is optional
(as may be made necessary by the radio technology)?

Section 5.2

   The operation in the Downlink direction is similar to that in the
   Uplink direction, only reverting the order in which the architecture
   elements are traversed.

nit: s/reverting/reversing/

Section 6

   Rule IDs identify the Rules used for Compression/Decompression or for
   Fragmentation/Reassembly.

Is the Rule ID name(number)space shared between C/D and F/R, or do they
have distinct Rule ID tables?

   The scope of a Rule ID is the link between the SCHC Compressor and
   the SCHC Decompressor, or between the SCHC Fragmenter and the SCHC
   Reassembler.

It seems that Section 7.2 clarifies that this scope is available
per-device, and the rule IDs are not shared across all devices in the
LPWAN application.  Would it be worth putting "per-device" in here as
well?

   o  In SCHC F/R, to identify the specific mode and settings of F/R for
      one direction of traffic (Up or Dw).

      *  When F/R is used for both communication directions, at least
         two Rule ID values are needed for F/R, one per direction of
         traffic.

It might be worth a forward reference here, or a note that this is so we
can tell what header format to use for parsing (e.g., fragment vs. ack).

Section 7.2

   [...]
   On the network side, in order to identify the correct Rule to be
   applied, the SCHC Decompressor needs to associate the Rule ID with
   the Dev identifier.  Similarly, the SCHC Compressor on the network
   side first identifies the destination Dev before looking for the
   appropriate compression Rule (and associated Rule ID) in the Context
   of that Dev.

Does this imply that the set of Devices is known in advance at
provisioning time, or will part of device onboarding be to synchronize
these Rule IDs+device ID state (or are they expected to be determinable
algorithmically)?

Section 7.3

      *  The first step is to check the Field Identifiers (FID).  If any
         header field of the packet being examined cannot be matched
         with a Field Description with the correct FID, the Rule MUST be
         disregarded.  If any Field Description in the Rule has a FID
         that cannot be matched to one of the header fields of the
         packet being examined, the Rule MUST be disregarded.

This seems to imply that a given Rule must encompass the entire header
structure considered as input to compression, since any field in the
packet not having a corresponding FID in the Rule means that the Rule is
disregarded.  It would be good to state this requiremnet more plainly.

         example could be uri-queries in CoAP.  Care needs to be
         exercised when writing Rules containing FP=0 values.  Inded, it
         may result in decompressed packets having fields ordered
         differently compared to the original packet.

There may be security consequences of this if there is a checksum or
other integrity protection on the original packet!

      *  If no eligible compression Rule is found, then the header MUST
         be sent in its entirety using the Rule ID of the "default" Rule
         dedicated to this purpose.  Sending an uncompressed header may
         require SCHC F/R.

It feels like s/may require/will likely require/ might be justified,
given the description of LPWAN technologies here and in RFC 8376.

   o  Compression: each field of the header is compressed according to
      the Compression/Decompression Actions (CDAs).  The fields are
      compressed in the order that the Field Descriptions appear in the
      Rule.  [...]

Compressed in the order of Field Descriptions in the rule, not the order
the fields appear in in the packet, interesting.  This means that the
ordering of fields in the Rule is semantically important (and we should
say so explicitly) but perhaps also provides a bit more flexibility of
compression in the cases where the protocol header being compressed
allows flexibility of representation/field ordering.

   o  Decompression: when decompressing, on the network side the SCHC C/
      D needs to find the correct Rule based on the L2 address; in this

nit: the L2 address of the Dev.

      The receiver identifies the sender through its device-id or source
      identifier (e.g.  MAC address, if it exists) and selects the Rule
      using the Rule ID.  This Rule describes the compressed header
      format and associates the received residues to each of the header
      fields.  For each field in the header, the receiver applies the

We could perhaps stand to say a bit more about "associates the received
residues to each of the header fields", since even the boundaries
between received residues need to be determined based on the Rule ID and
any variable field lengths.

Section 7.5.3

   The not-sent action can be used when the field value is specified in
   a Rule and therefore known by both the Compressor and the
   Decompressor.  This action SHOULD be used with the "equal" MO.  If MO
   is "ignore", there is a risk to have a decompressed field value
   different from the original field that was compressed.

The security considerations should talk about the consequences of that
risk.

Section 7.5.5

   The mapping-sent action is used to send an index (the index into the
   Target Value list of values) instead of the original value.  This

Do we need to say this is zero-indexed?

Section  8.1

   The L2 Word size (see Section 4) determines the encoding of some
   messages.  SCHC F/R usually generates SCHC Fragments and SCHC ACKs
   that are multiples of L2 Words.

Do we want to say anything about the unusual cases where it does not?

Section 8.2.2.1

The figure implies that the tiles need not all be the same length; is
that worth stating explicitly (in contrast to Windows, which do need to
have a consistent cardinality)?

Section 8.2.3

   The CRC32 polynomial 0xEDB88320 (i.e. the reverse representation of
   the polynomial used e.g. in the Ethernet standard [RFC3385]) is

I don't think that RFC 3385 is a good reference for how to interpret the
hex constant as a CRC polynomial.  Given the parenthetical, perhaps it's
not trying to be, but I'd suggest having a CRC32 reference.

   Note that the concatenation of the complete SCHC Packet and the
   potential padding bits of the last SCHC Fragment does not generally

nit(?): I keep trying to read "potential padding bits" as "these bits
exist but are potentially padding bits", as opposed to the intended "any
padding bits [that may potentially be present]".  (Also in the rest of
this paragraph.)

Section 8.2.4

      The Rule ID allows SCHC F/R interleaving non-fragmented SCHC
      Packets and SCHC Fragments that carry other SCHC Packets, or
      interleaving SCHC Fragments that use different SCHC F/R modes or

nit(?): I don't see how just the Rule ID allows identifying Fragments
that carry other Packets, in the general case (i.e., including when the
same F/R mode+parameters are used for both packets).  The DTag seems
necessary in this case.

      A flow of SCHC F/R messages with a given Rule ID and DTag value
      pair MUST NOT interfere with the operation of a SCHC F/R instance
      that uses another Rule ID and DTag value pair.

What does "interfere with the operation of" mean?  Is this supposed to
be at a spectrum level or in the reassembly process?

   o  C (integrity Check): C is a 1-bit field.  This field is used in
      the SCHC ACK message to report on the reassembled SCHC Packet
      integrity check (see Section 8.2.3).

      A value of 1 tells that the integrity check was performed and is
      successful.  A value of 0 tells that the integrity check was not
      performed, or that is was a failure.

What is the recipient of this field expected to do in response to a 1 or
0 value?  (E.g., some forward references might help.)
A perhaps-related question is whether "not performed" is always due to
"not all fragments were present" or could be "my software is configured
to not check the RCS".  Figure 39 suggests that it's the former, but if
so that's probably worth saying explicitly.

Section 8.3.1.1

   The Regular SCHC Fragment format is shown in Figure 13.  Regular SCHC
   Fragments are generally used to carry tiles that are not the last one
   of a SCHC Packet.  The DTag field and the W field are optional.

Optional at a Profile level, or at runtime?

   The Fragment Payload of a SCHC Fragment with FCN equal to 0 (called
   an All-0 SCHC Fragment) MUST be distinguishable by size from a SCHC
   ACK REQ message (see Section 8.3.3) that has the same T, M and N
   values, even in the presence of padding.  This condition is met if
   the Payload is at least the size of an L2 Word.  This condition is
   also met if the SCHC Fragment Header is a multiple of L2 Words.

(I think there's an implicit "and the payload is at least one bit long"
in here, which may actually go without saying, but I had to think about
it while verifying the last sentence.)

Section 8.3.1.2

   The All-1 SCHC Fragment format is shown in Figure 14.  The sender
   generally uses the All-1 SCHC Fragment format for the message that
   completes the emission of a fragmented SCHC Packet.  The DTag field,
   the W field, the RCS field and the Payload are optional.  At least

What does "generally" mean?  When would it be used for other things?

As above, are W/RCS/Payload optional at the Profile level or at runtime?

Section 8.3.2

   The SCHC ACK message is shown in Figure 15.  The DTag field, the W
   field and the Compressed Bitmap field are optional.  The Compressed

As above, optional at the Profile level or runtime?

Section 8.3.4

   The SCHC Sender-Abort format is shown in Figure 21.  The DTag field
   and the W field are optional.  The FCN field is all ones.

[same comment]

   If the W field is present,

   o  the fragment sender MUST set it to all ones.  Other values are
      RESERVED.

   o  the fragment receiver MUST check its value.  If the value is
      different from all ones, the message MUST be ignored.

I'm pretty sure there are some other preconditions here, maybe including
"the SCHC Fragment has no payload", as ignoring all fragments that are
not All-1s is unlikely to work very well.

Section 8.3.5

   The SCHC Receiver-Abort format is shown in Figure 22.  The DTag field
   and the W field are optional.

As above, optional at the Profile level or runtime?

   o  if the value is different from all ones, the fragment sender MUST
      ignore the message.

As above, are there other preconditions here?  I guess the SCHC Receiver
does not send many types of fragment, so the requirements here may
actually be fairly weak.  (Perhaps this requirement goes better
rhetorically after the final paragraph of this section?)

That does raise another question, of whether (when bidirectional traffic
is used) it is needed or recommended to have the traffic direction be
implicit in Rule ID.

Section 8.4.1

   For each active pair of Rule ID and DTag values, the receiver MUST
   maintain an Inactivity Timer.

What happens if the receiver is under-resourced to do this?

Section 8.4.1.1

   Each SCHC Fragment MUST contain exactly one tile in its Payload.  The
   tile MUST be at least the size of an L2 Word.  The sender MUST

Including the last tile?

Section 8.4.2

   o  Data unit out-of-sequence delivery does not occur between the
      entity performing fragmentation and the entity performing
      reassembly

Is there an implicit "but data units may be lost or otherwise not
delivered" here?

Section 8.4.2.1

   o  upon receiving a SCHC ACK,

      *  if the SCHC ACK indicates that some tiles are missing at the
         receiver, then the sender MUST transmit all the tiles that have
         been reported missing, it MUST increment Attempts, it MUST
         reset the Retransmission Timer and MUST await the next SCHC
         ACK.

Are there any ACK REQs involved here?  How will the receiver know to
send a second SCHC ACK if only some tiles (potentially not including the
last tile of the window) are being retransmitted?

   o  on Retransmission Timer expiration,

      *  if Attempts is strictly less that MAX_ACK_REQUESTS, the
         fragment sender MUST send a SCHC ACK REQ and MUST increment the
         Attempts counter.

E.g., this text would suggest that after sending the last tile of a
window, we wait for the retransmission timer's delay before sending an
ACK REQ and thus inherently stall the transaction for that long.
(Later on we see that the All-0 Fragment has an implicit ACK REQ
semantics, but it's unclear that this works for the last tile of a
retransmitted window when the bitmap remains incomplete at the receiver.)

Section 8.4.2.2

   On receiving a SCHC Fragment with a Rule ID and DTag pair not being
   processed at that time
[...]
   On reception of any SCHC F/R message, the receiver MUST reset the
   Inactivity Timer.

I think these statements are inconsistent about the scope of the
Inactivity Timer.  The latter implies that the timer is global to the
recipient, but the former implies it is specific to a Rule ID/DTag pair.
(Section 8.4.2, of course, is clear that it is per-Rule ID/DTag pair.)

         +  If the Bitmap indicates that all the tiles of the current
            window have been correctly received, the receiver MUST
            increment its window counter and it enters the "acceptance
            phase" for that new window.

Is this going to leave us in a bad state if our ACK gets dropped?

      *  on the Bitmap becoming fully populated with 1's, the receiver
         MUST send a SCHC ACK for this window, it MUST increment its
         window counter and it enters the "acceptance phase" for the new
         window.

[same comment]

   o  if the window is the last window
   [...]
      *  on receiving a SCHC Fragment with a W bit equal to the local W
         bit,
         [...]
         +  otherwise, the receiver MUST update the Bitmap and it MUST
            assemble the tile received.  If the SCHC Fragment received
            is an All-1 SCHC Fragment, the receiver MUST assemble the
            padding bits of the All-1 SCHC Fragment after the received
            tile.  It MUST perform the integrity check.  Then

            -  if the integrity check indicates that the full SCHC
               Packet has been correctly reassembled, the receiver MUST
               send a SCHC ACK and it enters the "clean-up phase".

            -  if the integrity check indicates that the full SCHC
               Packet has not been correctly reassembled,

It seems that there will be some cases where we know that there remain
missing tiles; do we want to say anything about that (and skipping the
integrity check validation) here?

Section 8.4.3.1

   On Retransmission Timer expiration

   o  if Attempts is strictly less than MAX_ACK_REQUESTS, the fragment
      sender MUST send either the All-1 SCHC Fragment or a SCHC ACK REQ
      with the W field corresponding to the last window,

   o  otherwise the fragment sender MUST send a SCHC Sender-Abort and it
      MAY exit with an error condition.

Having a heads-up here that there's special behavior for the receiver
where the window that gets ACK'd in response to an ACK REQ may be a
different window than the one indicated in the ACK REQ would help me
out, as there's a few places in this section where that behavior is
implicitly relied upon but it's not otherwise stated until we get o the
following subsection.

In a few places in this section we talk about "the All-1 SCHC Fragment",
but I'm not entirely clear on whether this will always include the last
tile or, in the case where the profile directs that the last tile be
included in a regular fragment, there is some special format for the
All-1 fragment that does not include (much) payload.

Section 8.4.3.2

   On receiving any SCHC F/R message, the receiver MUST reset the
   Inactivity Timer.

As mentioned above, this statement is overly broad (and should be scoped
to Rule ID/DTag matching).

   After receiving an All-1 SCHC Fragment, a receiver MUST check the
   integrity of the reassembled SCHC Packet at least every time it
   prepares for sending a SCHC ACK for the last window.

As mentioned previously, the receiver may already know it lacks some
tiles, which makes checking the integrity kind of pointless.

Section 10.7.2

   As described in [RFC8065], it may be undesirable to build the Dev
   IPv6 IID out of the Dev address.  Another static value is used
   instead.  In that case, the TV contains the static value, the MO

What's the scope/duration of this other static value's usage?

Section 12

Do we want/expect the network gateway to be running a firewall that only
allows traffic from the Application to be relayed down to the radio
network?  If so, what kind of authentication mechanism could it use?
In a similar vein, I note that some of the examples show the use of
link-local IPv6 addressing; if the device is one end of that "link",
what node is the other end, and to what extent does the link-local
nature of the addressing prevent off-path traffic injection?

   Wireless networks are subjects to various sorts of attacks, which are
   not specific to SCHC.  In this section, we'll assume that an attacker
   was able to break into the network despite the latter's security
   measures and that it can now send packets to a target node.  What is

Since this is radio, is it implicit that the send-packets ability is
"from off-path"?

Section 12.1

It feels like we should say something about what the endpoint will do
with the bogus packet after SCHC Decompression -- does it just get
passed to the application with the application left to do any
sanity/authenticity checking?

I sympathize with the secdir reviewer's point about mixing secret
information with attacker-controlled information as compression input.
That said, my sense from reading the document is that compression is
applied on a per-protocol-header-field basis, which makes it unlikely
that there will be secret data combined with attacker-controlled data,
but I would appreciate a confirmation of that.

Section 12.2

This is a really great discussion of the risks affecting the
fragmentation/reassembly mechanism; thank you!
I suppose we could also mention the possibility of a spoofed ACK that
claims all data is received when it was not successfully received,
though in practice it does not seem like that would be particularly
valuable to the attacker (not least since they would probably also need
to suppress the legitimate ACK that indicates some fragment loss).

I also note the secdir reviewer's remark about fragmentation and packet
inspection devices.  I mostly expect any such devices to not be at the
radio layer for these application traffic flows, but please confirm.

Appendix A

What is the Rule ID for "no compression applied"?

Appendix C

Some of these are so hard to follow that I couldn't really verify them
completely.  I don't really have suggestions for improving them that
don't involve using substantially more vertical space, though.

Appendix D

What about MAX_ACK_RETRIES?

Appendix E

   tiles.  If multiple window sizes are supported, the Rule ID may
   signal the window size in use for a specific packet transmission.

Is this really a "may" or a "must"?  I don't see what else would be used
to determine what width to use when parsing the fragment.

Appendix F

   When the SCHC Fragment sender transmits the All-1 SCHC Fragment, it
   starts its Retransmission Timer with a large timeout value (e.g.
   several times that of the initial Inactivity Timer).  If a SCHC ACK
   is received before expiration of this timer, the SCHC Fragment sender
   retransmits any lost SCHC Fragments reported by the SCHC ACK, or if
   the SCHC ACK confirms successful reception of all SCHC Fragments of
   the last window, the transmission of the fragmented SCHC Packet is
   considered complete.  If the timer expires, and no SCHC ACK has been
   received since the start of the timer, the SCHC Fragment sender
   assumes that the All-1 SCHC Fragment has been successfully received
   (and possibly, the last SCHC ACK has been lost: this mechanism
   [...]

This seems like it's no longer a *retransmission* timer for the All-1
fragment, since we don't retransmit when it expires; we just assume
success and stop.