Summary: Has enough positions to pass.
** 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.
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 18.104.22.168.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?
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 22.214.171.124.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 §126.96.36.199, 188.8.131.52) 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 184.108.40.206.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.
[[ 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).
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?
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?