From b3d5aacee8423b7a636f8c48017568c51b947ab1 Mon Sep 17 00:00:00 2001 From: Julien Catalano Date: Tue, 5 Nov 2019 14:23:54 +0100 Subject: [PATCH 01/24] Fix Contributors section formatting - Remove YAML syntax, only valid for authors - Remove snail mail addresses - Inspired by this random RFC format https://tools.ietf.org/html/rfc8092#section-9.2 - RFC Editor policy: https://www.rfc-editor.org/policy.html#policy.authlist --- draft-ietf-lpwan-schc-over-lorawan.md | 66 ++++++++++----------------- 1 file changed, 23 insertions(+), 43 deletions(-) diff --git a/draft-ietf-lpwan-schc-over-lorawan.md b/draft-ietf-lpwan-schc-over-lorawan.md index 0887548..547d472 100644 --- a/draft-ietf-lpwan-schc-over-lorawan.md +++ b/draft-ietf-lpwan-schc-over-lorawan.md @@ -728,48 +728,29 @@ insightful discussions, reviews and suggestions. Contributors ordered by family name. -- ins: V. Audebert - name: Vincent AUDEBERT - org: EDF R&D - street: 7 bd Gaspard Monge - city: 91120 PALAISEAU - country: FRANCE - email: vincent.audebert@edf.fr -- ins: J. Catalano - name: Julien Catalano - org: Kerlink - street: 1 rue Jacqueline Auriol - city: 35235 Thorigné-Fouillard - country: France - email: j.catalano@kerlink.fr -- ins: M. Coracin - name: Michael Coracin - org: Semtech - street: 14 Chemin des Clos - city: Meylan - country: France - email: mcoracin@semtech.com -- ins: M. Le Gourrierec - name: Marc Le Gourrierec - org: SagemCom - street: 250 Route de l'Empereur - city: 92500 Rueil Malmaison - country: FRANCE - email: marc.legourrierec@sagemcom.com -- ins: N. Sornin - name: Nicolas Sornin - org: Semtech - street: 14 Chemin des Clos - city: Meylan - country: France - email: nsornin@semtech.com -- ins: A. Yegin - name: Alper Yegin - org: Actility - street: . - city: Paris, Paris - country: France - email: alper.yegin@actility.com +Vincent Audebert +EDF R&D +Email: vincent.audebert@edf.fr + +Julien Catalano +Kerlink +Email: j.catalano@kerlink.fr + +Michael Coracin +Semtech +Email: mcoracin@semtech.com + +Marc Le Gourrierec +Sagemcom +Email: marc.legourrierec@sagemcom.com + +Nicolas Sornin +Semtech +Email: nsornin@semtech.com + +Alper Yegin +Actility +Email: alper.yegin@actility.com --- back @@ -959,4 +940,3 @@ The receiver answers with an SCHC ACK ~~~~ {: #Fig-example-downlink-fragmentation title='Downlink example: compression and fragmentation'} -# Note From e6028bec92ff77ff7fd64633e32077f8879560d9 Mon Sep 17 00:00:00 2001 From: Oliv4945 Date: Mon, 11 Nov 2019 11:17:51 +0100 Subject: [PATCH 02/24] IID should follow RFC --- draft-ietf-lpwan-schc-over-lorawan.md | 10 ++++------ 1 file changed, 4 insertions(+), 6 deletions(-) diff --git a/draft-ietf-lpwan-schc-over-lorawan.md b/draft-ietf-lpwan-schc-over-lorawan.md index 0887548..1e7613b 100644 --- a/draft-ietf-lpwan-schc-over-lorawan.md +++ b/draft-ietf-lpwan-schc-over-lorawan.md @@ -37,6 +37,8 @@ normative: RFC7136: RFC3385: RFC4291: + RFC7217: + RFC8064: RFC8376: informative: I-D.ietf-lpwan-ipv6-static-context-hc: @@ -392,12 +394,8 @@ The mechanism for sharing those RuleID values is outside the scope of this docum ## IID computation -As LoRaWAN network uses unique EUI-64 per end-device, the Interface IDentifier is -the LoRaWAN DevEUI. -It is compliant with [RFC4291] and IID starting with binary 000 must enforce -the 64-bit rule. - -TODO: Derive IID from DevEUI with privacy constraints ? Ask working group ? +It is RECOMMENDED to create Interface IDentifier following +{{I-D.ietf-lpwan-ipv6-static-context-hc}}, [rfc7217] and [rfc8064] ## Padding From 09f9e61db2d72189cdb7fd9edb94518dcf6b43f4 Mon Sep 17 00:00:00 2001 From: Oliv4945 Date: Thu, 28 Nov 2019 16:08:48 +0100 Subject: [PATCH 03/24] Propose cryptographic IID --- draft-ietf-lpwan-schc-over-lorawan.md | 44 +++++++++++++++++++++++++-- 1 file changed, 41 insertions(+), 3 deletions(-) diff --git a/draft-ietf-lpwan-schc-over-lorawan.md b/draft-ietf-lpwan-schc-over-lorawan.md index 1e7613b..477a756 100644 --- a/draft-ietf-lpwan-schc-over-lorawan.md +++ b/draft-ietf-lpwan-schc-over-lorawan.md @@ -37,8 +37,8 @@ normative: RFC7136: RFC3385: RFC4291: - RFC7217: RFC8064: + RFC8065: RFC8376: informative: I-D.ietf-lpwan-ipv6-static-context-hc: @@ -110,6 +110,8 @@ all other definitions, please look up the SCHC specification o TBD: all significant LoRaWAN-related terms. + o OUI: Organisation Unique Identifier. IEEE assigned prefix for EUI + # Static Context Header Compression Overview This section contains a short overview of Static Context Header Compression @@ -394,8 +396,44 @@ The mechanism for sharing those RuleID values is outside the scope of this docum ## IID computation -It is RECOMMENDED to create Interface IDentifier following -{{I-D.ietf-lpwan-ipv6-static-context-hc}}, [rfc7217] and [rfc8064] +In order to mitigate risks described in [rfc8064] and [rfc8065] IID MUST be +created regarding the following algorithm: + +1. key = LoRaWAN AppSKey +2. string = devEui in HEX representation, padded to 128 bits by 0 on the left +3. output = aes128_encrypt(key, string) +4. IID = 8 least significant bytes of output + +aes128_encrypt algorithm is the generic algorithm described in IEEE802.15.4/2006 +Annex B [IEEE802154]. It has been chosen as it is 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 +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 +manufacturer OUI to target devices. + +Exemple with: + +* devEui: 0x1122334455667788 +* appSKey: 0x00AABBCCDDEEFF00AABBCCDDEEFFAABB + +~~~~ +1. key: 0x00AABBCCDDEEFF00AABBCCDDEEFFAABB +2. string: 0x00000000000000001122334455667788 +3. output: 0x3532E559FCCD707F9E1364029125B26D +3. IID: 0x9E1364029125B26D +~~~~ + +{: #Fig-iid-computation-example title='Example of IID computation.'} + ## Padding From 597776bc2195f4f86a160c2a9a8c6685a39216af Mon Sep 17 00:00:00 2001 From: Oliv4945 Date: Fri, 29 Nov 2019 08:33:25 +0100 Subject: [PATCH 04/24] Clarify padding --- 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 477a756..99ccccb 100644 --- a/draft-ietf-lpwan-schc-over-lorawan.md +++ b/draft-ietf-lpwan-schc-over-lorawan.md @@ -400,9 +400,10 @@ In order to mitigate risks described in [rfc8064] and [rfc8065] IID MUST be created regarding the following algorithm: 1. key = LoRaWAN AppSKey -2. string = devEui in HEX representation, padded to 128 bits by 0 on the left +2. string = devEui in HEX representation, padded to 128 bits by adding 0 as + most significant bits 3. output = aes128_encrypt(key, string) -4. IID = 8 least significant bytes of output +4. IID = 64 least significant bits of output aes128_encrypt algorithm is the generic algorithm described in IEEE802.15.4/2006 Annex B [IEEE802154]. It has been chosen as it is already used by devices for From ee4cc109c3eca10ecf8cc35ba5e22638d193e95a Mon Sep 17 00:00:00 2001 From: Oliv4945 Date: Tue, 26 Nov 2019 16:00:37 +0100 Subject: [PATCH 05/24] 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 0887548..ab88f68 100644 --- a/draft-ietf-lpwan-schc-over-lorawan.md +++ b/draft-ietf-lpwan-schc-over-lorawan.md @@ -320,7 +320,7 @@ _Note 1_: IPv6 multicast addresses must be defined as per [RFC4291]. LoRaWAN multicast group definition in a network server and the relation between those groups and IPv6 groupID are out of scope of this document. -_Note 2_: LoRa Alliance defined {{lora-alliance-remote-multicast-set}} as +_Note 2_: LoRa Alliance defined {{lora-alliance-remote-multicast-set}} as RECOMMENDED way to setup multicast groups on devices and create a synchronized reception window. @@ -550,7 +550,7 @@ fragment as described in {{lorawan-schc-payload}}. * SCHC fragmentation reliability mode: * Unicast downlinks: ACK-Always. - * Multicast downlinks: No-ACK, reliability has be be ensured by the upper + * 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}}. From d098a61ff051a4f2e049f4c9215efa8422650bd3 Mon Sep 17 00:00:00 2001 From: Oliv4945 Date: Fri, 29 Nov 2019 14:29:24 +0100 Subject: [PATCH 06/24] Dominique editorial review --- draft-ietf-lpwan-schc-over-lorawan.md | 199 +++++++++++++------------- 1 file changed, 100 insertions(+), 99 deletions(-) diff --git a/draft-ietf-lpwan-schc-over-lorawan.md b/draft-ietf-lpwan-schc-over-lorawan.md index ab88f68..f86e3cf 100644 --- a/draft-ietf-lpwan-schc-over-lorawan.md +++ b/draft-ietf-lpwan-schc-over-lorawan.md @@ -114,13 +114,14 @@ 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}}. -Static Context Header Compression (SCHC) avoids context synchronization, based -on the fact that the nature of data flows is highly predictable in LPWAN -networks, some static contexts may be stored on the Device (Dev). The context -MUST be stored in both ends, and it can either be learned by a provisioning -protocol or by out-of-band means or it can be pre-provisioned, etc. The way the -context is learned on both sides is outside the scope of this document. +It defines: +1. Compression mechanisms to avoid transport of known data by both + sender and receiver over the air. Known data are called "context" +2. Fragmentation mechanisms to allow SCHC Packet transportation on small, and + potentially variable, MTU + +Context exchange or pre-provisioning is out of scope of this document. ~~~~ Dev App @@ -198,9 +199,6 @@ and the ones in {{lora-alliance-spec}} is as follows: Radio Gateway and the Internet. This entity maps to the LoRaWAN Network Server. - o LPWAN-AAA Server, which controls the user authentication and the - applications. This entity maps to the LoRaWAN Join Server. - o Application Server (App). The same terminology is used in LoRaWAN. In that case, the application server will be the SCHC gateway, doing C/D and F/R. @@ -258,15 +256,13 @@ Class C. Class B and Class C are mutually exclusive. ## End-Device addressing LoRaWAN end-devices use a 32-bit network address (devAddr) to communicate with -the network over-the-air. However, that address might be reused several times -on the same network at the same time for different end-devices. End-devices using the -same devAddr are distinguished by the Network Server based on the cryptographic -signature appended to every single LoRaWAN MAC frame, as all end-devices use -different security keys. +the network over-the-air, this address might not be unique in a LoRaWAN +network; end-devices using the same devAddr are distinguished by the Network +Server based on the cryptographic signature appended to every LoRaWAN frame. + To communicate with the SCHC gateway the Network Server MUST identify the -end-devices by a unique 64-bit device identifier called the devEUI. Unlike -devAddr, devEUI is guaranteed to be unique for every single end-device across -all networks. +end-devices by a unique 64-bit device identifier called the devEUI. + The devEUI is assigned to the end-device during the manufacturing process by the end-device's manufacturer. It is built like an Ethernet MAC address by concatenating the manufacturer's IEEE OUI field with a vendor unique number. @@ -305,7 +301,10 @@ confirmed messages. 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 +* Data: + Application data frame with two levels of AES-128 encryption. One at + application level thanks to the AppSKey, the other at network level with the + NwkSKey. ## Unicast and multicast technology @@ -332,10 +331,10 @@ The LoRaWAN MAC layer features a frame port field in all frames. This field (FPort) is 8 bits long and the values from 1 to 223 can be used. It allows LoRaWAN networks and applications to identify data. -The FPort field is part of the SCHC Packet or the SCHC Fragment, as shown in +The FPort field is part of the SCHC Message, as shown in {{Fig-lorawan-schc-payload}}. The SCHC C/D and the SCHC F/R SHALL concatenate the FPort field with the LoRaWAN payload to retrieve their payload as it is used -as a part of the ruleId field. +as a part of the RuleID field. ~~~~ @@ -344,7 +343,7 @@ as a part of the ruleId field. | SCHC payload | ~~~~ -{: #Fig-lorawan-schc-payload title='SCHC payload in LoRaWAN'} +{: #Fig-lorawan-schc-payload title='SCHC Message in LoRaWAN'} A fragmentation session with application payload transferred from device to server, is called uplink fragmentation session. It uses an FPort for data uplink @@ -376,13 +375,13 @@ rule was found) The remaining RuleIDs are available for compression. RuleIDs are shared between uplink and downlink sessions. A RuleID different from FPortUp or FPortDown -means that the fragmentation is not used, thus the packet SHOULD be sent to C/D -layer. +means that the fragmentation is not used, thus, on reception, the SCHC Message +MUST be sent to the C/D layer. The only uplink messages using the FPortDown port are the fragmentation SCHC -control messages of a downlink fragmentation session (ex ACKs). Similarly, the -only downlink messages using the FPortUp port are the fragmentation SCHC -control messages of an uplink fragmentation session. +control messages of a downlink fragmentation session (for example, SCHC ACKs). +Similarly, the only downlink messages using the FPortUp port are the +fragmentation SCHC control messages of an uplink fragmentation session. An application can have multiple fragmentation sessions between a device and one or several SCHC gateways. A set of FPort values is REQUIRED for each SCHC gateway @@ -403,22 +402,20 @@ TODO: Derive IID from DevEUI with privacy constraints ? Ask working group ? All padding bits MUST be 0. -## Compression {#Comp} +## Decompression {#Decomp} -SCHC C/D MUST concatenate FPort and LoRaWAN payload to retrieve the SCHC packet +SCHC C/D MUST concatenate FPort and LoRaWAN payload to retrieve the SCHC Packet as per {{lorawan-schc-payload}}. RuleIDs matching FPortUp and FPortDown are reserved for SCHC Fragmentation. ## Fragmentation {#Frag} -The L2 word size used by LoRaWAN is 1 byte (8 bits). -The SCHC fragmentation over LoRaWAN uses the ACK-on-Error for uplink -fragmentation and Ack-Always for downlink fragmentation. A LoRaWAN end-device -cannot support simultaneous interleaved fragmentation sessions in the same -direction (uplink or downlink). This means that only a single fragmented -IPv6 datagram may be transmitted and/or received by the end-device at a given -moment. +The L2 Word Size used by LoRaWAN is 1 byte (8 bits). +The SCHC fragmentation over LoRaWAN uses the ACK-on-Error mode for uplink +fragmentation and Ack-Always mode for downlink fragmentation. A LoRaWAN +end-device cannot support simultaneous interleaved fragmentation sessions in +the same direction (uplink or downlink). The fragmentation parameters are different for uplink and downlink fragmentation sessions and are successively described in the next sections. @@ -436,7 +433,7 @@ or more SCHC gateway(s) thanks to distinct sets of FPorts, cf {{rule-id-manageme In that case the device is the fragmentation transmitter, and the SCHC gateway the fragmentation receiver. A single fragmentation rule is defined. SCHC F/R MUST concatenate FPort and LoRaWAN payload to retrieve the SCHC -fragment as per {{lorawan-schc-payload}}. +Message, as per {{lorawan-schc-payload}}. * SCHC header size is two bytes (the FPort byte + 1 additional byte). * RuleID: 8 bits stored in LoRaWAN FPort. @@ -504,10 +501,10 @@ LoRaWAN payload. MTU is: _4 windows * 63 tiles * 10 bytes per tile = 2520 bytes_ + ------ + ----------------------------------------- + | RuleID | W | C | Encoded bitmap (if C = 0) | + ------ + ----- + ----- + ------------------------- + -| 8 bits | 2 bit | 1 bit | 0 to 127 bits | +| 8 bits | 2 bit | 1 bit | 0 to 63 bits | ~~~~ -{: #Fig-fragmentation-header-long-schc-ack title='SCHC formats, failed RCS check.'} +{: #Fig-fragmentation-header-long-schc-ack title='SCHC ACK format, failed RCS check.'} #### Receiver-Abort @@ -594,7 +591,7 @@ purposes but not SCHC needs. | 8 bits | 1 bit | 1 bit | 32 bits | Last tile, if any | ~~~~ -{: #Fig-fragmentation-downlink-header-all1 title='All-1 SCHC ACK detailed format for the last fragment.'} +{: #Fig-fragmentation-downlink-header-all1 title='All-1 SCHC Message: the last fragment.'} #### SCHC acknowledge @@ -623,7 +620,7 @@ purposes but not SCHC needs. ~~~~ -{: #Fig-fragmentation-downlink-header-abort title='Receiver-Abort packet (following an all-1 packet with incorrect RCS).'} +{: #Fig-fragmentation-downlink-header-abort title='Receiver-Abort packet (following an All-1 SCHC Fragment with incorrect RCS).'} Class A and Class B or Class C end-devices do not manage retransmissions and @@ -639,7 +636,7 @@ end-device. The device replies with an ACK message to every single fragment received from the SCHC gateway (because the window size is 1). Following the reception of a FCN=0 fragment (fragment that is not the last fragment of the packet or -ACK-request, but the end of a window), the device MUST transmit the SCHC ACK +SCHC ACK REQ, but the end of a window), the device MUST transmit the SCHC ACK fragment until it receives the fragment of the next window. The device SHALL transmit up to MAX_ACK_REQUESTS ACK messages before aborting. The device should transmit those ACK as soon as possible while taking into consideration @@ -652,13 +649,13 @@ the "RCS is correct" indicator bit set (C=1). This message might be lost therefore the SCHC gateway MAY request a retransmission of this ACK in the next downlink. The device SHALL keep this ACK message in memory until it receives a downlink, on SCHC FPortDown from the SCHC gateway different from an -ACK-request: it indicates that the SCHC gateway has received the ACK message. +SCHC ACK REQ: it indicates that the SCHC gateway has received the ACK message. Following the reception of a FCN=All-1 fragment (the last fragment of a datagram), if all fragments have been received and the RCS is not correct, the device SHALL transmit a Receiver-Abort fragment. The device SHALL keep this Abort message in memory until it receives a downlink, on SCHC FPortDown, -from the SCHC gateway different from an ACK-request indicating that the SCHC +from the SCHC gateway different from an SCHC ACK REQ indicating that the SCHC gateway has received the Abort message. The fragmentation receiver (device) does not implement retransmission timer and inactivity timer. @@ -677,7 +674,7 @@ Class B and Class C end-devices can receive in scheduled RX slots or in RX slots following the transmission of an uplink. The device replies with an ACK message to every single fragment received from the SCHC gateway (because the window size is 1). Following the reception of an FCN=0 fragment (fragment that -is not the last fragment of the packet or ACK-request), the device MUST always +is not the last fragment of the packet or SCHC ACK REQ), the device MUST always transmit the corresponding SCHC ACK message even if that fragment has already been received. The ACK bitmap is 1 bit long and is always 1. If the SCHC gateway receives this @@ -692,7 +689,7 @@ datagram) and if the RCS is correct, the device SHALL transmit the ACK with the current fragmentation session has succeeded and its context can be cleared. If the retransmission timer elapses and the SCHC gateway has not received the -SCHC ACK it retransmits the last fragment with the payload (not an ACK-request +SCHC ACK it retransmits the last fragment with the payload (not an SCHC ACK REQ without payload). The SCHC gateway tries retransmitting up to MAX_ACK_REQUESTS times before aborting. @@ -706,8 +703,8 @@ Class B ping slots. The RECOMMENDED value is equal to 3 times the Class B ping slot periodicity. For Class C end-devices which are nearly constantly receiving, the RECOMMENDED value is 30 seconds. This means that the end-device shall try to transmit the ACK within 30 seconds of the reception of each fragment. The -inactivity timer is implemented by the end-device to flush the context in-case it -receives nothing from the SCHC gateway over an extended period of time. The +inactivity timer is implemented by the end-device to flush the context in case +it receives nothing from the SCHC gateway over an extended period of time. The RECOMMENDED value is 12 hours for both Class B and Class C end-devices. # Security considerations @@ -776,26 +773,26 @@ Contributors ordered by family name. # Examples ## Uplink - Compression example - No fragmentation -{{Fig-example-uplink-no-fragmentation}} is representing an applicative payload -going through SCHC, no fragmentation required +{{Fig-example-uplink-no-fragmentation}} represents an applicative payload +going through SCHC over LoRaWAN, no fragmentation required ~~~~ An applicative payload of 78 bytes is passed to SCHC compression layer using rule 1, allowing to compress it to 40 bytes and 5 bits: 1 byte -ruleID, 21 bits residue + 37 bytes payload. - +RuleID, 21 bits residue + 37 bytes payload. +SCHC Message: | RuleID | Compression residue | Payload | Padding=b'000 | + ------ + ------------------- + --------- + ------------- + -| 1 | 21 bits | 38 bytes | 3 bits | +| 1 | 21 bits | 37 bytes | 3 bits | The current LoRaWAN MTU is 51 bytes, although 2 bytes FOpts are used by LoRaWAN protocol: 49 bytes are available for SCHC payload; no need for fragmentation. The payload will be transmitted through FPort = 1 - +LoRaWAN packet: | LoRaWAN Header | LoRaWAN payload (40 bytes) | + ------------------------- + --------------------------------------- + | | FOpts | RuleID=1 | Compression | Payload | Padding=b'000 | @@ -808,16 +805,16 @@ fragmentation. The payload will be transmitted through FPort = 1 ## Uplink - Compression and fragmentation example -{{Fig-example-uplink-fragmentation-long}} is representing an applicative payload +{{Fig-example-uplink-fragmentation-long}} represents an applicative payload going through SCHC, with fragmentation. ~~~~ An applicative payload of 478 bytes is passed to SCHC compression layer using rule 1, allowing to compress it to 282 bytes and 5 bits: 1 byte -ruleID, 21 bits residue + 279 bytes payload. - +RuleID, 21 bits residue + 279 bytes payload. +SCHC Message: | RuleID | Compression residue | Payload | + ------ + ------------------- + --------- + | 1 | 21 bits | 279 bytes | @@ -828,6 +825,7 @@ protocol: 11 bytes are available for SCHC payload + 1 byte FPort field. SCHC header is 2 bytes (including FPort) so 1 tile is sent in first fragment. +LoRaWAN message, containing SCHC Fragment: | LoRaWAN Header | LoRaWAN payload (11 bytes) | + -------------------------- + -------------------------- + | | RuleID=20 | W | FCN | 1 tile | @@ -847,6 +845,7 @@ field, a tile does not fit inside so LoRaWAN stack will send only FOpts. Next transmission MTU is 242 bytes, 4 bytes FOpts. 23 tiles are transmitted: +LoRaWAN message, containing SCHC Fragment: | LoRaWAN Header | LoRaWAN payload (231 bytes) | + --------------------------------------+ --------------------------- + | | FOpts | RuleID=20 | W | FCN | 23 tiles | @@ -858,16 +857,18 @@ Next transmission MTU is 242 bytes, no FOpts. All 5 remaining tiles are transmitted, the last tile is only 2 bytes + 5 bits. Padding is added for the remaining 3 bits. -| LoRaWAN Header | LoRaWAN payload (44 bytes) | -+ ---- + -----------+ ----------------------------------------------- + -| | RuleID=20 | W | FCN | 5 tiles | Padding=b'000 | -+ ---- + ---------- + ----- + ----- + ----------------- + ------------- + -| XXXX | 1 byte | 0 0 | 38 | 42 bytes + 5 bits | 3 bits | +LoRaWAN message, containing All-1 SCHC Fragment: +| LoRaWAN Header | LoRaWAN payload (44 bytes) | ++ ---- + -----------+ ----------------------------------------------------------- + +| | RuleID=20 | W | FCN | RCS | 5 tiles | Padding=b'000 | ++ ---- + ---------- + ----- + ----- + ------- + ----------------- + ------------- + +| XXXX | 1 byte | 0 0 | 63 | 4 bytes | 42 bytes + 5 bits | 3 bits | All packets have been received by the SCHC gateway, computed RCS is correct so the following ACK is sent to the device: +LoRaWAN message, containing SCHC ACK: | LoRaWAN Header | LoRaWAN payload | + -------------- + --------- + ------------------- + | | RuleID=20 | W | C | Padding | @@ -884,77 +885,77 @@ correct so the following ACK is sent to the device: An applicative payload of 443 bytes is passed to SCHC compression layer using rule 1, allowing to compress it to 130 bytes and 5 bits: 1 byte -ruleId, 21 bits residue + 127 bytes payload. - +RuleID, 21 bits residue + 127 bytes payload. +SCHC Packet: | RuleID | Compression residue | Payload | + ------ + ------------------- + --------- + | 1 | 21 bits | 127 bytes | The current LoRaWAN MTU is 51 bytes, no FOpts are used by LoRaWAN -protocol: 48 bytes are available for SCHC payload + FPort field => it +protocol: 51 bytes are available for SCHC payload + FPort field => it has to be fragmented. - -| LoRaWAN Header | LoRaWAN payload (51 bytes) | -+ ---- + ---------- + --------------------------------------------- + -| | RuleID=21 | W | FCN | 1 tile | Padding=b'000000 | -+ ---- + ---------- + --- + --- + -------------- + ---------------- + -| XXXX | 1 byte | 0 | 0 | 50 bytes | 6 bits | +LoRaWAN message, containing SCHC Fragment: +| LoRaWAN Header | LoRaWAN payload (51 bytes) | ++ ---- + ---------- + -------------------------------------- + +| | RuleID=21 | W = 0 | FCN = 0 | 1 tile | ++ ---- + ---------- + ------ + ------- + ------------------- + +| XXXX | 1 byte | 1 bit | 1 bit | 50 bytes and 6 bits | Content of the tile is: | RuleID | Compression residue | Payload | + ------ + ------------------- + ------------------ + -| 1 | 21 bits | 46 bytes + 3 bits | +| 1 | 21 bits | 48 bytes and 1 bit | -The receiver answers with an SCHC ACK +The receiver answers with a SCHC ACK -| FPortDown | LoRaWAN payload | -+ --------- + ---------------------------------- + -| RuleID | W = 0 | C = b'1 | Padding=b'000000 | -+ --------- + ----- + ------- + ---------------- + -| 1 byte | 1 bit | 1 bit | 6 bits | +| LoRaWAN Header | LoRaWAN payload | ++ ---- + --------- + -------------------------------- + +| | RuleID=21 | W = 0 | C = 1 | Padding=b'000000 | ++ ---- + --------- + ----- + ----- + ---------------- + +| XXXX | 1 byte | 1 bit | 1 bit | 6 bits | The second downlink is sent, two FOpts: - -| LoRaWAN Header | LoRaWAN payload (49 bytes) | -+ --------------------------- + ------------------ + ---------------- + -| | FOpts | RuleID=21 | W | FCN | 1 tile | Padding=b'000000 | -+ ---- + ------- + ---------- + - + --- + -------- + ---------------- + -| XXXX | 2 bytes | 1 byte | 1 | 0 | 48 bytes | 6 bits | +LoRaWAN message, containing SCHC Fragment: +| LoRaWAN Header | LoRaWAN payload (49 bytes) | ++ --------------------------- + ------------------------------------- + +| | FOpts | RuleID=21 | W = 1 | FCN = 0 | 1 tile | ++ ---- + ------- + ---------- + ----- + ------- + ------------------- + +| XXXX | 2 bytes | 1 byte | 1 bit | 1 bit | 48 bytes and 6 bits | The receiver answers with an SCHC ACK -| FPortDown | LoRaWAN payload | -+ --------- + ---------------------------------- + -| RuleID | W = 1 | C = b'1 | Padding=b'000000 | -+ --------- + ----- + ------- + ---------------- + -| 1 byte | 1 bit | 1 bit | 6 bits | +| LoRaWAN Header | LoRaWAN payload | ++ ---- + --------- + -------------------------------- + +| | RuleID=21 | W = 1 | C = 1 | Padding=b'000000 | ++ ---- + --------- + ----- + ----- + ---------------- + +| XXXX | 1 byte | 1 bit | 1 bit | 6 bits | The last downlink is sent, no FOpts: - -| LoRaWAN Header | LoRaWAN payload (33 bytes) | -+ ---- + ---------- + ----------------------------------------------- + -| | RuleID=21 | W | FCN | 1 tile | Padding=b'0 | -+ ---- + ---------- + --- + --- + --------------------- + ----------- + -| XXXX | 1 byte | 0 | 1 | 32 bytes + 5 bits | 1 bit | +LoRaWAN message, containing All-1 SCHC Fragment: +| LoRaWAN Header | LoRaWAN payload (33 bytes) | ++ ---- + --------- + ------------------------------------------------------- + +| | RuleID=21 | W = 0 | FCN = 1 | 1 tile | Padding=b'00000 | ++ ---- + --------- + ------- + ------- + ----------------- + --------------- + +| XXXX | 1 byte | 1 bit | 1 bit | 31 bytes + 1 bits | 5 bits | The receiver answers with an SCHC ACK -| FPortDown | LoRaWAN payload | -+ --------- + ---------------------------------- + -| RuleID | W = 0 | C = b'1 | Padding=b'000000 | -+ --------- + ----- + ------- + ---------------- + -| 1 byte | 1 bit | 1 bit | 6 bits | +| LoRaWAN Header | LoRaWAN payload | ++ ---- + --------- + -------------------------------- + +| | RuleID=21 | W = 0 | C = 1 | Padding=b'000000 | ++ ---- + --------- + ----- + ----- + ---------------- + +| XXXX | 1 byte | 1 bit | 1 bit | 6 bits | ~~~~ {: #Fig-example-downlink-fragmentation title='Downlink example: compression and fragmentation'} From 8236aa5e6f0d0505f048bc48d819e7742808162f Mon Sep 17 00:00:00 2001 From: Oliv4945 Date: Fri, 29 Nov 2019 15:10:46 +0100 Subject: [PATCH 07/24] Dominique significant comments review --- draft-ietf-lpwan-schc-over-lorawan.md | 34 ++++++++++++--------------- 1 file changed, 15 insertions(+), 19 deletions(-) diff --git a/draft-ietf-lpwan-schc-over-lorawan.md b/draft-ietf-lpwan-schc-over-lorawan.md index f86e3cf..035f56c 100644 --- a/draft-ietf-lpwan-schc-over-lorawan.md +++ b/draft-ietf-lpwan-schc-over-lorawan.md @@ -312,7 +312,7 @@ LoRaWAN technology supports unicast downlinks, but also multicast: a packet send over LoRaWAN radio link can be received by several devices. It is useful to address many end-devices with same content, either a large binary file (firmware upgrade), or same command (e.g: lighting control). -As IPv6 is also a multicast technology this feature MAY be used to address a +As IPv6 is also a multicast technology this feature can be used to address a group of devices. _Note 1_: IPv6 multicast addresses must be defined as per [RFC4291]. LoRaWAN @@ -353,9 +353,10 @@ server to device, is called downlink fragmentation session. It uses another FPort for data downlink and its associated SCHC control uplinks, named FPortDown in this document. -FPorts can use arbitrary values inside the allowed FPort range and MUST be -shared by the end-device, the Network Server and SCHC gateway prior to the -communication. The uplink and downlink fragmentation FPorts MUST be different. +FPorts can use arbitrary values inside the FPort range allowed by LoRaWAN and +MUST be shared by the end-device, the Network Server and SCHC gateway prior to +the communication. The uplink and downlink fragmentation FPorts MUST be +different. ## Rule ID management {#rule-id-management} @@ -442,20 +443,17 @@ Message, 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 calculation algorithm: CRC32 using 0xEDB88320 (i.e. the reverse - representation of the polynomial used e.g. in the Ethernet standard - [RFC3385]) as suggested in {{I-D.ietf-lpwan-ipv6-static-context-hc}}. +* RCS: Use recommended calculation algorithm in {{I-D.ietf-lpwan-ipv6-static-context-hc}}. * MAX_ACK_REQUESTS: 8 * Tile: size is 10 bytes * Retransmission and inactivity timers: - LoRaWAN end-devices do not implement a "retransmission timer". At the end of + LoRaWAN end-devices MUST not implement a "retransmission timer". At the end of a window or a fragmentation session, corresponding ACK(s) is (are) transmitted by the network gateway (LoRaWAN application server) in the RX1 or RX2 receive slot of end-device. If this ACK is not received by the end-device at the end of its RX windows, - it sends an all-0 (or an all-1) fragment with no payload to request an SCHC - ACK retransmission. The periodicity between retransmission of the all-0/all-1 - fragments is device/application specific and MAY be different for each device + it sends an SCHC ACK REQ. The periodicity between retransmission of SCHC ACK + REQs is device/application specific and MAY be different for each device (not specified). 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 @@ -554,9 +552,7 @@ fragment as described in {{lorawan-schc-payload}}. * 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 calculation algorithm: CRC32 using 0xEDB88320 (i.e. the reverse - representation of the polynomial used e.g. in the Ethernet standard - [RFC3385]), as per {{I-D.ietf-lpwan-ipv6-static-context-hc}}. +* RCS: Use recommended calculation algorithm in {{I-D.ietf-lpwan-ipv6-static-context-hc}}. * MAX_ACK_REQUESTS: 8 As only 1 tile is used, its size can change for each downlink, and will be @@ -570,11 +566,11 @@ purposes but not SCHC needs. ~~~~ -| FPort | LoRaWAN payload | -+ ------ + ----------------------------------- + -| RuleID | W | FCN = b'0 | Payload | -+ ------ + ----- + --------- + --------------- + -| 8 bits | 1 bit | 1 bit | X bytes | +| FPort | LoRaWAN payload | ++ ------ + ------------------------------------ + +| RuleID | W | FCN = b'0 | Payload | ++ ------ + ----- + --------- + ---------------- + +| 8 bits | 1 bit | 1 bit | X bytes + 6 bits | ~~~~ {: #Fig-fragmentation-downlink-header-all0 title='All fragments but the last one. Header size 10 bits, including LoraWAN FPort.'} From cd3aca3f6662a593364401ff4111efc078760928 Mon Sep 17 00:00:00 2001 From: Oliv4945 Date: Fri, 29 Nov 2019 16:02:17 +0100 Subject: [PATCH 08/24] typo --- 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 99ccccb..990ab2b 100644 --- a/draft-ietf-lpwan-schc-over-lorawan.md +++ b/draft-ietf-lpwan-schc-over-lorawan.md @@ -400,7 +400,7 @@ In order to mitigate risks described in [rfc8064] and [rfc8065] IID MUST be created regarding the following algorithm: 1. key = LoRaWAN AppSKey -2. string = devEui in HEX representation, padded to 128 bits by adding 0 as +2. string = devEui in HEX representation, padded to 128 bits by adding 0s as most significant bits 3. output = aes128_encrypt(key, string) 4. IID = 64 least significant bits of output From 43960f6c95b29c2b8d5136d94f78686637bf60ab Mon Sep 17 00:00:00 2001 From: Oliv4945 Date: Mon, 2 Dec 2019 11:24:36 +0100 Subject: [PATCH 09/24] Lasts comments from Dominique --- draft-ietf-lpwan-schc-over-lorawan.md | 69 +++++++++++++++------------ 1 file changed, 39 insertions(+), 30 deletions(-) diff --git a/draft-ietf-lpwan-schc-over-lorawan.md b/draft-ietf-lpwan-schc-over-lorawan.md index 035f56c..f59a4cd 100644 --- a/draft-ietf-lpwan-schc-over-lorawan.md +++ b/draft-ietf-lpwan-schc-over-lorawan.md @@ -46,7 +46,6 @@ informative: name: LoRa Alliance date: 07.2018 target: https://lora-alliance.org/sites/default/files/2018-07/lorawan1.0.3.pdf - I-D.ietf-lpwan-ipv6-static-context-hc: lora-alliance-remote-multicast-set: title: LoRaWAN Remote Multicast Setup Specification Version 1.0.0 author: @@ -363,9 +362,8 @@ different. 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 MAY reserve some -FPort values for other needs as long as they don't conflict with FPorts used -for SCHC C/D and SCHC F/R. +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. In order to improve interoperability RECOMMENDED fragmentation RuleID values are: @@ -434,7 +432,7 @@ or more SCHC gateway(s) thanks to distinct sets of FPorts, cf {{rule-id-manageme In that case the device is the fragmentation transmitter, and the SCHC gateway the fragmentation receiver. A single fragmentation rule is defined. SCHC F/R MUST concatenate FPort and LoRaWAN payload to retrieve the SCHC -Message, as per {{lorawan-schc-payload}}. +Packet, as per {{lorawan-schc-payload}}. * SCHC header size is two bytes (the FPort byte + 1 additional byte). * RuleID: 8 bits stored in LoRaWAN FPort. @@ -447,7 +445,9 @@ Message, as per {{lorawan-schc-payload}}. * MAX_ACK_REQUESTS: 8 * Tile: size is 10 bytes * Retransmission and inactivity timers: - LoRaWAN end-devices MUST not implement a "retransmission timer". At the end of + 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}}. At the end of a window or a fragmentation session, corresponding ACK(s) is (are) transmitted by the network gateway (LoRaWAN application server) in the RX1 or RX2 receive slot of end-device. @@ -458,7 +458,7 @@ Message, as per {{lorawan-schc-payload}}. 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 can be carried in the All-1 fragment. +* Last tile: The last tile MUST NOT be carried in the All-1 fragment. 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 @@ -482,11 +482,11 @@ LoRaWAN payload. MTU is: _4 windows * 63 tiles * 10 bytes per tile = 2520 bytes_ ~~~~ -| FPort | LoRaWAN payload | -+ ------ + ------------------------------------------------ + -| RuleID | W | FCN=All-1 | RCS | Payload | -+ ------ + ------ + --------- + ------- + ----------------- + -| 8 bits | 2 bits | 6 bits | 32 bits | Last tile, if any | +| FPort | LoRaWAN payload | ++ ------ + ---------------------------- + +| RuleID | W | FCN=All-1 | RCS | ++ ------ + ------ + --------- + ------- + +| 8 bits | 2 bits | 6 bits | 32 bits | ~~~~ {: #Fig-fragmentation-header-all1 title='All-1 fragment detailed format for the last fragment.'} @@ -541,7 +541,7 @@ LoRaWAN payload. MTU is: _4 windows * 63 tiles * 10 bytes per tile = 2520 bytes_ In that case the device is the fragmentation receiver, and the SCHC gateway the fragmentation transmitter. The following fields are common to all devices. SCHC F/R MUST concatenate FPort and LoRaWAN payload to retrieve the SCHC -fragment as described in {{lorawan-schc-payload}}. +Packet as described in {{lorawan-schc-payload}}. * SCHC fragmentation reliability mode: * Unicast downlinks: ACK-Always. @@ -580,11 +580,11 @@ purposes but not SCHC needs. ~~~~ -| FPort | LoRaWAN payload | -+ ------ + ----------------------------------------------- + -| RuleID | W | FCN = b'1 | RCS | Payload | -+ ------ + ----- + --------- + ------- + ----------------- + -| 8 bits | 1 bit | 1 bit | 32 bits | Last tile, if any | +| FPort | LoRaWAN payload | ++ ------ + --------------------------- + +| RuleID | W | FCN = b'1 | RCS | ++ ------ + ----- + --------- + ------- + +| 8 bits | 1 bit | 1 bit | 32 bits | ~~~~ {: #Fig-fragmentation-downlink-header-all1 title='All-1 SCHC Message: the last fragment.'} @@ -622,7 +622,7 @@ purposes but not SCHC needs. Class A and Class B or Class C end-devices do not manage retransmissions and timers in the same way. -#### Class A end-devices +#### Class A end-devices {#uplink-class-a} Class A end-devices can only receive in an RX slot following the transmission of an uplink. Therefore there cannot be a concept of "retransmission timer" for an @@ -774,8 +774,8 @@ going through SCHC over LoRaWAN, no fragmentation required ~~~~ -An applicative payload of 78 bytes is passed to SCHC compression layer -using rule 1, allowing to compress it to 40 bytes and 5 bits: 1 byte +An applicative payload of 78 bytes is passed to SCHC compression layer. Rule 1 +is used by C/D layer, allowing to compress it to 40 bytes and 5 bits: 1 byte RuleID, 21 bits residue + 37 bytes payload. SCHC Message: @@ -806,8 +806,8 @@ going through SCHC, with fragmentation. ~~~~ -An applicative payload of 478 bytes is passed to SCHC compression layer -using rule 1, allowing to compress it to 282 bytes and 5 bits: 1 byte +An applicative payload of 478 bytes is passed to SCHC compression layer. Rule 1 +is used by C/D layer, allowing to compress it to 282 bytes and 5 bits: 1 byte RuleID, 21 bits residue + 279 bytes payload. SCHC Message: @@ -853,12 +853,21 @@ Next transmission MTU is 242 bytes, no FOpts. All 5 remaining tiles are transmitted, the last tile is only 2 bytes + 5 bits. Padding is added for the remaining 3 bits. +LoRaWAN message, containing last tile: +| LoRaWAN Header | LoRaWAN payload (44 bytes) | ++ ---- + -----------+ ------------------------------------------------- + +| | RuleID=20 | W | FCN | 5 tiles | Padding=b'000 | ++ ---- + ---------- + ----- + ----- + ----------------- + ------------- + +| XXXX | 1 byte | 0 0 | 38 | 42 bytes + 5 bits | 3 bits | + + +Then All-1 message can be transmitted: LoRaWAN message, containing All-1 SCHC Fragment: -| LoRaWAN Header | LoRaWAN payload (44 bytes) | -+ ---- + -----------+ ----------------------------------------------------------- + -| | RuleID=20 | W | FCN | RCS | 5 tiles | Padding=b'000 | -+ ---- + ---------- + ----- + ----- + ------- + ----------------- + ------------- + -| XXXX | 1 byte | 0 0 | 63 | 4 bytes | 42 bytes + 5 bits | 3 bits | +| LoRaWAN Header | LoRaWAN payload (44 bytes) | ++ ---- + -----------+ -------------------------- + +| | RuleID=20 | W | FCN | RCS | ++ ---- + ---------- + ----- + ----- + ---------- + +| XXXX | 1 byte | 0 0 | 63 | 4 bytes | All packets have been received by the SCHC gateway, computed RCS is @@ -879,8 +888,8 @@ LoRaWAN message, containing SCHC ACK: ~~~~ -An applicative payload of 443 bytes is passed to SCHC compression layer -using rule 1, allowing to compress it to 130 bytes and 5 bits: 1 byte +An applicative payload of 443 bytes is passed to SCHC compression layer. Rule 1 +is used by C/D layer, allowing to compress it to 130 bytes and 5 bits: 1 byte RuleID, 21 bits residue + 127 bytes payload. SCHC Packet: From abb0e6961af294ccb3ff9641b2c9902df40ae681 Mon Sep 17 00:00:00 2001 From: Oliv4945 Date: Mon, 2 Dec 2019 11:26:43 +0100 Subject: [PATCH 10/24] Remove nonexistant case --- draft-ietf-lpwan-schc-over-lorawan.md | 8 -------- 1 file changed, 8 deletions(-) diff --git a/draft-ietf-lpwan-schc-over-lorawan.md b/draft-ietf-lpwan-schc-over-lorawan.md index f59a4cd..60a7134 100644 --- a/draft-ietf-lpwan-schc-over-lorawan.md +++ b/draft-ietf-lpwan-schc-over-lorawan.md @@ -647,14 +647,6 @@ downlink. The device SHALL keep this ACK message in memory until it receives a downlink, on SCHC FPortDown from the SCHC gateway different from an SCHC ACK REQ: it indicates that the SCHC gateway has received the ACK message. -Following the reception of a FCN=All-1 fragment (the last fragment of a -datagram), if all fragments have been received and the RCS is not correct, -the device SHALL transmit a Receiver-Abort fragment. The device SHALL keep -this Abort message in memory until it receives a downlink, on SCHC FPortDown, -from the SCHC gateway different from an SCHC ACK REQ indicating that the SCHC -gateway has received the Abort message. The fragmentation receiver (device) -does not implement retransmission timer and inactivity timer. - The fragmentation sender (the SCHC gateway) implements an inactivity timer with a default duration of 12 hours. Once a fragmentation session is started, if the SCHC gateway has not received any ACK or Receiver-Abort message 12 hours after From 445ced6d52b4846b763a48969d483fa3643b5602 Mon Sep 17 00:00:00 2001 From: Oliv4945 Date: Thu, 12 Dec 2019 09:11:53 +0100 Subject: [PATCH 11/24] Add penultimage size for Ack-On-Error mode --- draft-ietf-lpwan-schc-over-lorawan.md | 1 + 1 file changed, 1 insertion(+) diff --git a/draft-ietf-lpwan-schc-over-lorawan.md b/draft-ietf-lpwan-schc-over-lorawan.md index 60a7134..dea8013 100644 --- a/draft-ietf-lpwan-schc-over-lorawan.md +++ b/draft-ietf-lpwan-schc-over-lorawan.md @@ -459,6 +459,7 @@ Packet, as per {{lorawan-schc-payload}}. 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. 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 61e8549ae2528bd0dd6f174aa76755684631bb61 Mon Sep 17 00:00:00 2001 From: Oliv4945 Date: Thu, 12 Dec 2019 10:11:10 +0100 Subject: [PATCH 12/24] Split example in text+figures --- draft-ietf-lpwan-schc-over-lorawan.md | 117 ++++++++++++++------------ 1 file changed, 64 insertions(+), 53 deletions(-) diff --git a/draft-ietf-lpwan-schc-over-lorawan.md b/draft-ietf-lpwan-schc-over-lorawan.md index dea8013..900e95a 100644 --- a/draft-ietf-lpwan-schc-over-lorawan.md +++ b/draft-ietf-lpwan-schc-over-lorawan.md @@ -762,71 +762,71 @@ Contributors ordered by family name. # Examples ## Uplink - Compression example - No fragmentation -{{Fig-example-uplink-no-fragmentation}} represents an applicative payload -going through SCHC over LoRaWAN, no fragmentation required - -~~~~ +This example represents an applicative payload going through SCHC over LoRaWAN, +no fragmentation required An applicative payload of 78 bytes is passed to SCHC compression layer. Rule 1 is used by C/D layer, allowing to compress it to 40 bytes and 5 bits: 1 byte RuleID, 21 bits residue + 37 bytes payload. -SCHC Message: +~~~~ | RuleID | Compression residue | Payload | Padding=b'000 | + ------ + ------------------- + --------- + ------------- + | 1 | 21 bits | 37 bytes | 3 bits | - +~~~~ +{: #Fig-example-uplink-no-fragmentation-payload-schc-message title='Uplink example: SCHC Message'} The current LoRaWAN MTU is 51 bytes, although 2 bytes FOpts are used by LoRaWAN protocol: 49 bytes are available for SCHC payload; no need for -fragmentation. The payload will be transmitted through FPort = 1 +fragmentation. The payload will be transmitted through FPort = 1. -LoRaWAN packet: +~~~~ | LoRaWAN Header | LoRaWAN payload (40 bytes) | + ------------------------- + --------------------------------------- + | | FOpts | RuleID=1 | Compression | Payload | Padding=b'000 | | | | | residue | | | + ---- + ------- + -------- + ----------- + --------- + ------------- + | XXXX | 2 bytes | 1 byte | 21 bits | 37 bytes | 3 bits | - ~~~~ -{: #Fig-example-uplink-no-fragmentation title='Uplink example: compression without fragmentation'} +{: #Fig-example-uplink-no-fragmentation-compression title='Uplink example: LoRaWAN packet'} ## Uplink - Compression and fragmentation example -{{Fig-example-uplink-fragmentation-long}} represents an applicative payload -going through SCHC, with fragmentation. - -~~~~ +This example represents an applicative payload going through SCHC, with +fragmentation. An applicative payload of 478 bytes is passed to SCHC compression layer. Rule 1 is used by C/D layer, allowing to compress it to 282 bytes and 5 bits: 1 byte RuleID, 21 bits residue + 279 bytes payload. -SCHC Message: +~~~~ | RuleID | Compression residue | Payload | + ------ + ------------------- + --------- + | 1 | 21 bits | 279 bytes | - +~~~~ +{: #Fig-example-uplink-fragmentation-schc-message title='Uplink example: SCHC Message'} The current LoRaWAN MTU is 11 bytes, 0 bytes FOpts are used by LoRaWAN protocol: 11 bytes are available for SCHC payload + 1 byte FPort field. SCHC header is 2 bytes (including FPort) so 1 tile is sent in first fragment. -LoRaWAN message, containing SCHC Fragment: +~~~~ | LoRaWAN Header | LoRaWAN payload (11 bytes) | + -------------------------- + -------------------------- + | | RuleID=20 | W | FCN | 1 tile | + -------------- + --------- + ----- + ------ + --------- + | XXXX | 1 byte | 0 0 | 62 | 10 bytes | +~~~~ +{: #Fig-example-uplink-fragmentation-lorawan-packet-1 title='Uplink example: LoRaWAN packet 1'} - +~~~~ Content of the tile is: | RuleID | Compression residue | Payload | + ------ + ------------------- + ----------------- + | 1 | 21 bits | 6 byte + 3 bits | - +~~~~ +{: #Fig-example-uplink-fragmentation-lorawan-packet-1-tile-content title='Uplink example: LoRaWAN packet 1 - Tile content'} Next transmission MTU is 11 bytes, although 2 bytes FOpts are used by LoRaWAN protocol: 9 bytes are available for SCHC payload + 1 byte FPort @@ -834,128 +834,139 @@ field, a tile does not fit inside so LoRaWAN stack will send only FOpts. Next transmission MTU is 242 bytes, 4 bytes FOpts. 23 tiles are transmitted: -LoRaWAN message, containing SCHC Fragment: +~~~~ | LoRaWAN Header | LoRaWAN payload (231 bytes) | + --------------------------------------+ --------------------------- + | | FOpts | RuleID=20 | W | FCN | 23 tiles | + -------------- + ------- + ---------- + ----- + ----- + ----------- + | XXXX | 4 bytes | 1 byte | 0 0 | 61 | 230 bytes | - +~~~~ +{: #Fig-example-uplink-fragmentation-lorawan-packet-2 title='Uplink example: LoRaWAN packet 2'} Next transmission MTU is 242 bytes, no FOpts. All 5 remaining tiles are transmitted, the last tile is only 2 bytes + 5 bits. Padding is added for the remaining 3 bits. -LoRaWAN message, containing last tile: +~~~~ | LoRaWAN Header | LoRaWAN payload (44 bytes) | + ---- + -----------+ ------------------------------------------------- + | | RuleID=20 | W | FCN | 5 tiles | Padding=b'000 | + ---- + ---------- + ----- + ----- + ----------------- + ------------- + | XXXX | 1 byte | 0 0 | 38 | 42 bytes + 5 bits | 3 bits | - +~~~~ +{: #Fig-example-uplink-fragmentation-lorawan-packet-3 title='Uplink example: LoRaWAN packet 3'} Then All-1 message can be transmitted: -LoRaWAN message, containing All-1 SCHC Fragment: + +~~~~ | LoRaWAN Header | LoRaWAN payload (44 bytes) | + ---- + -----------+ -------------------------- + | | RuleID=20 | W | FCN | RCS | + ---- + ---------- + ----- + ----- + ---------- + | XXXX | 1 byte | 0 0 | 63 | 4 bytes | - +~~~~ +{: #Fig-example-uplink-fragmentation-lorawan-packet-4 title='Uplink example: LoRaWAN packet 4 - All-1 message'} All packets have been received by the SCHC gateway, computed RCS is -correct so the following ACK is sent to the device: +correct so the following ACK is sent to the device by the SCHC receiver: -LoRaWAN message, containing SCHC ACK: +~~~~ | LoRaWAN Header | LoRaWAN payload | + -------------- + --------- + ------------------- + | | RuleID=20 | W | C | Padding | + -------------- + --------- + ----- + - + ------- + | XXXX | 1 byte | 0 0 | 1 | 5 bits | - ~~~~ -{: #Fig-example-uplink-fragmentation-long title='Uplink example: compression and fragmentation'} +{: #Fig-example-uplink-fragmentation-lorawan-packet-5 title='Uplink example: LoRaWAN packet 5 - SCHC ACK'} ## Downlink - -~~~~ - An applicative payload of 443 bytes is passed to SCHC compression layer. Rule 1 is used by C/D layer, allowing to compress it to 130 bytes and 5 bits: 1 byte RuleID, 21 bits residue + 127 bytes payload. -SCHC Packet: +~~~~ | RuleID | Compression residue | Payload | + ------ + ------------------- + --------- + | 1 | 21 bits | 127 bytes | - +~~~~ +{: #Fig-example-downlink-fragmentation-schc-message title='Downlink example: SCHC Message'} The current LoRaWAN MTU is 51 bytes, no FOpts are used by LoRaWAN protocol: 51 bytes are available for SCHC payload + FPort field => it has to be fragmented. -LoRaWAN message, containing SCHC Fragment: +~~~~ | LoRaWAN Header | LoRaWAN payload (51 bytes) | + ---- + ---------- + -------------------------------------- + | | RuleID=21 | W = 0 | FCN = 0 | 1 tile | + ---- + ---------- + ------ + ------- + ------------------- + | XXXX | 1 byte | 1 bit | 1 bit | 50 bytes and 6 bits | +~~~~ +{: #Fig-example-downlink-fragmentation-lorawan-packet-1 title='Downlink example: LoRaWAN packet 1 - SCHC Fragment 1'} Content of the tile is: + +~~~~ | RuleID | Compression residue | Payload | + ------ + ------------------- + ------------------ + | 1 | 21 bits | 48 bytes and 1 bit | +~~~~ +{: #Fig-example-downlink-fragmentation-lorawan-packet-1-tile-content title='Downlink example: LoRaWAN packet 1: Tile content'} +The receiver answers with a SCHC ACK: -The receiver answers with a SCHC ACK - +~~~~ | LoRaWAN Header | LoRaWAN payload | + ---- + --------- + -------------------------------- + | | RuleID=21 | W = 0 | C = 1 | Padding=b'000000 | + ---- + --------- + ----- + ----- + ---------------- + | XXXX | 1 byte | 1 bit | 1 bit | 6 bits | - +~~~~ +{: #Fig-example-downlink-fragmentation-lorawan-packet-2 title='Downlink example: LoRaWAN packet 2 - SCHC ACK'} The second downlink is sent, two FOpts: -LoRaWAN message, containing SCHC Fragment: +~~~~ | LoRaWAN Header | LoRaWAN payload (49 bytes) | + --------------------------- + ------------------------------------- + | | FOpts | RuleID=21 | W = 1 | FCN = 0 | 1 tile | + ---- + ------- + ---------- + ----- + ------- + ------------------- + | XXXX | 2 bytes | 1 byte | 1 bit | 1 bit | 48 bytes and 6 bits | +~~~~ +{: #Fig-example-downlink-fragmentation-lorawan-packet-3 title='Downlink example: LoRaWAN packet 3 - SCHC Fragment 2'} +The receiver answers with an SCHC ACK: -The receiver answers with an SCHC ACK - +~~~~ | LoRaWAN Header | LoRaWAN payload | + ---- + --------- + -------------------------------- + | | RuleID=21 | W = 1 | C = 1 | Padding=b'000000 | + ---- + --------- + ----- + ----- + ---------------- + | XXXX | 1 byte | 1 bit | 1 bit | 6 bits | - +~~~~ +{: #Fig-example-downlink-fragmentation-lorawan-packet-4 title='Downlink example: LoRaWAN packet 4 - SCHC ACK'} The last downlink is sent, no FOpts: -LoRaWAN message, containing All-1 SCHC Fragment: -| LoRaWAN Header | LoRaWAN payload (33 bytes) | -+ ---- + --------- + ------------------------------------------------------- + -| | RuleID=21 | W = 0 | FCN = 1 | 1 tile | Padding=b'00000 | -+ ---- + --------- + ------- + ------- + ----------------- + --------------- + -| XXXX | 1 byte | 1 bit | 1 bit | 31 bytes + 1 bits | 5 bits | - - -The receiver answers with an SCHC ACK +~~~~ +| LoRaWAN Header | LoRaWAN payload (37 bytes) | ++ ---- + --------- + ----------------------------------------------------------------- + +| | RuleID=21 | W = 0 | FCN = 1 | RCS | 1 tile | Padding=b'00000 | ++ ---- + --------- + ------- + ------- + ------- + ----------------- + --------------- + +| XXXX | 1 byte | 1 bit | 1 bit | 4 bytes | 31 bytes + 1 bits | 5 bits | +~~~~ +{: #Fig-example-downlink-fragmentation-lorawan-packet-5 title='Uplink example: LoRaWAN packet 5 - All-1 message'} +The receiver answers to the sender with an SCHC ACK: +~~~~ | LoRaWAN Header | LoRaWAN payload | + ---- + --------- + -------------------------------- + | | RuleID=21 | W = 0 | C = 1 | Padding=b'000000 | + ---- + --------- + ----- + ----- + ---------------- + | XXXX | 1 byte | 1 bit | 1 bit | 6 bits | - ~~~~ -{: #Fig-example-downlink-fragmentation title='Downlink example: compression and fragmentation'} +{: #Fig-example-downlink-fragmentation-lorawan-packet-6 title='Uplink example: LoRaWAN packet 6 - SCHC ACK'} # Note From 66695edb27741c1c472cde844018e3755557b1f9 Mon Sep 17 00:00:00 2001 From: Oliv4945 Date: Thu, 12 Dec 2019 10:15:18 +0100 Subject: [PATCH 13/24] RuleId provisionning details --- 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 900e95a..cd50adb 100644 --- a/draft-ietf-lpwan-schc-over-lorawan.md +++ b/draft-ietf-lpwan-schc-over-lorawan.md @@ -373,7 +373,7 @@ In order to improve interoperability RECOMMENDED fragmentation RuleID values are rule was found) The remaining RuleIDs are available for compression. RuleIDs are shared between -uplink and downlink sessions. A RuleID different from FPortUp or FPortDown +uplink and downlink sessions. A RuleID not in the set(s) of FPortUp or FPortDown means that the fragmentation is not used, thus, on reception, the SCHC Message MUST be sent to the C/D layer. From 3b7675f62587586c241dd5f77178445c3d005478 Mon Sep 17 00:00:00 2001 From: Oliv4945 Date: Thu, 12 Dec 2019 10:15:53 +0100 Subject: [PATCH 14/24] Acknowledgements update --- 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 cd50adb..73dd562 100644 --- a/draft-ietf-lpwan-schc-over-lorawan.md +++ b/draft-ietf-lpwan-schc-over-lorawan.md @@ -707,7 +707,10 @@ addition to those identified in {{I-D.ietf-lpwan-ipv6-static-context-hc}}. {:numbered="false"} Thanks to all those listed in the Contributors section for the excellent text, -insightful discussions, reviews and suggestions. +insightful discussions, reviews and suggestions, but also to (in +alphabetical order) Dominique Barthel, Arunprabhu Kandasamy, Rodrigo Muñoz, +Alexander Pelov, Pascal Thubert for useful design considerations, reviews and +comments. # Contributors {:numbered="false"} From 97c10e1414eb04d4474b33fa2c50c2e3746e974c Mon Sep 17 00:00:00 2001 From: Oliv4945 Date: Thu, 12 Dec 2019 14:18:30 +0100 Subject: [PATCH 15/24] I-D.ietf-lpwan-ipv6-static-context-hc is now normative --- 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 1755ef5..078b111 100644 --- a/draft-ietf-lpwan-schc-over-lorawan.md +++ b/draft-ietf-lpwan-schc-over-lorawan.md @@ -40,8 +40,8 @@ normative: RFC8064: RFC8065: RFC8376: -informative: I-D.ietf-lpwan-ipv6-static-context-hc: +informative: lora-alliance-spec: title: LoRaWAN Specification Version V1.0.3 author: From 2cefd4c081488aae9070b02ce8be0da4c330aa18 Mon Sep 17 00:00:00 2001 From: Oliv4945 Date: Thu, 12 Dec 2019 14:21:05 +0100 Subject: [PATCH 16/24] Editorial changes --- 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 078b111..4e2d870 100644 --- a/draft-ietf-lpwan-schc-over-lorawan.md +++ b/draft-ietf-lpwan-schc-over-lorawan.md @@ -120,7 +120,7 @@ This section contains a short overview of Static Context Header Compression It defines: 1. Compression mechanisms to avoid transport of known data by both - sender and receiver over the air. Known data are called "context" + sender and receiver over the air. Known data are part of the "context" 2. Fragmentation mechanisms to allow SCHC Packet transportation on small, and potentially variable, MTU @@ -496,7 +496,7 @@ Packet, as per {{lorawan-schc-payload}}. 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. +* Penultimate tile MUST be equal to the regular size. 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 b01f49a293c9cb2c59482b9b7731c26f68b64795 Mon Sep 17 00:00:00 2001 From: Oliv4945 Date: Thu, 12 Dec 2019 14:25:42 +0100 Subject: [PATCH 17/24] Clarified RuleId provisionning --- draft-ietf-lpwan-schc-over-lorawan.md | 8 ++++---- 1 file changed, 4 insertions(+), 4 deletions(-) diff --git a/draft-ietf-lpwan-schc-over-lorawan.md b/draft-ietf-lpwan-schc-over-lorawan.md index 4e2d870..96e3cf5 100644 --- a/draft-ietf-lpwan-schc-over-lorawan.md +++ b/draft-ietf-lpwan-schc-over-lorawan.md @@ -356,10 +356,10 @@ server to device, is called downlink fragmentation session. It uses another FPort for data downlink and its associated SCHC control uplinks, named FPortDown in this document. -FPorts can use arbitrary values inside the FPort range allowed by LoRaWAN and -MUST be shared by the end-device, the Network Server and SCHC gateway prior to -the communication. The uplink and downlink fragmentation FPorts MUST be -different. +All ruleId can use arbitrary values inside the FPort range allowed by LoRaWAN +specification and MUST be shared by the end-device and SCHC gateway prior to +the communication with the selected rule. +The uplink and downlink fragmentation FPorts MUST be different. ## Rule ID management {#rule-id-management} From 2337044468b677325d419420cfedf23457a88fdf Mon Sep 17 00:00:00 2001 From: Oliv4945 Date: Thu, 12 Dec 2019 14:26:16 +0100 Subject: [PATCH 18/24] Update acknowledgments --- draft-ietf-lpwan-schc-over-lorawan.md | 6 +++--- 1 file changed, 3 insertions(+), 3 deletions(-) diff --git a/draft-ietf-lpwan-schc-over-lorawan.md b/draft-ietf-lpwan-schc-over-lorawan.md index 96e3cf5..d967a91 100644 --- a/draft-ietf-lpwan-schc-over-lorawan.md +++ b/draft-ietf-lpwan-schc-over-lorawan.md @@ -744,10 +744,10 @@ addition to those identified in {{I-D.ietf-lpwan-ipv6-static-context-hc}}. {:numbered="false"} Thanks to all those listed in the Contributors section for the excellent text, -insightful discussions, reviews and suggestions, but also to (in +insightful discussions, reviews and suggestions, and also to (in alphabetical order) Dominique Barthel, Arunprabhu Kandasamy, Rodrigo Muñoz, -Alexander Pelov, Pascal Thubert for useful design considerations, reviews and -comments. +Alexander Pelov, Pascal Thubert, Laurent Toutain for useful design +considerations, reviews and comments. # Contributors {:numbered="false"} From f8f48f45829ed04e6fe505477965d494349c0044 Mon Sep 17 00:00:00 2001 From: Oliv4945 Date: Mon, 16 Dec 2019 16:16:46 +0100 Subject: [PATCH 19/24] Update IID to use AES-CMAC hash --- draft-ietf-lpwan-schc-over-lorawan.md | 16 ++++++---------- 1 file changed, 6 insertions(+), 10 deletions(-) diff --git a/draft-ietf-lpwan-schc-over-lorawan.md b/draft-ietf-lpwan-schc-over-lorawan.md index d967a91..e9fdebb 100644 --- a/draft-ietf-lpwan-schc-over-lorawan.md +++ b/draft-ietf-lpwan-schc-over-lorawan.md @@ -398,14 +398,11 @@ In order to mitigate risks described in [rfc8064] and [rfc8065] IID MUST be created regarding the following algorithm: 1. key = LoRaWAN AppSKey -2. string = devEui in HEX representation, padded to 128 bits by adding 0s as - most significant bits -3. output = aes128_encrypt(key, string) -4. IID = 64 least significant bits of output +2. cmac = aes128_cmac(key, devEui) +3. IID = cmac[0..7] -aes128_encrypt algorithm is the generic algorithm described in IEEE802.15.4/2006 -Annex B [IEEE802154]. It has been chosen as it is already used by devices for -LoRaWAN procotol. +aes128_cmac algorithm is described in [rfc4493]. It has been chosen as it is +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 @@ -426,9 +423,8 @@ Exemple with: ~~~~ 1. key: 0x00AABBCCDDEEFF00AABBCCDDEEFFAABB -2. string: 0x00000000000000001122334455667788 -3. output: 0x3532E559FCCD707F9E1364029125B26D -3. IID: 0x9E1364029125B26D +2. cmac: 0xBA59F4B196C6C3432D9383C145AD412A +3. IID: 0xBA59F4B196C6C3 ~~~~ {: #Fig-iid-computation-example title='Example of IID computation.'} From 1b6d1aa38e10133822bc10007c31643b4ee13e79 Mon Sep 17 00:00:00 2001 From: Oliv4945 Date: Mon, 16 Dec 2019 16:29:08 +0100 Subject: [PATCH 20/24] fix --- draft-ietf-lpwan-schc-over-lorawan.md | 1 + 1 file changed, 1 insertion(+) diff --git a/draft-ietf-lpwan-schc-over-lorawan.md b/draft-ietf-lpwan-schc-over-lorawan.md index e9fdebb..e7b260c 100644 --- a/draft-ietf-lpwan-schc-over-lorawan.md +++ b/draft-ietf-lpwan-schc-over-lorawan.md @@ -40,6 +40,7 @@ normative: RFC8064: RFC8065: RFC8376: + RFC4493: I-D.ietf-lpwan-ipv6-static-context-hc: informative: lora-alliance-spec: From d9bc51e951b87bc865ecd36921f530bae61e8b8e Mon Sep 17 00:00:00 2001 From: Oliv4945 Date: Mon, 16 Dec 2019 16:29:40 +0100 Subject: [PATCH 21/24] Clarify security --- draft-ietf-lpwan-schc-over-lorawan.md | 9 +++++---- 1 file changed, 5 insertions(+), 4 deletions(-) diff --git a/draft-ietf-lpwan-schc-over-lorawan.md b/draft-ietf-lpwan-schc-over-lorawan.md index e7b260c..b58ccf8 100644 --- a/draft-ietf-lpwan-schc-over-lorawan.md +++ b/draft-ietf-lpwan-schc-over-lorawan.md @@ -393,7 +393,7 @@ instance the device is required to communicate with. The mechanism for sharing those RuleID values is outside the scope of this document. -## IID computation +## IID computation {#IID} In order to mitigate risks described in [rfc8064] and [rfc8065] IID MUST be created regarding the following algorithm: @@ -733,9 +733,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}}. 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}}. +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 +any new security issues in addition to those identified in +{{I-D.ietf-lpwan-ipv6-static-context-hc}}. # Acknowledgements {:numbered="false"} From ac1fc26b2bad758f7d3a7a2e3316896f8c54d3b3 Mon Sep 17 00:00:00 2001 From: Oliv4945 Date: Mon, 16 Dec 2019 16:30:16 +0100 Subject: [PATCH 22/24] Clarify LoRaWAN encryption --- draft-ietf-lpwan-schc-over-lorawan.md | 5 ++--- 1 file changed, 2 insertions(+), 3 deletions(-) diff --git a/draft-ietf-lpwan-schc-over-lorawan.md b/draft-ietf-lpwan-schc-over-lorawan.md index b58ccf8..fe82480 100644 --- a/draft-ietf-lpwan-schc-over-lorawan.md +++ b/draft-ietf-lpwan-schc-over-lorawan.md @@ -306,9 +306,8 @@ confirmed messages. 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: - Application data frame with two levels of AES-128 encryption. One at - application level thanks to the AppSKey, the other at network level with the - NwkSKey. + MAC and application data. Application data are protected with AES-128 + encryption, MAC related data are AES-128 encrypted with another key. ## Unicast and multicast technology From 1d72e1384a608f4d449f91fca17ac0bbabdd8a16 Mon Sep 17 00:00:00 2001 From: Oliv4945 Date: Thu, 19 Dec 2019 12:16:39 +0100 Subject: [PATCH 23/24] Make ACK after each window optionnal --- draft-ietf-lpwan-schc-over-lorawan.md | 34 ++++++++++++++++----------- 1 file changed, 20 insertions(+), 14 deletions(-) diff --git a/draft-ietf-lpwan-schc-over-lorawan.md b/draft-ietf-lpwan-schc-over-lorawan.md index fe82480..746c3d9 100644 --- a/draft-ietf-lpwan-schc-over-lorawan.md +++ b/draft-ietf-lpwan-schc-over-lorawan.md @@ -477,20 +477,15 @@ Packet, as per {{lorawan-schc-payload}}. * RCS: Use recommended calculation algorithm in {{I-D.ietf-lpwan-ipv6-static-context-hc}}. * MAX_ACK_REQUESTS: 8 * Tile: size is 10 bytes -* Retransmission and inactivity timers: - 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}}. At the end of - a window or a fragmentation session, corresponding ACK(s) is (are) - transmitted by the network gateway (LoRaWAN application server) in the RX1 or - RX2 receive slot of end-device. - If this ACK is not received by the end-device at the end of its RX windows, - it sends an SCHC ACK REQ. The periodicity between retransmission of SCHC ACK - REQs is device/application specific and MAY be different for each device - (not specified). 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. +* 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 + 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. +* 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. @@ -498,6 +493,17 @@ 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. + +This OPTIONAL feature will prevent a device to transmit full payload if the +network can not be reach, thus save battery life. + #### Regular fragments ~~~~ From d036b09b0fd9ec3c30ac81fc605082cda44fad4e Mon Sep 17 00:00:00 2001 From: Oliv4945 Date: Fri, 20 Dec 2019 15:18:59 +0100 Subject: [PATCH 24/24] CMAC example correction --- 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 746c3d9..05d4922 100644 --- a/draft-ietf-lpwan-schc-over-lorawan.md +++ b/draft-ietf-lpwan-schc-over-lorawan.md @@ -423,8 +423,8 @@ Exemple with: ~~~~ 1. key: 0x00AABBCCDDEEFF00AABBCCDDEEFFAABB -2. cmac: 0xBA59F4B196C6C3432D9383C145AD412A -3. IID: 0xBA59F4B196C6C3 +2. cmac: 0x4E822D9775B2649928F82066AF804FEC +3. IID: 0x28F82066AF804FEC ~~~~ {: #Fig-iid-computation-example title='Example of IID computation.'}