Nabto Edge Compared to Nabto Micro
Nabto Edge is the next generation Nabto platform, superseding the Nabto Micro platform (also known as µNabto, uNabto and Nabto 4). Nabto Micro will still be supported, but most or all new features will only be added to Nabto Edge.
Nabto Edge adds many new features and is the recommended platform for projects where the embedded device has enough resources: The added features come at a larger footprint, so for the most resource constrained devices, Nabto Micro must be used as discussed below.
Note that Nabto Edge and Nabto Micro are not compatible at any level, they are two completely distinct platforms.
Supported Communication Patterns
Both Nabto Edge and Nabto Micro support request/response and streams - through a raw stream API and a tunnel abstraction. Nabto Edge request/response communication is based on CoAP, Nabto Micro request/response is based on a proprietary RPC implementation based on static interfaces. Nabto Micro RPC does not support fragmentation, ie requests and responses are limited to fit in a single 1 kB payload.
Communication from the device to the basestation on initiative of the device (Push) is currently only implemented in Nabto Micro. It is in the 2020 roadmap to be implemented in Nabto Edge.
Nabto Edge implements or uses standards whenever possible:
- DTLS 1.2 for secure communication
- J-PAKE for secure pairing (2020 roadmap)
- CoAP for request/response communication
- JWT for authentication and authorization (optional)
- OCSP stapling and certificate based authentication of the basestation
- mDNS device discovery
Most of the above did not exist when Nabto Micro was designed. So for Nabto Micro, similar (but proprietary) solutions were designed in-house.
In Nabto Edge, all embedded devices are identified through two ids: A product id (globally unique) and a device id (unique within a product id). Both are used when the device registers with the Nabto Edge basestation reached through a configured service URL.
In Nabto Micro, devices are assigned a single device id that is also used to locate the Nabto Micro basestation servers (device ids are FQDNs that DNS resolve to the basestation).
Nabto Edge uses public key cryptography based on elliptic curves at both client and device. This ensures end-to-end security with no trusted 3rd party.
To enable working on even the most resource constrained devices (down to 8-bit MCUs with just a kB of RAM), Nabto Micro uses a less computationally expensive shared secret based approach: Each device has a unique secret installed, shared with the basestation as configuration data. This requires the basestation to be considered a trusted party.
To enable LAN-only encryption in Nabto Micro, a shared secret is also needed between client and device, often quite complex to manage. So often vendors either disable LAN-only access to devices to ensure an encrypted session is always setup, mediated by the basestation using the device/basestation shared secret (and hence disabling offline use). Or they consider the LAN trusted, meaning that communication happens in cleartext.
In Nabto Edge, LAN encryption just works with no additional hassle as each peer has its own public key cryptography keypair.
Nabto Edge supports public key based authentication and local policy based authorization - as well as support for JWT based authentication and claim based authorization. The platform has built-in support for centralized coarse grained access control based on a simple token based mechanism.
Nabto Micro also supports public key based authentication and simple access control. A simple token based access control mechanism is supported (requires vendor to provide a custom token management service). Nabto Micro has no direct platform support for JWT.
The Nabto Edge platform implements QuickConnect to allow using a relay connection immediately while a direct connection is attempted to be established. This slightly shortens the time for the first byte in scenarios where a direct connection turns out to be possible - and significantly in fallback scenarios where there is no wait for the direct connection attempt to time out.
The Nabto Edge platform has slightly better raw stream throughput than Nabto Micro, relevant for e.g. HD video streams.
The DTLS handshake in Nabto Edge involves exchange of a few more messages than the Nabto Micro handshake, making establishing the initial connection slightly slower on Nabto Edge than on Nabto Micro on high latency connections.
Nabto Edge has full native support for IPv6 (at client, device and basestation).
Nabto Micro has limited support for IPv6: Clients can operate in an IPv6 only network towards a partially IPv6 enabled Nabto Micro basestation. The Nabto Micro device SDK (the uNabto SDK) only supports IPv4, ie relying on a translation mechanism on the user’s network. Hence, only relay is supported if one Nabto Micro peer is deployed in an IPv6-only network.
Nabto Edge requires more computational resources and memory on the embedded device than Nabto Micro due to the use of public key cryptography. This means that at least a 32-bit architecture is required. The exact requirements are yet to be determined, but the platform has been tested to work fine on an ESP32 platform.
Nabto Micro requires an 8-bit CPU with 1-2 kB of RAM (for low throughput scenarios) and 50-200 kB of storage for the application image, depending on included features.