Subject: Re: [Iot-directorate] Iotdir telechat review of draft-ietf-lpwan-schc-over-lorawan-10

From: Rahul Jadhav <[email-masked]>
Date: Fri, 2 Oct 2020 10:53:08 +0530

Thank you Olivier. Most of the comments are resolved but there are few
unresolved ones. Please find my comments in the context.

Thanks

On Mon, 28 Sep 2020 at 16:41, Olivier Gimenez <[email-masked]> wrote:

> Dear Rahul,
>
>
>
> Thank you very much for your review. Please find my answers/questions in
> your email
>
>
>
> Best regards
>
> Olivier
>
>
>
> > -----Original Message-----
>
> > From: JADHAV Rahul via Datatracker <[email-masked]>
>
> > Section 4:
>
> > [RJ] The architecture shows "Join Server" but the section has no
> explanation for
>
> > it.
>
>
>
> [OG] Ok, added in commit 669cc0d
> <https://github.com/Acklio/schc-over-lorawan/commit/669cc0d6a699ed9db20fbcb2a8fb2000d19066d2>
> :
>
> *The LPWAN-AAA Server is the LoRaWAN Join Server. Its role is to manage
> and*
>
> *deliver security keys in a secure way, so devices root key is never
> exposed.*
>
> [RJ] ok

>
>
> > Section 4:
>
> > "The Network Gateway (NGW) is the interconnection node between the Radio
>
> > Gateway and the Internet." [RJ] It is mentioned that NGW is the gateway
> to the
>
> > Internet but the SCHC C/D and F/R is handled on the LoRaWAN application
>
> > server.
>
> > How would the compressed packets be sent out to the Internet from NGW?
> [RJ]
>
> > In the last para of the section it is mentioned that "(SCHC gateway)
> acts as the
>
> > first-hop IP router for the device. This means that the NGW is not the
>
> > interconnection node between the RGW and the Internet.
>
>
>
> (OG] True, this has been written from LoRaWAN point of view, where data
> are usually
>
> transmitted from the Network Server (NGW) to the Application server (SCHC
> gateway)
>
> thought internet. But it is misleading in this context. I updated it in
> commit  d7ae663
> <https://github.com/Acklio/schc-over-lorawan/commit/d7ae663f39889d7207ca4dea8d5a38801274415b>
> :
>
> *The Network Gateway (NGW) is the interconnection node between the*
>
> *   Radio Gateway and the SCHC gateway (LoRaWAN Application server). This*
>
> *   entity maps to the LoRaWAN Network Server.*
>
> [RJ] Ok

>
>
> > Section 4:
>
> > [RJ] The terms used in the architecture figure 3 and the document are
>
> > different/confusing. For e.g., the figure mentions Application Server
> which is
>
> > referred to as SCHC Gateway in the overall document. The figure mentions
>
> > Network Server but is referred to as Network Gateway (NGW) in the overall
>
> > document. As a reader, I wanted to use this architecture diagram as a
> ref but
>
> > the terms mentioned in the diagram are different from those used in the
> draft
>
> > elsewhere.
>
>
>
> [OG] This chapters explains a LoRaWAN network. I have been asked use all
>
> terminology from the RFC8376 (see figure 9) instead of LoRaWAN terminology
>
> for the other chapters of the document. Mapping is defined thanks to
> figures 1
>
> and 2.
>
> [OG] Should I delete figure 3 as it creates more confusion that clarity ?
>
> [RJ] Actually for me fig 3 was very helpful. However, there is big
friction to understand and relate the terms from the text section to that
with the figure. One way to handle this is to mention both the terms,
keeping the RFC 8376 terms in brackets, and explicitly stating the origin
of those terms as a note in the figure.

>
>
> > Section 4.1:
>
> > "The lower the downlink latency, the higher the power consumption."
>
> > [RJ] I didn't understand why lower latency could result in higher power
>
> > consumption. I think the intention was to use either downlink frequency
> or
>
> > listen periodicity as a driver for higher power consumption.
>
>
>
> Lower latency means more wakes up of the device to open an RX window,
>
> thus more power consumption. I clarified in commit d755ed2
> <https://github.com/Acklio/schc-over-lorawan/commit/d755ed21b4a668df7d0665ff120ced498015e845>
> :
>
> *There is a trade-off between the*
>
> *  periodicity of those scheduled Class B listen windows and the power*
>
> *  consumption of the device: if the periodicity is high downlinks from
> the NGW*
>
> *  will be send faster, but the device wakes up more often: it will have
> higher*
>
> *  power consumption*
>
>
>
[RJ] Works. However, check minor nits raised as a review comment in the
corresponding commit.

> Section 4.3/4.4:
>
> > [RJ] The terms "frames" and "messages" are used interchangeably. Would be
>
> > better to use a fixed term, or else clarify these terms in the document.
>
>
>
> [OG] Clarified in commit 459eda2
> <https://github.com/Acklio/schc-over-lorawan/commit/459eda294aae7483a8a8fd00d65ed68ec4185260>.
> "frame" is now used for LoRaWAN only, "message" as "SCHC messages" defined
> in RFC8724
>
[RJ] Works

>
>
> > Section 4.6:
>
> > [RJ] FRMPayload is not defined anywhere.
>
>
>
> [OG] Defined in the terminology section. commit 872eb3f
> <https://github.com/Acklio/schc-over-lorawan/commit/872eb3f817cd8603f84e67fe2e3aa711eb6234c3>
> :
>
> *FRMPayload: Application data in a LoRaWAN frame.*
>
> [RJ] works

>
>
> > Section 5.1:
>
> > [RJ] I believe the term "fragmented datagram" should be used in place of
>
> > "fragmentation datagram" in the whole of this para.
>
>
>
> [OG] Ok, changed in commit dac5709
> <https://github.com/Acklio/schc-over-lorawan/commit/dac5709adc6cd8154b70fde0ce570c06279b859d>
>
>
>
[RJ] works

> > Section 5.1:
>
> > "It uses another FPort for data downlink and its associated SCHC control
> uplinks,
>
> > named FPortDown in this document." [RJ] Just for my understanding, the
>
> > FPortUp and FPortDown are disjoint sets i.e., an FPort part of FPortUp
> set
>
> > cannot be part of the FPortDown set. Is this correct? If yes, can we
> make it
>
> > explicit in the document?
>
>
>
> [OG] FPortUp and FPortDown are single values. FPortUp must be different
>
> than FPortDown as described in chapter "5.2.  Rule ID management".
>
> Should we switch both chapter for improved clarity ? I find it easier to
> read as it is.
>
> [RJ] I did not find any statement in Section 5.2 which says that the
"FPortUp must be different that FPortDown".  Which statement are you
referring to?

>
>
> > Section 5.2:
>
> > "RuleID = 22 (8-bit) for which SCHC compression was not possible..."
>
> > [RJ] I believe RuleID = 22 is provisioned for LoRaWAN messages which are
> sent
>
> > uncompressed i.e., if a device wants to send an uncompressed IPv6 then
> it can
>
> > use this RuleID. Is this correct? If yes, can we state this sample
> use-case for
>
> > RuleID=22?
>
>
>
> [OG] Its aim is to be used when no compression rule is defined more that
> when the
>
> device wants to send uncompressed IPv6. Should I change it to the
> description of RFC8724:
>
> *for  which SCHC compression was not possible (i.e., no matching*
>
> *         compression Rule was found).*
>
> ?
>
> [RJ] I am not sure which description of RFC 8724 are you referring to. Can
you please quote the section etc?

>
>
>
>
> > Section 5.3:
>
> > "There is a small probability of IID collision in a LoRaWAN network, if
> such
>
> > event occurs the IID can be changed by rekeying the device on L2 level
> (ie:
>
> > trigger a LoRaWAN join)." [RJ] As I understand, IID collision can be
> detected
>
> > only by the Network Gateway. How would the Network Gateway initiate a
>
> > LoRaWAN join? Section 4.4 defines that only the end device can initiate a
>
> > JoinRequest frame.
>
>
>
> [OG] It has been discussed by the working group and the consensus have
> been that
>
> it should be defined by the application if the IID collision is a concern
> in the
>
> application (collision risk grows with the number of devices in a network)
>
>
>
> [OG] For your information Section 4.4 does says that the joinRequest is
> send by
>
> a device but not how it is triggered. In LoRaWAN v1.1, NGW is able to
> trigger a
>
> new joinRequest of a connected device.
>
 [RJ] Collision can only be detected on the NGW. If LoRaWAN v1.1 can handle
it from NGW, an implementer should know. I see that lora-spec v1.1 is not
mentioned in informative ref. Is this spec available in public? If yes, can
we add a ref?

>
>
> > Section 5.6.1:
>
> > Please provide a reference to Section 8.2.4 in RFC 8724 for DTag.
>
>
>
> [OG] Added in commit 7b43c1c
> <https://github.com/Acklio/schc-over-lorawan/commit/7b43c1c154ee677f863c5b83c319ee254deecb67>
> :
>
> *[RFC8724] section 8.2.4 describes the possibility to interleave several*
>
> *fragmented SCHC datagrams for the same RuleID. This is not used in SCHC
> over*
>
> *LoRaWAN profile. A Device cannot interleave several fragmented SCHC
> datagrams*
>
> *on the same FPort.  This field is not used and its size is 0.*
>
>
>
[RJ] Works.

> > Section 5.6.2:
>
> > The term Tile is not defined in the document nor is there a ref to RFC
> 8724.
>
> > Better to redefine it here or at least have a ref to RFC 8724.
>
>
>
> [OG] Defined in terminology section and added reference to RFC 8724 in
> commit 5c6fad7
> <https://github.com/Acklio/schc-over-lorawan/commit/5c6fad7a1f5d2ae42cdaf962aa5f82f948ac9df0>
>
> *Tile: Piece of a fragmented packet as described in [RFC8724] section
> 8.2.2.1*
>
> [RJ] Works

>
>
> > Section 5.6.3:
>
> > The term "applicative uplink" is used in this and subsequent sections.
> Are you
>
> > referring to the application uplink? Not sure of what applicative means
> in the
>
> > context?
>
>
>
> [OG] Clarified in commit b08f639
> <https://github.com/Acklio/schc-over-lorawan/commit/b08f639f0dd775e4ddde9cef2d57cef8a455e260>
> as:
>
> *As this uplink is to open an RX window any LoRaWAN uplink frame from the
> device*
>
> *MAY reset this counter.*
>
>
>
[RJ] The term "applicative"  is used several places. The commit fixes it in
just one place. Please go a grep and consider fixing other places as well.

> > Section 5.6.3.5.1:
>
> > "LoRaWAN layer will respect the regulation if required."
>
> > I believe the local spectrum regulation is what is referred here, but am
> not
>
> > sure.
>
>
>
> [OG] yes, updated with your proposition in commit 8470063
> <https://github.com/Acklio/schc-over-lorawan/commit/8470063344dcb0736318b3f0183770460cd381bb>
>
[RJ] Works.

>
>
> > Section 6: Security Considerations
>
> > The section mentions the use of IID for privacy protection and the use of
>
> > AES-128 encryption for payload encryption. However, it is not clear to
> me as to
>
> > how the replay protection can be handled i.e. if an attacker replays the
> data
>
> > sent by any other node previously, how can it be protected? I believe
> this is
>
> > handled as part of the LoRaWAN mac layer?
>
>
>
> [OG] Yes security is handled by the LoRaWAN mac layer. As a non-exhaustive
> introduction, for LoRaWAN data frames:
>
> LoRaWAN frame payload (FRMPayload) is xored with an encrypted sequence
> changing for each uplink; the encryption key used is the AppSkey; then a
> Message Integrity Code (MIC) is added
>
> The AppSkey is derived from the AppKey, AppNonce, NetId and DevNonce after
> each joinReq
>
>
>
> See the security page
> <https://pages.services/pages.lora-alliance.org/lorawan-security/> of the
> LoRa Alliance and LoRaWAN specification
> <https://lora-alliance.org/sites/default/files/2018-07/lorawan1.0.3.pdf>
> for more details
>
>
>
> In the case of the IID, AES-128 is used to generate a hash as the
> algorithm is already implemented in LoRaWAN devices.
>
[RJ] Ok thanks for clarifying.

>
>
>
>
> > Minor Nits:
>
>
>
> [OG] Thank you, I corrected them in commit eee6754
> <https://github.com/Acklio/schc-over-lorawan/commit/eee675481dee1f5a6aedad45df23dcde25a2870e>
>
> [RJ] All Ok.

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

---

From: Olivier Gimenez <[email-masked]>
Date: Fri, 2 Oct 2020 08:39:21 +0000

Thank you for your feedback. I replied in your email

Olivier

From: Rahul Jadhav <[email-masked]>

[RJ] Actually for me fig 3 was very helpful. However, there is big friction to understand and relate the terms from the text section to that with the figure. One way to handle this is to mention both the terms, keeping the RFC 8376 terms in brackets, and explicitly stating the origin of those terms as a note in the figure.

[OG] Ok, I added them in 2e6aed7<https://github.com/Acklio/schc-over-lorawan/commit/2e6aed7f44fc75f99753b520cd9799c103d0cec3>

> "The lower the downlink latency, the higher the power consumption."
[RJ] Works. However, check minor nits raised as a review comment in the corresponding commit.

[OG] Thanks, fixed in 509d679<https://github.com/Acklio/schc-over-lorawan/commit/509d6796ebf932f8a43417cc569462511d52916f>

> Section 5.1:
[RJ] I did not find any statement in Section 5.2 which says that the "FPortUp must be different that FPortDown".  Which statement are you referring to?

[OG] Sorry it was not explicit in the document. I added it in a9bd3f9<https://github.com/Acklio/schc-over-lorawan/commit/a9bd3f9029bc8b165648c748f85b8352ffa03fa2>:
FPortUp value MUST be different from FPortDown

> "RuleID = 22 (8-bit) for which SCHC compression was not possible..."

[OG] Its aim is to be used when no compression rule is defined more that when the

device wants to send uncompressed IPv6. Should I change it to the description of RFC8724:

for  which SCHC compression was not possible (i.e., no matching

         compression Rule was found).

?
[RJ] I am not sure which description of RFC 8724 are you referring to. Can you please quote the section etc?

[OG] Ok, added in commit beb0dd6<https://github.com/Acklio/schc-over-lorawan/commit/beb0dd6a315ee248d9d995327c19e8e1c390e3e8>:
RuleID = 22 (8-bit) for which SCHC compression was not possible
      (i.e., no matching compression Rule was found), as described in  [RFC8724] section 6.

> "There is a small probability of IID collision in a LoRaWAN network, if such

> event occurs the IID can be changed by rekeying the device on L2 level (ie:

> trigger a LoRaWAN join)." [RJ] As I understand, IID collision can be detected

> JoinRequest frame.

[OG] It has been discussed by the working group and the consensus have been that

it should be defined by the application if the IID collision is a concern in the

[OG] For your information Section 4.4 does says that the joinRequest is send by

a device but not how it is triggered. In LoRaWAN v1.1, NGW is able to trigger a

new joinRequest of a connected device.
 [RJ] Collision can only be detected on the NGW. If LoRaWAN v1.1 can handle it from NGW, an implementer should know. I see that lora-spec v1.1 is not mentioned in informative ref. Is this spec available in public? If yes, can we add a ref?

[OG] IID collision is detected by SCHC gateway. Then, in LoRaWAN v1.1, this SCHC gateway can ask the NGW to trigger a new join to rekey the device, thus change the IID. It has been decided by the working group that the new join trigger is out of scope, as written section 5.3. Do you recommend to reconsider it ?
The way the device is rekeyed
   is out of scope of this document and left to the implementation

> The term "applicative uplink" is used in this and subsequent sections. Are you

> referring to the application uplink? Not sure of what applicative means in the

> context?

[OG] Clarified in commit b08f639<https://github.com/Acklio/schc-over-lorawan/commit/b08f639f0dd775e4ddde9cef2d57cef8a455e260> as:

As this uplink is to open an RX window any LoRaWAN uplink frame from the device

MAY reset this counter.

[RJ] The term "applicative"  is used several places. The commit fixes it in just one place. Please go a grep and consider fixing other places as well.

[OG] I explained “applicative payload” in the example introduction. commit 04929da<https://github.com/Acklio/schc-over-lorawan/commit/04929daa34ab52d6596c8fd602c75cc2c2812695>:

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

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.

---

From: "Eric Vyncke (evyncke)" <[email-masked]>
Date: Fri, 2 Oct 2020 09:11:42 +0000

Thank you Rahul and Olivier for keeping improving the document.

May we expect a revised I-D next week? Then, I will continue the publication process.

Regards

-éric

From: Olivier Gimenez <[email-masked]>
Date: Friday, 2 October 2020 at 10:39
To: Rahul Jadhav <[email-masked]>
Cc: "[email-masked]" <[email-masked]>, "[email-masked]" <[email-masked]>, "[email-masked]" <[email-masked]>
Subject: RE: Iotdir telechat review of draft-ietf-lpwan-schc-over-lorawan-10
Resent-From: <[email-masked]>
Resent-To: <[email-masked]>, <[email-masked]>, <[email-masked]>, Pascal Thubert <[email-masked]>, Eric Vyncke <[email-masked]>, <[email-masked]>, Dominique Barthel <[email-masked]>, <[email-masked]>
Resent-Date: Friday, 2 October 2020 at 10:39

Olivier

?

MAY reset this counter.

---

From: Rahul Jadhav <[email-masked]>
Date: Fri, 2 Oct 2020 15:04:57 +0530

Thanks Olivier. Most of the changes work for me. Few nits suggested in the
commits.

@Eric, I believe it should definitely be possible to get an updated ID by
next week since Olivier responses are prompt and I'll make sure I follow
suit.

Regards,
Rahul

On Fri, 2 Oct 2020 at 14:09, Olivier Gimenez <[email-masked]> wrote:

> *From:* Rahul Jadhav <[email-masked]>
>
> [OG] Ok, I added them in 2e6aed7
> <https://github.com/Acklio/schc-over-lorawan/commit/2e6aed7f44fc75f99753b520cd9799c103d0cec3>
>

[RJ] This works great for me. Thanks.

> [OG] Thanks, fixed in 509d679
> <https://github.com/Acklio/schc-over-lorawan/commit/509d6796ebf932f8a43417cc569462511d52916f>
>
[RJ] Ok

> [OG] Sorry it was not explicit in the document. I added it in a9bd3f9
> <https://github.com/Acklio/schc-over-lorawan/commit/a9bd3f9029bc8b165648c748f85b8352ffa03fa2>
> :
>
> *FPortUp value MUST be different from FPortDown*
>

[RJ] Perfect.

> [OG] Ok, added in commit beb0dd6
> <https://github.com/Acklio/schc-over-lorawan/commit/beb0dd6a315ee248d9d995327c19e8e1c390e3e8>
> :
>
> *RuleID = 22 (8-bit) for which SCHC compression was not possible*
>
> *      (i.e., no matching compression Rule was found), as described in
> [RFC8724] section 6.*
>
[RJ] Works. Reference to Section 6 of RFC 8724 definitely helps since it
has a clear requirement towards keeping such an ID explicit.

>  [RJ] Collision can only be detected on the NGW. If LoRaWAN v1.1 can
> handle it from NGW, an implementer should know. I see that lora-spec v1.1
> is not mentioned in informative ref. Is this spec available in public? If
> yes, can we add a ref?
>
>
>
> [OG] IID collision is detected by SCHC gateway. Then, in LoRaWAN v1.1,
> this SCHC gateway can ask the NGW to trigger a new join to rekey the
> device, thus change the IID. It has been decided by the working group that
> the new join trigger is out of scope, as written section 5.3. Do you
> recommend to reconsider it ?
>
> *The way the device is rekeyed*
>
> *   is out of scope of this document and left to the implementation*
>

[RJ] I take that as, lora-spec v1.1 is not publicly available and thus we
need to keep these rekeying specifics out of the document. If that's the
case, it works for me.

> [RJ] The term "applicative"  is used several places. The commit fixes it
> in just one place. Please go a grep and consider fixing other places as
> well.
>
>
>
> [OG] I explained “applicative payload” in the example introduction. commit
> 04929da
> <https://github.com/Acklio/schc-over-lorawan/commit/04929daa34ab52d6596c8fd602c75cc2c2812695>
> :
>
>
>
> *   In following examples "applicative payload" refers to the IPv6*
>
> *   payload send by the application to the SCHC layer.*
>

[RJ]  Works. Small nits in the text raised as comments in the commit.

---

From: Olivier Gimenez <[email-masked]>
Date: Fri, 2 Oct 2020 10:19:13 +0000

Thank you Rahul for your reactivity! I corrected the nits.
LoRaWAN specification v1.1 is public<https://lora-alliance.org/resource-hub/lorawanr-specification-v11> but most devices and NGW are still working on v1.0.x so I do not think that we should reference it.

Eric: yes, I just need to have a review from a co-author for merge request<https://github.com/Acklio/schc-over-lorawan/pull/35> then I will publish a new ID

Olivier