Static Context Header Compression and Fragmentation (SCHC) over LoRaWAN
draft-ietf-lpwan-schc-over-lorawan-14

[[ questions ]]

[ section 5.3 ]

* Is this MUST really necessary?  If an implementation wanted to, say, read
  8 bytes from a good /dev/urandom source wouldn't that also be okay?  Seems
  like SHOULD would suffice (with a MUST NOT comment about not just using
  DevEUI etc).

** Section 3.  Per “… sending application flows using IPv6 or IPv6/UDP protocols”?  It isn’t clear to me what nuance is being conveyed by saying IPv6 with and without UDP.

** Section 5.3  
-- it would be useful to explicitly state that AppSKey is a session key and what it is used for (encryption and decryption of the payload)

-- s/As AppSKey is renewed each time/As AppSKey is regenerated each time/ -- isn’t it derived per each join from a the AppKey+nonce+?

-- s/appSKey:/AppSKey/

-- RFC4493 should be normative because it is needed to compute the IID

** Section 6.
Moreover, SCHC data (LoRaWAN payload) are protected at
   the LoRaWAN level by an AES-128 encryption with a session key shared
   by the device and the SCHC gateway.  These session keys are renewed
   at each LoRaWAN session (ie: each join or rejoin to the LoRaWAN
   network)

Appreciating that this document is not redefining LoRaWAN security, it might nevertheless be helpful to more clearly state (or provide a reference to) the security properties of the link between the device and the application service (SCHC gateway).  Since the text explicitly noted that confidentiality via the session key, it would also be helpful to note the other properties such as integrity provided by the MIC, partial replay protection via the DevNonce, etc.

The title, Abstract, and Introduction all use “LoRaWAN” without expansion or explanation.  I suggest expanding it as “Long Range WAN” in all three places, and citing [lora-alliance-spec] at that expansion in the Introduction (you dont cite it until Section 4).

Please expand LPWAN on first use in the Introduction.

And a comment about Martin’s comment: “I found this document to be very tough going without reading through RFC8724.” ... Well, to be fair, 8724 is a normative reference, so isn’t that sort of expected?

I am not sure that I understand the expected behavior for class A
devices when the SCHC gateway is retransmitting SCHC ACK and also has
other, higher-priority, downlink traffic to send.  As I note inline in
the Section 5.6.3.5.1 comments, it seems like we might have internally
inconsistent guidance about whether a non-SCHC-ACK message indicates
receipt of the ACK (and thus that the device can discard the saved SCHC
ACK message).

It is interesting that we give (e.g., in §5.6.2.4, 5.6.3.4) the
Receiver-Abort format but not the Sender-Abort format.

It seems like we are perhaps playing a little fast and loose with the
requirements imposed by RFC 8742, in that it attempts to require various
aspects to be specified for each ruleID for each profile, but we do not
specify the full set of Rule IDs.  Perhaps it would be worth a blanket
statement that the procedures we specify apply to all rule IDs using
this profile (unless otherwise specified by the configuration that
establishes the static context on both parties to the communication).

Section 2

Please expand EUI on first use, as it's not marked as "well-known" at
https://www.rfc-editor.org/materials/abbrev.expansion.txt .

Section 3

It seems like it might be useful to indicate in the figure where the
LoRaWAN network boundary is.

Section 4.2

   LoRaWAN end-devices use a 32-bit network address (devAddr) to
   communicate with the Network Gateway over-the-air, this address might
   not be unique in a LoRaWAN network; devices using the same devAddr
   are distinguished by the Network Gateway based on the cryptographic
   signature appended to every LoRaWAN frame.

nit: the first comma is a comma splice, but the sentence already has a
semicolon.  I think this paragraph should become at least two sentences.

   To communicate with the SCHC gateway, the Network Gateway MUST
   identify the devices by a unique 64-bit device identifier called the
   DevEUI.

Baking in a persistent identifier like this has privacy considerations.
Is DevEUI randomization going to be possible?

Section 4.3

   As SCHC defines its own acknowledgment mechanisms, SCHC does not
   require to use LoRaWAN Confirmed frames.

nit: s/require to use/require use of/

Section 4.4

   o  Data: MAC and application data.  Application data are protected
      with AES-128 encryption, MAC related data are AES-128 encrypted
      with another key.

nit: comma splice.

Section 5.1

   Note: SCHC Message is any datagram sent by SCHC C/D or F/R layers.

How would such a message be identified by the recipient?  Is the FPort
contents enough, or would there be some other data needed as well?

Section 5.3

Thank you for condsidering the RFC 8064/8065 risks and using ephemeral
IIDs tied to the application session!

Using the AppSKey for a purpose other than protecting LoRaWAN
application traffic is not great cryptographic hygiene.  That said, I
recognize that it's chosen because we don't expect all LoRaWAN devices
to have any kind of cryptographic hash available and that limits the
options for key derivation.  I would need to think a bit harder to tell
whether even something as simple as prepending a fixed constant block
before the DevEUI as CMAC input would provide any additional benefit.

[I did not attempt to verify the IID-generation example.]

Section 5.6.2

It might be nice to list the F/R parameters in the same order that RFC
8742 (Section 8.2.4 or 8.4.3) does.

Also, a forward reference to the subsections that provide the layout of
the various fields would be appreciated.

   o  DTag: Size is 0 bit, not used.

We should probably say specifically that T is 0 bits.

   o  Window index: encoded on W = 2 bits.  So 4 windows are available.

Likewise, M is 2 bits.

   o  RCS: Use recommended calculation algorithm in [RFC8724].

It might be helpful to give a section reference into 8724 (and likewise
in §5.6.3).

   o  Retransmission timer: Set by the implementation depending on the
      application requirements.

Can we give a default value that would be usable in many situations?

   o  Last tile: it can be carried in a Regular SCHC Fragment, alone in
      an All-1 SCHC Fragment or with any of these two methods.

So receivers have to be able to cope with receiving either version, too?

   For battery powered devices, it is RECOMMENDED to use the ACK
   mechanism at the end of each window instead of waiting until the end
   of all windows:

This is the Uplink section; won't whether/when to ACK be under the
control of the SCHC gateway, that may or may not know if the device is
battery-powered or not?

   o  the SCHC sender SHOULD wait for the SCHC ACK from the SCHC
      receiver before sending tiles from the next window.  If the SCHC
      ACK is not received, it SHOULD send a SCHC ACK REQ up to
      MAX_ACK_REQUESTS times, as described previously.

If no ACK is elicited, does it continue on to the next window or fail
the transmission?

   SCHC implementations MUST be compatible with both behaviors, and this
   selection is part of the rule context.

This is attaching a new property to each rule at the very end of the
section, which is easily ignored; I strongly recommend adding a
prominent note at the top of the section that "in addition to the
per-rule context parameters specified in [RFC8724], for uplink rules an
additional context parameter is added: whether or not to ack after each
window".

Section 5.6.3

   o  SCHC fragmentation reliability mode:

      *  Unicast downlinks: ACK-Always.

      *  Multicast downlinks: No-ACK, reliability has to be ensured by
         the upper layer.  This feature is OPTIONAL and may not be
         implemented by SCHC gateway.

I think you should say that the subsequent parameters only apply to the
ACK-Always case, since the No-ACK case does not need (I think?) any of
them except the rule ID.

   o  DTag: Size is 0 bit, not used.

Should probably mention T, again.

   Class A devices can only receive during an RX slot, following the
   transmission of an uplink.  Therefore the SCHC gateway cannot
   initiate communication (e.g., start a new SCHC session).  In order to
   create a downlink opportunity it is RECOMMENDED for Class A devices
   to send an uplink every 24 hours when no SCHC session is started,
   this is application specific and can be disabled.  [...]

Just to walk through this, if the SCHC gateway has more than 2 frames to
send to the device, after the device-initiated (every 24 hour)
transmission, the SCHC gateway will send the first two frames, and then
... each ACK from the device will also open up two receive slots, so the
exchange continues fairly synchronously until the SCHC gateway does not
have more data to transmit?  Are there any cases (multiple losses) where
we might be reduced to a trickle of 20 bytes every 24 hours?

Section 5.6.3.5.1

   _Note_: The device MUST keep this SCHC ACK message in memory until it
   receives a downlink SCHC Fragmentation Message (with FPort ==
   FPortDown) that is not a SCHC ACK REQ: it indicates that the SCHC
   gateway has received the SCHC ACK message.

I'm not sure that I understand how this works -- the previous paragraph
seemed to indicate that we had SCHC_ACK_REQ_DN_OPPORTUNITY greater than
one to allow for non-ACK-REQ (i.e., potentially higher priority) traffic
to get sent, which I assumed meant intermingled with the ACK REQs.  But
the paragraph I quote here implies that any such intermingling would be
misinterpreted as receipt of the ACK.  So, what is the expected behavior
when the SCHC gateway is retransmitting ACK REQ and also has other
downlink traffic to send?

Section 5.7

This seems to just be reiterating behaviors stated in RFC 8742, with
specific numbers corrsponding to this profile.  If so, it's not entirely
clear how much value there is in keeping the calculationsin the final
archival RFC.

Section 6

It's a little unfortunate that [lora-alliance-spec] doesn't have much in
the way of a security considerations section, which would cover that the
quality of RNG on device and join server is quite relevant for the
strength of the session keys.  (Also, what Roman said.)

Please also add a mention of the privacy considerations for using the
persistent DevEUI as an identifier for communications between the SCHC
gateway and network gateway.  (I assume that this is encrypted at least
as well as the regular LoRaWAN traffic, so there is not huge exposure,
but it seems like it is still worth documenting.)

Section 10.1

Why is RFC 8064 normative but not RFC 8065?  We cite them in exactly the
same circumstances, so they should receive identical treatment.

Sectino 10.2

I think [lora-alliance-spec] should probably be listed as normative;
even if you try to implement LoRaWAN SCHC as a separate module than the
core LoRaWAN stack, you still need to know about integrating with the
FPort.

Similarly, since the RFC 4493 AES-CMAC is used for generating the IID
(which is a MUST-level requirement), RFC 4493 needs to be a normative
reference.  (I note that RFC 4493 is already listed at
https://datatracker.ietf.org/doc/downref/ so there is no process concern
in doing so.)

Appendix A

   In following examples "applicative payload" refers to the IPv6
   payload sent by the application to the SCHC layer.

This is a slightly unfortunate terminology choice, since we also use the
unadorned term "payload" to refer to (what I assume is) the IPv6
payload, i.e., the actual application data.

Appendix A.2

Compressing a 478 byte IPv6 packet down to 283 bytes is quite
impressive, almost unrealistically so, considering that the base IPv6
header is 40 bytes and we can only get a few more from (e.g.) UDP port
numbers and such.

Appendix A.3

This is again an impressive compression result for only IPv6+UDP input.

Can someone please explain when there will actually be defined a context establishment mechanism for a link technology applying shch? This specification do not appear to be usable in an general interoperable way eithout that. What is the intention for lorawan to solve this issue?

I found this document to be very tough going without reading through RFC8724.

- I am not sure what Fig. 5 depicts. Does this mean that an "SCHC Packet" is a subset of an "SCHC Message", prepended by the Fport and LoRaWan payload? Because Fig. 4 of RFC 8724 says an "SCHC Packet" consists of a "Payload" prepended by the Rule ID (which corresponds to the FPort) and "Compression Residue". Please align the terminology!

- There are numerous terms from 8724 that could use a brief definition here on first use: for example RuleID, MSB, RX1, RX2, and IID.

- Sec 5.6.2:
   For battery powered devices, it is RECOMMENDED to use the ACK
   mechanism at the end of each window instead of waiting until the end
   of all windows...

   For non-battery powered devices, the SCHC receiver MAY also choose to
   send a SCHC ACK only at the end of all windows.  This will reduce
   downlink load on the LoRaWAN network, by reducing the number of
   downlinks.

This text is ambiguous. For example, the first paragraph can be interpreted as "battery-powered devices SHOULD send an ACK at the end of each window, instead of waiting till the end of all windows", or "endpoints sending to battery-powered devices SHOULD send an ACK at the end of each window...." To the layman, it is a little odd that the non-battery-powered devices are more encouraged to send fewer messages! Some explanatory text would be useful.

- Sec 5.6.5.3.1
"All fragments but the last have an FCN=0
   (because window size is 1).  Following it, the device MUST transmit
   the SCHC ACK message."

What is "it"? All fragments, or the FCN=1 fragment?