This archive is retained to ensure existing URLs remain functional. It will not contain any emails sent to this mailing list after July 1, 2024. For all messages, including those sent before and after this date, please visit the new location of the archive at https://mailman.ripe.net/archives/list/[email protected]/
[iot-wg] EduRoam for IoT
- Previous message (by thread): [iot-wg] EduRoam for IoT
- Next message (by thread): [iot-wg] EduRoam for IoT
Messages sorted by: [ date ] [ thread ] [ subject ] [ author ]
Marco Hogewoning
marcoh at ripe.net
Tue Dec 10 08:30:16 CET 2019
For the record: writing in this more in personal capacity/curiosity here. But of course also happy to explore if and how RIPE NCC could assist here. On 9 Dec 2019, at 18:43, sandoche Balakrichenan <sandoche.balakrichenan at afnic.fr> wrote: > > The idea initially is to have IoT devices (e.g. LoRa devices) authenticated in visited networks based on its identifier. For example, a LoRa end-device which has established authentication in its home network (e.g. in University A) should be able to connect to a gateway and Network Server in a visited network (e.g. In University B) with the same security credentials. I can see use case of such a mechanism, also outside of the educational spheres. However it is not entirely clear on the interworking with LoRa. It's been a while since I last looked at it, but as I understood in LoRaWan (and similar systems), the network layer authentication is more a matter of L2 filtering/forwarding. I welcome anyone with more current knowledge to correct me here, but the flow as I always understood it: - Device broadcasts a packet - One or more gateways pick it from the airwaves (ISM, usually 863-870) - The gateway looks at L2 MAC address and if it recognises the vendor/application prefix, forwards it into an IP tunnel to some central processing hub. - The hub then either forwards the payload to the "real home" or in smaller scale operations just makes it available for local processing (API call to pick-up the data payload). In that context, to me the authentication part becomes a matter of "do I know these macs"/"Am I showing courtesy of forwarding". The other half is then based on encryption, where you usually see two layers: The first around the entire payload (inc application protocol) that is common to vendor/application and known to the "known" network nodes. And further down a device or user specific certificate to wrap the actual data and keep it private. If this model is still valid, I am sort of curious on what part you envision becoming part of some federated setup? Of course other methods exists, like NB-IOT which sits very close to "traditional" GSM roaming and the way SMS are handled. Products like Sigfox in turn seem to just send every packet back home and deal with it there. More general, sounds a bit like a similar structure the Things Network (http://thethingsnetwork.org) is operating. Maybe worth liaising with them, if only to learn a bit more? Think I still know a few people there, if you need introductions. MarcoH
- Previous message (by thread): [iot-wg] EduRoam for IoT
- Next message (by thread): [iot-wg] EduRoam for IoT
Messages sorted by: [ date ] [ thread ] [ subject ] [ author ]
[ iot-wg Archives ]