As I understand the frame counter is used for security issue, on an uplink the one transmitted by the device shall be at least a value of not less the last one recorded on the gateway side. Does anyone know the impact of the 16/32 bits width, 32 bits has higher security? How is the roll over of the counter managed? For example if I choose only 16 bits width, say I transmit every minute then I can reach 0xffff (max 16 bits value) after <>50 days sending data every minute (if that is possible on the network side, I am not sure if any TTN fair usage etc etc…). So in that case one must use the 32 bits width?
Thanks guys
Florent
I actually don’t think it matters.
If I have understood it is a protection for replay attacks, but you only have 30 seconds per day per node. The rate is so low that it would take months/years to reach 16 bit number.
A LoRaWAN packet only contains 16 bit of the counter value. The back-end (V2) checks the MIC with both a 16 bit value and only if that fails with an 32 bit value. So if you are using a 16 bit value the first check will succeed as there is no roll over to consider, for the 32 bit nodes the second check uses the internally (in the back-end) stored upper part of the counter for validation.
BTW, all of this can be found by looking at the sources on github.
1 Like
Thanks for your reply. So as I understand 32 bits doesnt load more the network, it is just an extra feature on the gateway side in case there was a roll over (as I can see in the code on github thanks for the link). I have one device sending few bytes everyminute for test purpose, after 50 days it will reach the max 16 bits, so I ll tick the 32 bits width (understand I could also disable the counter check).
No, it is a feature in the back-end. Gateways just forward data from the air to IP network and vice versa. Gateways do not decode packets (as there are none of the encryption secrets available to gateways that would not be possible.)
Please keep the fair access policy of TTN in mind. You are allowed to use 30 seconds of airtime per node per day. Not more. That is to grant everyone a fair share of the airwaves…
1 Like
Above all, the setting should match what your device actually uses. Choosing 32 bits in TTN Console for a device that uses 16 bits counters, won’t help.
I think that most end devices will use 32 bits counters; I assume that the 16 bits option was only added to the LoRaWAN specifications to support devices that have extremely limited resources, but that’s just a wild guess. Even though, in LoRaWAN 1.0.x, only the 16 LSB are included in each LoRaWAN message, the Message Integrity Code (MIC) is still calculated using all 32 bits, if 32 bits counters are used.
No, that’s a different setting. The MIC validation will fail for large values, when using the wrong setting for the width.
Sorry I meant back end, not gateway you are right (as highlighted the gateway it is just a forwarder)
This limitation is there already or it is just an advice? (Not trying to break the rule, just for my info)
So “Frame counter checks box” un-ticked the back end will still perform the counter check?
No. When disabling the checks then TTN won’t require the counter to be ever-increasing. That’s all. (And not recommended.) However, regardless that checkbox, TTN will always require a valid MIC, which for values larger than 16 bits is affected by the setting for the frame counter width.
So, your “(understand I could also disable the counter check)” is false; it’s not an alternative for correctly configuring the width to match what the device uses.
So to summarize the nodes whatever has 16/32 bits counter internally, anyway only the 16 bits LSB are sent to the back end? The back end will ever counts the frame received, 32 bits width preferred in case the back end has received more than 0xffff messages within the same session (that shall takes months…). If I keep the same session keys that I got at the first OTAA join but I manually reset the counter & if the “counter checks” box is checked , the back end will reject the messages with counter value sent over lower than what the back end expect, correct?