[lp-wan] Benjamin Kaduk's No Objection on draft-ietf-lpwan-schc-over-lorawan-13: (with COMMENT)

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

Benjamin Kaduk has entered the following ballot position for
draft-ietf-lpwan-schc-over-lorawan-13: No Objection

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-schc-over-lorawan/



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

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.