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

From: JADHAV Rahul via Datatracker <[email-masked]>
Date: Sun, 20 Sep 2020 11:45:41 -0700

Reviewer: JADHAV Rahul
Review result: Ready with Issues

Dear authors of schc-over-lorawan,

Thank you for this work.
Following is my review handled as part of IoT-DIR review process:

Section 4:
[RJ] The architecture shows "Join Server" but the section has no explanation
for it.

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.

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.

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.

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.

Section 4.6:
[RJ] FRMPayload is not defined anywhere.

Section 5.1:
[RJ] I believe the term "fragmented datagram" should be used in place of
"fragmentation datagram" in the whole of this para.

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?

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?

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.

Section 5.6.1:
Please provide a reference to Section 8.2.4 in RFC 8724 for DTag.

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.

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?

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.

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?

Minor Nits:

Section 3:

Known information are part of the "context".
Known information is of the "context".

This component called SCHC...
This component is called SCHC...

...the RG is called a Gateway...
...the RGW is called a Gateway...

Section 4:

SCHC C/D and F/R are LoRaWAN Application Server;
SCHC C/D and F/R are handled by LoRaWAN Application Server;

Section 4.4:
...contains (amongst other fields) the major network's settings...
...contains (amongst other fields) the network's major settings...

Section 4.7:
...a packet send over LoRaWAN radio link...
...a packet sent over LoRaWAN radio link...

Section 5.2:
In order to improve interoperability RECOMMENDED fragmentation....
In order to improve interoperability, RECOMMENDED fragmentation....

Section 5.6.2:
In that case the device is the fragmentation transmitter, and the SCHC gateway
the fragmentation receiver. In that case, the device is the fragment
transmitter, and the SCHC gateway is the fragment receiver.

Section 5.6.3.1: Figure title
"including LoraWAN FPort"
"including LoRaWAN FPort"

Section 6: Section Title
Security considerations
Security Considerations

---

From: "Eric Vyncke (evyncke)" <[email-masked]>
Date: Tue, 22 Sep 2020 19:58:32 +0000

Thank you very much for the review.

I will use it when balloting on this document

-éric

-----Original Message-----
From: JADHAV Rahul via Datatracker <[email-masked]>
Reply-To: JADHAV Rahul <[email-masked]>
Date: Sunday, 20 September 2020 at 20:45
To: "[email-masked]" <[email-masked]>
Cc: "[email-masked]" <[email-masked]>, "[email-masked]" <[email-masked]>, "[email-masked]" <[email-masked]>
Subject: Iotdir telechat review of draft-ietf-lpwan-schc-over-lorawan-10
Resent-From: <[email-masked]>
Resent-To: <[email-masked]>, <[email-masked]>, Pascal Thubert <[email-masked]>, <[email-masked]>, Eric Vyncke <[email-masked]>, <[email-masked]>, Dominique Barthel <[email-masked]>, <[email-masked]>
Resent-Date: Sunday, 20 September 2020 at 20:45

    Reviewer: JADHAV Rahul

    Thank you for this work.

    Section 4:

    Section 4:

    Section 4:

    Section 4.1:

    Section 4.3/4.4:

    Section 4.6:

    Section 5.1:

    Section 5.1:

    Section 5.2:

    Section 5.3:

    Section 5.6.1:

    Section 5.6.2:

    Section 5.6.3:

    Section 5.6.3.5.1:

    Minor Nits:

    Section 3:

    Section 4:

    Section 4.4:

    Section 4.7:

    Section 5.2:

    Section 5.6.2:

    Section 6: Section Title
    Security considerations
    Security Considerations

---

From: Olivier Gimenez <[email-masked]>
Date: Mon, 28 Sep 2020 11:10:59 +0000

Dear Rahul,

Thank you very much for your review. Please find my answers/questions in your email

Best regards

Olivier

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

> 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

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

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

> 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

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

> "fragmentation datagram" in the whole of this para.

[OG] Ok, changed in commit dac5709<https://github.com/Acklio/schc-over-lorawan/commit/dac5709adc6cd8154b70fde0ce570c06279b859d>

> "It uses another FPort for data downlink and its associated SCHC control uplinks,

> named FPortDown in this document." [RJ] Just for my understanding, the

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

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

?

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

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

> 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

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

> sure.

[OG] yes, updated with your proposition in commit 8470063<https://github.com/Acklio/schc-over-lorawan/commit/8470063344dcb0736318b3f0183770460cd381bb>

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

> Minor Nits:

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

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.