SKF usability

[lytzV]

Context LNS hosts may set up many routes all sharing the same DevAddr ranges. For instance, they could set up one route for each organization/tenant/user of their LNS, that way they can configure a max_copy setting on an organization/tenant/user level.

The current SKF works as following • If a route has no SK on one of its DevAddr, then HPR will send all packets under that DevAddr to the route • If a route has one or more SK on one of its DevAddr, then HPR will only send packets under that DevAddr if and only if HPR can validate the MIC using one of the SKs

Let's say an LNS host has 1000 organization/tenant/user, and 1000 DevAddr, neither of which are wildly unrealistic. It is very much possible that each organization/tenant/user may not have an active device occupying each of the 1000 DevAddr, let's call those "inactive DevAddr." Note that one route's inactive DevAddr may be active in another route.

In order to avoid getting bombarded by traffic on inactive DevAddrs, LNS hosts may submit dummy keys on them, so HPR would fail at validating the MIC.

This means that the LNS host could be submitting 1000*1000 = 1mm SKs, despite the fact that many of them may simply be dummy keys.

This puts unnecessary burden on HPRs and config service.

Proposal Make a route-level flag "get all traffic for that route's DevAddr ranges" • If the flag = true, then HPR would ignore all SKF on that route • If the flag = false. • When there is no SK on a DevAddr, instead of defaulting to "get all traffic for that DevAddr," default to "block all traffic for that DevAddr." That way, LNS hosts don't need to submit unnecessary dummy keys for inactive DevAddrs. • If a route has one or more SK on one of its DevAddr, then HPR will only send packets under that DevAddr if and only if HPR can validate the MIC using one of the SKs [unchanged from previous behavior]

[lytzV]

Also need to think about how we facilitate the change to the new SKF scheme so we don't have a breaking change.

[lytzV]

Revised Proposal Make a route-level flag "ignore empty skf"

If the flag = true • When there is no SK on a DevAddr, HPR blocks all traffic under that DevAddr to the route. That way, LNS hosts don't need to submit unnecessary dummy keys for inactive DevAddrs.

If the flag = false • When there is no SK on a DevAddr, HPR sends all traffic under that DevAddr to the route.

Regardless of the flag, when there is an non-empty SKF, then HPR will respect it (i.e. send only if the traffic can be validated by one of the SKs in the non-empty SKF)