From 061fab95187fc4b94a93a1d3c37da730fd85311b Mon Sep 17 00:00:00 2001 From: Oliv4945 Date: Sun, 5 Apr 2020 22:54:46 +0200 Subject: [PATCH 1/7] Typo in JoinAccept --- draft-ietf-lpwan-schc-over-lorawan.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/draft-ietf-lpwan-schc-over-lorawan.md b/draft-ietf-lpwan-schc-over-lorawan.md index 818cf80..1ce93fa 100644 --- a/draft-ietf-lpwan-schc-over-lorawan.md +++ b/draft-ietf-lpwan-schc-over-lorawan.md @@ -302,7 +302,7 @@ confirmed messages. derivation. * JoinAccept: 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 + issued by end-device's 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. From c7135644b633d199ddae0a643f2bc09c3a5f3700 Mon Sep 17 00:00:00 2001 From: Oliv4945 Date: Sun, 5 Apr 2020 22:55:56 +0200 Subject: [PATCH 2/7] Clarify sender ACK behavior --- draft-ietf-lpwan-schc-over-lorawan.md | 4 +++- 1 file changed, 3 insertions(+), 1 deletion(-) diff --git a/draft-ietf-lpwan-schc-over-lorawan.md b/draft-ietf-lpwan-schc-over-lorawan.md index 1ce93fa..7d69a13 100644 --- a/draft-ietf-lpwan-schc-over-lorawan.md +++ b/draft-ietf-lpwan-schc-over-lorawan.md @@ -511,7 +511,9 @@ 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 allows the implementation to select between: +SCHC sender MUST implement both cases to ensure compatibility with all +implementations. This 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 From dc18aebb9783ddc9d505123a09a32fcfecf12e58 Mon Sep 17 00:00:00 2001 From: Oliv4945 Date: Thu, 16 Apr 2020 15:12:00 +0200 Subject: [PATCH 3/7] Fix typos --- draft-ietf-lpwan-schc-over-lorawan.md | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) diff --git a/draft-ietf-lpwan-schc-over-lorawan.md b/draft-ietf-lpwan-schc-over-lorawan.md index 7d69a13..386afe8 100644 --- a/draft-ietf-lpwan-schc-over-lorawan.md +++ b/draft-ietf-lpwan-schc-over-lorawan.md @@ -302,7 +302,7 @@ confirmed messages. derivation. * JoinAccept: To on-board an end-device, the Network Server responds to the JoinRequest - issued by end-device's with a JoinAccept message. That message is + issued by an end-device 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. @@ -403,7 +403,7 @@ created regarding the following algorithm: 3. IID = cmac[0..7] aes128_cmac algorithm is described in [rfc4493]. It has been chosen as it is -already used by devices for LoRaWAN procotol. +already used by devices for LoRaWAN protocol. 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 From ff291de7fd90b76d85398dd3145467f16155c8e2 Mon Sep 17 00:00:00 2001 From: Oliv4945 Date: Thu, 16 Apr 2020 15:12:51 +0200 Subject: [PATCH 4/7] Reword SCHC ACK position --- draft-ietf-lpwan-schc-over-lorawan.md | 30 ++++++++++++++------------- 1 file changed, 16 insertions(+), 14 deletions(-) diff --git a/draft-ietf-lpwan-schc-over-lorawan.md b/draft-ietf-lpwan-schc-over-lorawan.md index 386afe8..c7938a2 100644 --- a/draft-ietf-lpwan-schc-over-lorawan.md +++ b/draft-ietf-lpwan-schc-over-lorawan.md @@ -503,20 +503,22 @@ 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 LoRaWAN payload. MTU is: _4 windows * 63 tiles * 10 bytes per tile = 2520 bytes_ -_Note_: As LoRaWAN is a radio communication, it is RECOMMENDED for an -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 - to MAX_ACK_REQUESTS time as described previously. - -SCHC sender MUST implement both cases to ensure compatibility with all -implementations. This 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 +For battery powered SCHC sender, it is RECOMMENDED to use ACK mechanism at the +end of each window instead of waiting the end of all windows: + +* SCHC receiver sends a 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 to MAX_ACK_REQUESTS time as described previously. + +For non-battery powered devices, SCHC receiver can also choose to send a SCHC +ACK only at the end of all windows. It will reduce downlink load on the network, +by reducing the number of downlinks. + +SCHC implementations must be compatible with both behavior, and selection is +made on a RuleID basis. The rules datamodel MUST include this field in the +fragmentation rules for LoRaWAN. #### Regular fragments From 8a56e1e5f79915d0732dee31b6a81533670f13b6 Mon Sep 17 00:00:00 2001 From: Oliv4945 Date: Thu, 16 Apr 2020 15:29:50 +0200 Subject: [PATCH 5/7] Replace draft-ipv6-static-context-hc by RFC8724 --- draft-ietf-lpwan-schc-over-lorawan.md | 22 +++++++++++----------- 1 file changed, 11 insertions(+), 11 deletions(-) diff --git a/draft-ietf-lpwan-schc-over-lorawan.md b/draft-ietf-lpwan-schc-over-lorawan.md index c7938a2..c423be7 100644 --- a/draft-ietf-lpwan-schc-over-lorawan.md +++ b/draft-ietf-lpwan-schc-over-lorawan.md @@ -41,7 +41,7 @@ normative: RFC8065: RFC8376: RFC4493: - I-D.ietf-lpwan-ipv6-static-context-hc: + RFC8724: informative: lora-alliance-spec: title: LoRaWAN Specification Version V1.0.3 @@ -72,7 +72,7 @@ This is called a profile. # Introduction {#Introduction} The Static Context Header Compression (SCHC) specification -{{I-D.ietf-lpwan-ipv6-static-context-hc}} describes +[RFC8724] describes generic header compression and fragmentation techniques that can be used on all LPWAN (Low Power Wide Area Networks) technologies defined in {{RFC8376}}. Even though those technologies share a great @@ -97,7 +97,7 @@ when, and only when, they appear in all capitals, as shown here. This section defines the terminology and acronyms used in this document. For all other definitions, please look up the SCHC specification -{{I-D.ietf-lpwan-ipv6-static-context-hc}}. +[RFC8724]. o DevEUI: an IEEE EUI-64 identifier used to identify the end-device during the procedure while joining the network (Join Procedure) @@ -116,7 +116,7 @@ all other definitions, please look up the SCHC specification This section contains a short overview of Static Context Header Compression (SCHC). For a detailed description, refer to the full specification -{{I-D.ietf-lpwan-ipv6-static-context-hc}}. +[RFC8724]. It defines: @@ -189,7 +189,7 @@ terminology to: An overview of LoRaWAN {{lora-alliance-spec}} protocol and architecture is described in {{RFC8376}}. The mapping between the LPWAN -architecture entities as described in {{I-D.ietf-lpwan-ipv6-static-context-hc}} +architecture entities as described in [RFC8724] and the ones in {{lora-alliance-spec}} is as follows: o Devices (Dev) are the end-devices or hosts (e.g. sensors, @@ -479,12 +479,12 @@ Packet, as per {{lorawan-schc-payload}}. * FCN: The FCN field is encoded on N = 6 bits, so WINDOW_SIZE = 63 tiles are allowed in a window * Window index: encoded on W = 2 bits. So 4 windows are available. -* RCS: Use recommended calculation algorithm in {{I-D.ietf-lpwan-ipv6-static-context-hc}}. +* RCS: Use recommended calculation algorithm in [RFC8724]. * MAX_ACK_REQUESTS: 8 * Tile: size is 10 bytes * Retransmission timer: LoRaWAN end-devices MUST NOT implement a "retransmission timer", this changes the specification of - {{I-D.ietf-lpwan-ipv6-static-context-hc}}, see {{uplink-class-a}}. It must + [RFC8724], see {{uplink-class-a}}. It must transmit MAX_ACK_REQUESTS time the SCHC ACK REQ at it own timing; ie the periodicity between retransmission of SCHC ACK REQs is device specific and can vary depending on other application uplinks and regulations. @@ -605,11 +605,11 @@ Packet as described in {{lorawan-schc-payload}}. * Multicast downlinks: No-ACK, reliability has to be ensured by the upper layer. This feature is OPTIONAL and may not be implemented by SCHC gateway. * RuleID: 8 bits stored in LoRaWAN FPort. -* Window index (unicast only): encoded on W=1 bit, as per {{I-D.ietf-lpwan-ipv6-static-context-hc}}. +* Window index (unicast only): encoded on W=1 bit, as per [RFC8724]. * DTag: Size is 0 bit, not used * FCN: The FCN field is encoded on N=1 bit, so WINDOW_SIZE = 1 tile (FCN=All-1 is reserved for SCHC). -* RCS: Use recommended calculation algorithm in {{I-D.ietf-lpwan-ipv6-static-context-hc}}. +* RCS: Use recommended calculation algorithm in [RFC8724]. * MAX_ACK_REQUESTS: 8 As only 1 tile is used, its size can change for each downlink, and will be @@ -755,10 +755,10 @@ RECOMMENDED value is 12 hours for both Class B and Class C end-devices. # Security considerations 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 +suited for LoRaWAN networks for [RFC8724]. IID 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}}. +[RFC8724]. 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) From 281d3465b0e3daffba38596bb10bb8438d1f9a4e Mon Sep 17 00:00:00 2001 From: Oliv4945 Date: Thu, 16 Apr 2020 16:20:28 +0200 Subject: [PATCH 6/7] Follow RFC2119 as recommended by Julien --- draft-ietf-lpwan-schc-over-lorawan.md | 10 +++++----- 1 file changed, 5 insertions(+), 5 deletions(-) diff --git a/draft-ietf-lpwan-schc-over-lorawan.md b/draft-ietf-lpwan-schc-over-lorawan.md index c423be7..2d52edf 100644 --- a/draft-ietf-lpwan-schc-over-lorawan.md +++ b/draft-ietf-lpwan-schc-over-lorawan.md @@ -506,17 +506,17 @@ LoRaWAN payload. MTU is: _4 windows * 63 tiles * 10 bytes per tile = 2520 bytes_ For battery powered SCHC sender, it is RECOMMENDED to use ACK mechanism at the end of each window instead of waiting the end of all windows: -* SCHC receiver sends a SCHC ACK after every window even if there is no +* SCHC receiver SHOULD send a 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 +* SCHC sender SHOULD wait 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 to MAX_ACK_REQUESTS time as described previously. -For non-battery powered devices, SCHC receiver can also choose to send a SCHC +For non-battery powered devices, SCHC receiver MAY also choose to send a SCHC ACK only at the end of all windows. It will reduce downlink load on the network, by reducing the number of downlinks. -SCHC implementations must be compatible with both behavior, and selection is +SCHC implementations MUST be compatible with both behavior, and selection is made on a RuleID basis. The rules datamodel MUST include this field in the fragmentation rules for LoRaWAN. From a9431aabcb9530d5b91d84564cb711e812252266 Mon Sep 17 00:00:00 2001 From: Oliv4945 Date: Fri, 17 Apr 2020 15:50:36 +0200 Subject: [PATCH 7/7] Fine tune SCHC ACK chapter --- draft-ietf-lpwan-schc-over-lorawan.md | 3 +-- 1 file changed, 1 insertion(+), 2 deletions(-) diff --git a/draft-ietf-lpwan-schc-over-lorawan.md b/draft-ietf-lpwan-schc-over-lorawan.md index 2d52edf..e93aef5 100644 --- a/draft-ietf-lpwan-schc-over-lorawan.md +++ b/draft-ietf-lpwan-schc-over-lorawan.md @@ -517,8 +517,7 @@ ACK only at the end of all windows. It will reduce downlink load on the network, by reducing the number of downlinks. SCHC implementations MUST be compatible with both behavior, and selection is -made on a RuleID basis. The rules datamodel MUST include this field in the -fragmentation rules for LoRaWAN. +a part of the rule context. #### Regular fragments