Re: [lp-wan] IID computation for SCHC over LoRaWAN

[Olivier Gimenez <[e-mail]>]

Dear,

As last interim has been cancelled here is the proposition I wanted to make:

Keep as explained in the document, derive IID from AppSKey and DevEUI, then add
"There is a small probability of IID collision in a network, if such event occur the IID can be changed by rekeying the device (ie: rejoin). The way the device is rekeyed is out of scope of this document and left to the implementation."

But I also wonder if we can allow a ruleID for that: Ex: If a message is delivered with ruleId XXX, device must rejoin.
If not it seems reasonable to me that implementation has to define a port for rejoining. What are your thoughts ?

We might even go a step further and use this port for configuration:

*         Rejoin command

*         Network prefix

*         Rules, in few years :)


Thank you
Olivier



From: Olivier Gimenez
Sent: 11 February 2020 21:58
To: lp-wan <[e-mail]>
Cc: [e-mail]; Ivaylo Petrov <[e-mail]>; Pascal Thubert (pthubert) <[e-mail]>
Subject: Re: [lp-wan] IID computation for SCHC over LoRaWAN


Hi,



Following last interim meeting I tried to weight both approaches I presented.



1. NAT like - Devices does not know its public IP address

Pros:

* Easy to implement

* Conflicts are resolved by the gateway itself

* No need to share the network 64 bits prefix beforehand

Cons:

* Some upper layer might require to know their public address. FTP and Skype might not be a real concern for LPWAN but it is an issue for DLMS, so it is a no go for me.



2. Derive IID from AppSKey and DevEUI

Pros:

* Device has access to its public IP, no "NAT"

* Conflicts can be resolved by changing AppSKey with new join

Cons:

* Need to share network 64bits prefix beforehand. Mitigated as the rules also need to be shared so it can be part of the same mechanism

* Need to define a way to create a new join



So, as discussed in the interim I think that the proposition to recommend a new join if the implementer find the conflict probability too high, without specifying how, is the way to go.

Do you agree with it ? Any other last minute idea ?



Thank you

Best regards

________________________________
From: Olivier Gimenez
Sent: Monday, January 27, 2020 10:38:22 AM
To: lp-wan
Cc: [e-mail]<mailto:[e-mail]>; Ivaylo Petrov; Pascal Thubert (pthubert)
Subject: Re: [lp-wan] IID computation for SCHC over LoRaWAN


Hi,



According to Wikipedia<https://en.wikipedia.org/wiki/Birthday_problem#Probability_table> for 64 bits IID:

  *   when 190 000 devices are in the network, collision probability is one out of a billion
  *   when 6 100 000 devices are in the network, collision probability is one out of a million

I am still convinced that we should not add any specification/code complexity with such low numbers, anyway we wonder if another approach can be used:

Please see attached picture, the gateway can be seen as a NAT router: the device is able to compute its IP address based on devEUI or whatever we find relevant, which will be unique inside an IPv6 network (but will not change over time or be obfuscated), then IP used outside LoRaWAN network is computed in the SCHC gateway, this way an address collision is detected in the gateway and a new IP can be generated.
Another pro is there is no more need to provision the network prefix into the device

Any thoughts ?

Thank you
Olivier

[cid:image001.png@01D5EAF2.228EB260]

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.