Subject: [lp-wan] I-D Action: draft-ietf-lpwan-schc-over-lorawan-05.txt

From: [email-masked]
Date: Fri, 20 Dec 2019 06:48:49 -0800

A New Internet-Draft is available from the on-line Internet-Drafts directories.
This draft is a work item of the IPv6 over Low Power Wide-Area Networks WG of the IETF.

        Title           : Static Context Header Compression (SCHC) over LoRaWAN
        Authors         : Olivier Gimenez
                          Ivaylo Petrov
	Filename        : draft-ietf-lpwan-schc-over-lorawan-05.txt
	Pages           : 24
	Date            : 2019-12-20

Abstract:
   The Static Context Header Compression (SCHC) specification describes
   generic header compression and fragmentation techniques for LPWAN
   (Low Power Wide Area Networks) technologies.  SCHC is a generic
   mechanism designed for great flexibility so that it can be adapted
   for any of the LPWAN technologies.

   This document provides the adaptation of SCHC for use in LoRaWAN
   networks, and provides elements such as efficient parameterization
   and modes of operation.  This is called a profile.

The IETF datatracker status page for this draft is:
https://datatracker.ietf.org/doc/draft-ietf-lpwan-schc-over-lorawan/

There are also htmlized versions available at:
https://tools.ietf.org/html/draft-ietf-lpwan-schc-over-lorawan-05
https://datatracker.ietf.org/doc/html/draft-ietf-lpwan-schc-over-lorawan-05

A diff from the previous version is available at:
https://www.ietf.org/rfcdiff?url2=draft-ietf-lpwan-schc-over-lorawan-05

Please note that it may take a couple of minutes from the time of submission
until the htmlized version and diff are available at tools.ietf.org.

Internet-Drafts are also available by anonymous FTP at:
ftp://ftp.ietf.org/internet-drafts/

---

From: Olivier Gimenez <[email-masked]>
Date: Fri, 20 Dec 2019 15:03:45 +0000

Hi,

I just pushed a new draft revision including the following changelog:

  *  Fix typos and formatting
  *  Add IID proposition
  *  Clarify lot of paragraphs following Dominique review
  *  Update acknowledgements
  *  Change ACK behaviour between each windows to optional for uplink fragmentation

We proposed an algorithm for IID which is close to the discussion we had with Dave Thaler during IETF-106, the idea is to create a hash derived from DevEUI and AppSKey. AppSkey is the only candidate we can find shared by the SCHC gateway and the device, which changes over time (RFC8065), in our case after each join/rejoin. This should also be validated by LoRaWAN security group to know if we can reuse AppSKey for such purpose

There is another proposition based on RFC7217 which the IID is "stable for each subnet": RID = F(Prefix, Net_Iface, Network_ID, DAD_Counter, secret_key), where Net_Iface can be DevEUI and Network_ID the LoRaWAN netid. 

I prefer the first proposition as it will mitigate correlation over time, the drawback is that we reuse AppSKey for something else than payload LoRaWAN protection.
The second proposition need a way to share the secret_key before communication and using LoRaWAN Netid might be an issue in passive roaming.

Any thoughts or comments ?

Thank you, and merry Christmas !
Olivier

> -----Original Message-----
> From: lp-wan <[email-masked]> On Behalf Of internet-

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.