Lorawan-stack: Create devices on extra Join Server

[johanstokking]

Summary

Create devices with root keys on extra Join Servers, like Global Join Server

Why do we need this?

Currently, it is impossible to create a device on, for example, Global Join Server and activate it in a TTI Cloud Hosted region via the Console. It needs command-line with a non-trivial configuration. We'll get the same issue in the community network.

We want to promote people to use Global Join Server by default, to put keys in the right place from the start.

What is already there? What do you see now?

Console supports two modes on device creation; External Join Server (experience tracked in https://github.com/TheThingsNetwork/lorawan-stack/issues/2119) and cluster-local Join Server. Improvements are already on the way in #2644; this would be an extension of a wizard step.

What is missing? What do you want to see?

Multiple options, configurable. For example, in TTI Cloud Hosted:

1. Create on Global Join Server; keys entered will be set to <tenant>.join.cloud.thethings.industries. This means a cross-cluster call
2. Create on cluster-local Join Server; keys entered will be set to routing cluster
3. Use third-party Join Server (like Semtech Join Server); existing behavior

How do you propose to implement this?

The availability, name and cluster address is configuration. We need the following configuration:

console:
  extra-join-servers:
    - name: 'Global Join Server'
      address: 'join.cloud.thethings.industries'
      join-euis:
        - '70B3D57ED0000000/64'
    - name: 'My Custom Join Server'
      address: 'example.com'
      join-euis:
        - '0000000000000000/0'

The cluster-local Join Server is implicitly available if the Join Server is enabled in the Console configuration.

The third-party Join Server is always available. We should probably explicitly name it "third-party", because "external" is confusing (extra JS's are also external to the cluster).

How do you propose to test this?

1. Disable cluster Join Server in Console: there should only be the option to create devices on the third-party Join Server
2. With 1: configure the cluster Join Server as extra: extra-join-servers: [{ name: 'Test', address: 'localhost' }]: there should be two options, with the cluster Join Server as "extra", shown as "Test"

Can you do this yourself and submit a Pull Request?

Can review

[bafonins]

Just to clarify:

Currently, it is impossible to create a device on, for example, Global Join Server and activate it in a TTI Cloud Hosted region via the Console.

This is technically possible, but an end device has to be registered twice, on an external JS and then in the cloud hosted. Right?

Multiple options, configurable. For example, in TTI Cloud Hosted:
1. Create on Global Join Server; keys entered will be set to .join.cloud.thethings.industries. This means a cross-cluster call
2. Create on cluster-local Join Server; keys entered will be set to routing cluster
3. Use third-party Join Server (like Semtech Join Server); existing behavior

So, option 2 is already supported in the Console. Options 1 and 3 are somewhat supported, but someone (either the user or the device manufacturer have to register/claim an end device on external/third-party JS). If understand this correctly, all we are trying to do is to simplify option 1 such that end devices are registered only in CH once and the keys are automatically stored in GJS. For option 3 the current functionality for external JS should suffice. Is this correct?

The availability, name and cluster address is configuration. We need the following configuration:

How is this configured? Is this already supported in the stack?

[johanstokking]

This is technically possible, but an end device has to be registered twice, on an external JS and then in the cloud hosted. Right?

Yes, but this is where creation vs setting becomes confusing. The device is created in IS+JS, but not in NS+AS yet. So it is listed, but it's not complete. In the routing cluster, the user would need to go to the device and "edit" it.

If understand this correctly, all we are trying to do is to simplify option 1 such that end devices are registered only in CH once and the keys are automatically stored in GJS.

Yes. So for clarity: manual key insertion still happens, but now in the routing cluster's Console.

For option 3 the current functionality for external JS should suffice. Is this correct?

Yes, there's no change here, although we might want to call this "third-party Join Server" now.

How is this configured? Is this already supported in the stack?

No, this becomes new Console configuration.

[johanstokking]

Extended the example with the JoinEUI prefixes per Join Server. This should restrict the JoinEUI entry.

[johanstokking]

Raising priority as the concept of Global Join Server remains challenging cc @benolayinka

[bafonins]

Related blocked issue: https://github.com/TheThingsNetwork/lorawan-stack/issues/2694

[johanstokking]

I hope it's not blocked on improving the form UX in general?

[benolayinka]

I'm trying to understand exactly what is needed from the user in each case:

Option 1: Activate on GJS
User enters:
DevEUI - provided by mfr (or created by user if it's an arduino)
JoinEUI - provided by mfr (or created by user if it's an arduino)
AppKey - created by user
NwkKey - created by user
Join Server - box for "also activate on GJS" is checked by default

Option 2: Activate on cluster JS
User enters:
DevEUI - provided by mfr (or created by user if it's an arduino)
JoinEUI - provided by mfr (or created by user if it's an arduino)
AppKey - created by user
NwkKey - created by user
Join Server - uncheck box for "use GJS"

Option 3: Third Party JS
DevEUI - must be provided by mfr
JoinEUI - must be provided by mfr
AppKey - created by user
NwkKey - created by user
Join Server - choose "third party"

two additional qs

1. does this mean users can register any DevEUI/JoinEUI pair in the GJS? doesn't this open the door for conflicts?
2. what is the process for later activating a device on another cluster that has been previously registered in the GJS?

[johanstokking]

@benolayinka your understanding is correct. Minor remark is that _provisioning_ happens (1) on GJS or (2) cluster JS, or the provisioning already happened on (3) an external Join Server. In option 3, there are no root keys generated or provided: it is like now.

• does this mean users can register any DevEUI/JoinEUI pair in the GJS? doesn't this open the door for conflicts?

Yes, but this is already the case. We'll figure that out later with device ownership claiming.

2. what is the process for later activating a device on another cluster that has been previously registered in the GJS?

That is basically (3): so the device is already provisioned. Therefore it should be clear in options 1 and 2 that it's about key provisioning (and the user selects where), and option 3 is about pointing to an already provisioned device.

[johanstokking]

@bafonins what is this blocked on?

Removing prio/medium

[bafonins]

@johanstokking The UI is blocked on https://github.com/TheThingsNetwork/lorawan-stack/issues/2813.

Nothing is blocking us from extending console configuration with a list of extra join servers. However, I would prefer adding the configuration and adapting the UI in the same PR

[johanstokking]

Please include this in the new screens for end device creation.

[johanstokking]

Replaced by #3770