TTN -> How many JoinRequests are stored


from a security point of view I found something in relation to replay attacks against LoRaWAN and it seems like storing the latest n JoinRequest messages is needed to prevent an replay attack against the network server - in our case the TTN.
Does anyone know how many JoinRequest messages are stored by TTN until somebody could replay an old JoinRequest in order to establish the same session details?
Seems like this information is hidden somewhere inside TTN and not available to public?

Kind regards

If you found a security threat, we kindly ask you, as a security researcher, to:

  • Contact us to report any security vulnerabilities found in any of our community websites, our community network deployments or our open source repositories.
  • Contact us privately through the means listed on this page.
  • Support us in solving the issue (if you have the technical skills to do so).
  • Refrain from requesting compensation for reporting vulnerabilities.
  • Wait for 14 days after we released and deployed a fix before announcing or publishing the details of the vulnerability.
  • Provide us with links to your announcements and/or publications regarding the vulnerability.

see Responsible Disclosure Policy

Actually I’m refering to the paper by Gildas Avoine -> chapter “3.1.2 Targeting the NS”
-> “According to the specification, the NS must keeptrack of “a certain number” of received DevNonce values in order to prevent replay attacks, withoutclarifying if this means all values or a few of them.”
But how big is the number of DevNonces (and therefore JoinRequests) in case of TTN? Or are there any other countermeasures in place?

yes I understand… there are several papers on theoretical LoRaWAN attack vectors.
let’s say there haven’t been a succesfull LoRaWAN replay ‘attack’ on TTN as far as I know.
at least not publiced

I don’t know, but I’m sure there are :sunglasses: