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

[Olivier Gimenez <[e-mail]>]

Dear Benjamin,



Thank you for this in depth review and your useful comments.

I answered in your email and I did all the changes in this commit<https://github.com/Acklio/schc-over-lorawan/commit/5614d17db002be38465329d4f7ed1301589182a1>



Best regards

Olivier



> -----Original Message-----

> From: lp-wan <[e-mail]> On Behalf Of Benjamin Kaduk via

> Datatracker

> Sent: 04 November 2020 03:17

> To: The IESG <[e-mail]>

> Cc: [e-mail]; [e-mail]; draft-ietf-lpwan-schc-over-

> [e-mail]; [e-mail]

> Subject: [lp-wan] Benjamin Kaduk's No Objection on draft-ietf-lpwan-schc-over-

> lorawan-13: (with COMMENT)

>

> Warning - External Email

> ________________________________

>

> 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).



[OG] Several SCHC fragmentation sessions cannot be interleaved on the same fport (see §5.2 and §5.6.1),

thus there is no "higher- priority, downlink traffic to send", from SCHC gateway point of view.

Section 5.6.3.5.1 says that a device should keep the SCHC ACK message to be able to send it

again if the SCHC gateway asks for it (in case of lost packet). If the SCHC gateway send any other

SCHC message than a SCHC ACK REQ the device knows that the SCHC ACK has been correctly received.



> 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.



[OG] It was to avoid un-necessary parts. There is no ambiguity in the SCHC Receiver-Abort,

nor any confusion possible with other message so we saw no need to repeat RFC8724 example

with N=6. The receiver abort has been described as it must be distinguishable from SCHC

Receiver-Abort.

That said it can be added if you think that we should be in SCHC over LoRaWAN I-D



> 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).



[OG] Sorry, but I am not sure to understand your comment. We do not specify all RuleIDs. They

should be defined per application or device, but some specific for the profile to work:

* Uplink fragmentation

* Downlink fragmentation

* No compression nor fragmentation.



> 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 .



[OG] Thanks. I expended first use and added it to the terminology chapter



> Section 3

>

> It seems like it might be useful to indicate in the figure where the LoRaWAN

> network boundary is.



[OG] Good idea, thanks:


   End Device                                               App
+--------------+                                    +----+ +----+ +----+
|App1 App2 App3|                                    |App1| |App2| |App3|
|              |                                    |    | |    | |    |
|      UDP     |                                    |UDP | |UDP | |UDP |
|     IPv6     |                                    |IPv6| |IPv6| |IPv6|
|              |                                    |    | |    | |    |
|SCHC C/D & F/R|                                    |    | |    | |    |
+-------+------+                                    +----+ +----+ +----+
        |  +-------+     +-------+    +-----------+    .      .      .
        +~ |Gateway| === |Network| == |Application|..... Internet ....
           +-------+     |server |    |server     |
                         +-------+    | F/R - C/D |
                                      +-----------+
|<- - - - - LoRaWAN - - - ->|



Figure 3 is modified in the same way



> 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.



[OG] Sure, corrected



>    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?



[OG] No, a unique DevEUI is attached to a device. It is only send over the

air during the join procedure. All regular uplink/downlinks do not use it.

The interface between the SCHC gateway and the Network Gateway is not

defined by the LoRaWAN specification but usually encrypted so this data

cannot be listened to.





> 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/



[OG] Thanks, already reported and corrected



> 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.



[OG] Fixed



> 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?



[OG] RuleId (Fport) is enough. If the RuleID is known in the rule tables then it is an SCHC Message



> 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.



[OG] That is true: it is not a good cryptographic hygiene but LoRaWAN security

and technical committee have accepted that we reuse the AppSKey for this

purpose. Please also note that IID only use half of the CMAC output, reducing

the risk of attacks trying to reconstruct AppSKey.

Moreover an application with security concerns can make regular join to renew

the AppSKey



My knowledge of cryptographic hash generation is not good enough to know if

replacing/appending few bytes of the AppSkey would help, but as said LoRaWAN

committee validated this.



> [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.



[OG] Yes, I changed the order to respect appendix D order



> Also, a forward reference to the subsections that provide the layout of the

> various fields would be appreciated.



[OG] Good suggestion, I added them



>    o  DTag: Size is 0 bit, not used.

> We should probably say specifically that T is 0 bits.



[OG] OK, done



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

> Likewise, M is 2 bits.



[OG] there was actually an issue here as w is the field name so I corrected it to: “4 windows are used, encoded on M = 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).



[OG] Done



>    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?



[OG] Ok, added



>    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?



[OG] Yes, as defined in RFC8724



>    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?



[OG] The gateway will not know if the device is battery-powered, but the application designer will.

This foreseen to be tuned during application design, as for the retransmission and inactivity timers



>    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?



[OG] It fails the transmission with an SCHC sender abort message, as per RFC8724



>    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".



[OG] Ok, I added you proposition to clarify this, but after the list of parameters.

I think that it will be easier for reader (cf this line)



> 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.



[OG] Most parameters (cf RFC8724 §8.4.1) are shared for both. But for better clarity I split the lists: one common and one dedicated for ACK-Always (Unicast)



>    o  DTag: Size is 0 bit, not used.

>

> Should probably mention T, again.



[OG] Yes, done



>

>    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?



[OG] Yes



> Are there any cases (multiple losses) where we might be reduced to a trickle of

> 20 bytes every 24 hours?



[OG] I guess than 20 bytes is just an example as LoRaWAN downlinks are greater.

During a SCHC session, if a packet is lost a SCHC ACK is “immediately

queues for transmission” up to MAX_ACK_REQUESTS. If MAC_ACK_REQUESTS is

reached the session is aborted. So this case cannot happen. Cf 5.6.3.5.1. part  SCHC All-0 (FCN=0)

At the end of a transmission session we also have a mechanism ensure that all SCHC ACK REQ

are send before RETRANSMISSION_TIMER timeout. Cf 5.6.3.5.1. part  SCHC All-0 (FCN=0)



So no, we should not reach this reduce state.



> 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.



[OG] Yes



> 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?



[OG] This is why we added “downlink SCHC Fragmentation Message (with FPort ==FPortDown)”.

So other non SCHC related traffic (applicative or LoRaWAN MAC commands) does not disturb

the SCHC implementation



> 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.



[OG] Indeed it is redundant. I initially left them out because of that but working group

decided during the last call to add them as RFC8724 – Appendix D says that it must be

described in the profile



> 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.)



[OG] I’ll try to suggest something ☺



> 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.



[OG] Thank you for catching it. Both are now informative



> 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.



[OG] Good advice, I changed it as normative



> 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.)



[OG] Yes I was not sure because RFC4493 is “informal” and not “standard track” but

we discussed it with Eric V. and I changed it to normative



> 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.



[OG] Ok, I changed from “applicative payload” to “applicative 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.



[OG] SCHC can also compress static “application data”, not only the IPv6 header. Nevertheless I

reduced the number of application data bytes to avoid setting false expectations related to

compression ratio



To view our privacy policy, including the types of personal information we collect, process and share, and the rights and options you have in this respect, see www.semtech.com/legal.