From 433ef4b8fa7dbb9a93078fefb7824129e66cea7c Mon Sep 17 00:00:00 2001 From: Oliv4945 Date: Mon, 30 Mar 2020 14:22:18 +0200 Subject: [PATCH 1/7] Add IID collision --- draft-ietf-lpwan-schc-over-lorawan.md | 4 ++++ 1 file changed, 4 insertions(+) diff --git a/draft-ietf-lpwan-schc-over-lorawan.md b/draft-ietf-lpwan-schc-over-lorawan.md index 05d4922..ea50e12 100644 --- a/draft-ietf-lpwan-schc-over-lorawan.md +++ b/draft-ietf-lpwan-schc-over-lorawan.md @@ -429,6 +429,10 @@ Exemple with: {: #Fig-iid-computation-example title='Example of IID computation.'} +There is a small probability of IID collision in a network, if such event occurs +the IID can be changed by rekeying the device on L2 level (ie: LoRaWAN rejoin). +The way the device is rekeyed is out of scope of this document and left to the +implementation. ## Padding From 104360cb6d015cb312cb5adbf3d95fc190477265 Mon Sep 17 00:00:00 2001 From: Oliv4945 Date: Mon, 30 Mar 2020 14:31:56 +0200 Subject: [PATCH 2/7] Fix typos --- draft-ietf-lpwan-schc-over-lorawan.md | 23 ++++++++++++----------- 1 file changed, 12 insertions(+), 11 deletions(-) diff --git a/draft-ietf-lpwan-schc-over-lorawan.md b/draft-ietf-lpwan-schc-over-lorawan.md index ea50e12..a4a6f53 100644 --- a/draft-ietf-lpwan-schc-over-lorawan.md +++ b/draft-ietf-lpwan-schc-over-lorawan.md @@ -146,10 +146,10 @@ Context exchange or pre-provisioning is out of scope of this document. {{Fig-archi}} represents the architecture for compression/decompression, it is based on {{RFC8376}} terminology. The Device is sending applications flows -using IPv6 or IPv6/UDP protocols. These flow might be compressed by an Static +using IPv6 or IPv6/UDP protocols. These flows might be compressed by an Static Context Header Compression Compressor/Decompressor (SCHC C/D) to reduce headers size and fragmented (SCHC F/R). The resulting information is sent on a layer two -(L2) frame to an LPWAN Radio Gateway (RGW) which forwards the frame to a Network +(L2) frame to an LPWAN Radio Gateway (RGW) that forwards the frame to a Network Gateway (NGW). The NGW sends the data to a SCHC F/R for defragmentation, if required, then C/D for decompression which shares the same rules with the device. The SCHC F/R and C/D can be located on the Network Gateway (NGW) or in @@ -301,10 +301,11 @@ confirmed messages. unique identifier devEUI and a random nonce that will be used for session key derivation. * JoinAccept: - To on-board an end-device, the Network Server responds to the JoinRequest end-device's - message with a JoinAccept message. That message is encrypted with the - end-device's AppKey and contains (amongst other fields) the major network's - settings and a network random nonce used to derive the session keys. + To on-board an end-device, the Network Server responds to the JoinRequest + issued by end-device's message with a JoinAccept message. That message is + encrypted with the end-device's AppKey and contains (amongst other fields) + the major network's settings and a network random nonce used to derive the + session keys. * Data: MAC and application data. Application data are protected with AES-128 encryption, MAC related data are AES-128 encrypted with another key. @@ -367,7 +368,7 @@ RuleID MUST be 8 bits, encoded in the LoRaWAN FPort as described in {{lorawan-schc-payload}}. LoRaWAN supports up to 223 application FPorts in the range \[1;223\] as defined in section 4.3.2 of {{lora-alliance-spec}}, it implies that RuleID MSB SHOULD be inside this range. An application can send non SCHC -traffic by using FPort values differents from the ones used for SCHC. +traffic by using FPort values different from the ones used for SCHC. In order to improve interoperability RECOMMENDED fragmentation RuleID values are: @@ -412,11 +413,11 @@ level. Address scan risk is mitigated thanks to AES-128, which provides enough entropy bits of the IID. -Using this algorithm will also ensure that there is not correlation between the -hardware identifier (IEEE-64 devEUI) and the IID, so an attacker can not use +Using this algorithm will also ensure that there is no correlation between the +hardware identifier (IEEE-64 devEUI) and the IID, so an attacker cannot use manufacturer OUI to target devices. -Exemple with: +Example with: * devEui: 0x1122334455667788 * appSKey: 0x00AABBCCDDEEFF00AABBCCDDEEFFAABB @@ -502,7 +503,7 @@ implementation to use ACK mechanism at the end of each window: * SCHC receiver sends an SCHC ACK after every window even if there is no missing tiles. * SCHC sender waits for the SCHC ACK from the SCHC receiver before sending tiles from - next window. If the SCHC ACK is not received it should send an SCHC ACK REQ up + next window. If the SCHC ACK is not received, it should send an SCHC ACK REQ up to MAX_ACK_REQUESTS time as described previously. This OPTIONAL feature will prevent a device to transmit full payload if the From 01e8752248cf48cf9e1ce25e635b3b75983b24c9 Mon Sep 17 00:00:00 2001 From: Oliv4945 Date: Mon, 30 Mar 2020 14:39:08 +0200 Subject: [PATCH 3/7] Update security --- draft-ietf-lpwan-schc-over-lorawan.md | 5 ++++- 1 file changed, 4 insertions(+), 1 deletion(-) diff --git a/draft-ietf-lpwan-schc-over-lorawan.md b/draft-ietf-lpwan-schc-over-lorawan.md index a4a6f53..105a9ed 100644 --- a/draft-ietf-lpwan-schc-over-lorawan.md +++ b/draft-ietf-lpwan-schc-over-lorawan.md @@ -744,9 +744,12 @@ RECOMMENDED value is 12 hours for both Class B and Class C end-devices. This document is only providing parameters that are expected to be better suited for LoRaWAN networks for {{I-D.ietf-lpwan-ipv6-static-context-hc}}. IID -security is discussed in {{IID}}.As such, this document does not contribute to +security is discussed in {{IID}}. As such, this document does not contribute to any new security issues in addition to those identified in {{I-D.ietf-lpwan-ipv6-static-context-hc}}. +Moreover SCHC data (LoRaWAN payload) are protected on LoRaWAN level by an AES-128 +encryption with key shared by device and SCHC gateway. Those keys are renew each +LoRaWAN session (ie: each join or rejoin to the network) # Acknowledgements {:numbered="false"} From 68ad95c6c2d7556dc30d3767a65fd03615f067b2 Mon Sep 17 00:00:00 2001 From: Oliv4945 Date: Mon, 30 Mar 2020 14:50:27 +0200 Subject: [PATCH 4/7] Improve SCHC ACK following Arun comment --- draft-ietf-lpwan-schc-over-lorawan.md | 7 +++++-- 1 file changed, 5 insertions(+), 2 deletions(-) diff --git a/draft-ietf-lpwan-schc-over-lorawan.md b/draft-ietf-lpwan-schc-over-lorawan.md index 105a9ed..bce92fc 100644 --- a/draft-ietf-lpwan-schc-over-lorawan.md +++ b/draft-ietf-lpwan-schc-over-lorawan.md @@ -506,8 +506,11 @@ implementation to use ACK mechanism at the end of each window: next window. If the SCHC ACK is not received, it should send an SCHC ACK REQ up to MAX_ACK_REQUESTS time as described previously. -This OPTIONAL feature will prevent a device to transmit full payload if the -network can not be reach, thus save battery life. +This OPTIONAL feature allows the implementation to select between: + * SCHC ACK after every window: Save battery life by preventing a device to + transmit full payload if the network cannot be reached + * Otherwise: Reduce downlink load on the network by reducing the number of downlinks + #### Regular fragments From 542a821d65f16973329a565810f1b1c39b196fff Mon Sep 17 00:00:00 2001 From: Oliv4945 Date: Mon, 30 Mar 2020 16:02:02 +0200 Subject: [PATCH 5/7] Fix RFC compilation --- draft-ietf-lpwan-schc-over-lorawan.md | 1 - 1 file changed, 1 deletion(-) diff --git a/draft-ietf-lpwan-schc-over-lorawan.md b/draft-ietf-lpwan-schc-over-lorawan.md index bce92fc..13e78f4 100644 --- a/draft-ietf-lpwan-schc-over-lorawan.md +++ b/draft-ietf-lpwan-schc-over-lorawan.md @@ -427,7 +427,6 @@ Example with: 2. cmac: 0x4E822D9775B2649928F82066AF804FEC 3. IID: 0x28F82066AF804FEC ~~~~ - {: #Fig-iid-computation-example title='Example of IID computation.'} There is a small probability of IID collision in a network, if such event occurs From 4d4d98320e7b8745682ce1233b6f8b023b47c80f Mon Sep 17 00:00:00 2001 From: Oliv4945 Date: Mon, 30 Mar 2020 16:02:15 +0200 Subject: [PATCH 6/7] Clarify last tile --- draft-ietf-lpwan-schc-over-lorawan.md | 7 ++++++- 1 file changed, 6 insertions(+), 1 deletion(-) diff --git a/draft-ietf-lpwan-schc-over-lorawan.md b/draft-ietf-lpwan-schc-over-lorawan.md index 13e78f4..12e8716 100644 --- a/draft-ietf-lpwan-schc-over-lorawan.md +++ b/draft-ietf-lpwan-schc-over-lorawan.md @@ -490,8 +490,13 @@ Packet, as per {{lorawan-schc-payload}}. * Inactivity timer: The SCHC gateway implements an "inactivity timer". The default RECOMMENDED duration of this timer is 12 hours; this value is mainly driven by application requirements and MAY be changed by the application. -* Last tile: The last tile MUST NOT be carried in the All-1 fragment. * Penultimate tile MUST be equal to the regular size. +* 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: implementation must ensure that: + * The sender MUST ascertain that the receiver will not receive + the last tile through both a Regular SCHC Fragment and an All-1 SCHC Fragment. + * If last tile is in All-1 message: current L2 MTU MUST be big enough to fit + the All-1 and the last tile. With this set of parameters, the SCHC fragment header is 16 bits, including FPort; payload overhead will be 8 bits as FPort is already a part of From 02f66d62ae6931da1dd4f2c0f4015a8ef64a9dcf Mon Sep 17 00:00:00 2001 From: Oliv4945 Date: Tue, 31 Mar 2020 07:50:50 +0200 Subject: [PATCH 7/7] Clarify rejoin term regarding LoRaWAN 1.1 --- draft-ietf-lpwan-schc-over-lorawan.md | 5 +++-- 1 file changed, 3 insertions(+), 2 deletions(-) diff --git a/draft-ietf-lpwan-schc-over-lorawan.md b/draft-ietf-lpwan-schc-over-lorawan.md index 12e8716..818cf80 100644 --- a/draft-ietf-lpwan-schc-over-lorawan.md +++ b/draft-ietf-lpwan-schc-over-lorawan.md @@ -407,7 +407,7 @@ already used by devices for LoRaWAN procotol. As AppSKey is renewed each time a device joins or rejoins a network, the IID will change over time; this mitigates privacy, location tracking and -correlation over time risks. Rejoin periodicity is defined at the application +correlation over time risks. Join periodicity is defined at the application level. Address scan risk is mitigated thanks to AES-128, which provides enough entropy @@ -430,7 +430,8 @@ Example with: {: #Fig-iid-computation-example title='Example of IID computation.'} There is a small probability of IID collision in a network, if such event occurs -the IID can be changed by rekeying the device on L2 level (ie: LoRaWAN rejoin). +the IID can be changed by rekeying the device on L2 level (ie: trigger a LoRaWAN +join). The way the device is rekeyed is out of scope of this document and left to the implementation.