| Internet-Draft | IoT/Edge onboarding | July 2021 |
| Nordmark | Expires 27 January 2022 | [Page] |
Previous onboarding discussions have focused on network onboarding. In this note we put that in the context of the larger onboarding picture to also discuss the onboarding to some management or orchestration system.¶
This Internet-Draft is submitted in full conformance with the provisions of BCP 78 and BCP 79.¶
Internet-Drafts are working documents of the Internet Engineering Task Force (IETF). Note that other groups may also distribute working documents as Internet-Drafts. The list of current Internet-Drafts is at https://datatracker.ietf.org/drafts/current/.¶
Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as "work in progress."¶
This Internet-Draft will expire on 27 January 2022.¶
Copyright (c) 2021 IETF Trust and the persons identified as the document authors. All rights reserved.¶
This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (https://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Code Components extracted from this document must include Simplified BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Simplified BSD License.¶
The iotops group has discussed LwM2M [oma], FIDO [fidospec] and [I-D.lear-iotops-deep-thoughts-on-onboarding] where the last one intentionally focuses on network onboarding. This note broadens the discussion to all aspects of onboarding of IoT and edge devices to try to expose what is common and different at different layers.¶
Some of these topics has previously come up in T2TRG for example in [I-D.irtf-t2trg-secure-bootstrapping] but also with a strong networking focus.¶
One aspect of onboarding a device is providing network access to the device. That might involve both L2 and L3 aspects, such as Cellular and WiFi credentials at L2 and LAN as Internet access at L3. Furthermore, the L3 access might differentiate between LAN and Internet access and be subject to access control for instance controlled by MUD [RFC8520].¶
However, there are also higher levels of onboarding. For instance, Anima supports a notion of Secure Bootstrap over an Unconfigured Network [RFC8994] which not only includes the secure keys (BRSKI [RFC8995]) but also the configuration of the routers and switches (using GRASP [RFC8990]). Such configuration can have rather wide span and one can think of it as consisting of configuring the device plus configuring various applications (which might be routing protocols and management agents in the case of Anima use cases).¶
If we look at more compute-centric workloads are likely to have a larger set of applications which might be configured and managed separately from the device. We can already see examples of this in cloud datacenters where there is a IaaS layer provisioning and managing the servers, which is largely invisible to the users, and a set of applications (in the form for virtual machines or containers) which are provisioned and managed using application-specific mechanisms and management systems. For instance, a firewall virtual appliance/VNF might be managed the same way as a physical firewall appliance.¶
The IOTOPS charter scopes its use of "IoT devices" to devices that¶
The definitions of the various parts of Edge Computing by the Linux Foundation in [lfedge-wp] defines the constrained device edge and the smart device edge, which captures devices with different levels of flexibility, but they both fit into the above IOTOPS scope. Thus for the purposes of this discussion we can use Edge Computing devices and IoT devices interchangeably.¶
However, the devices at the constrained device edge are more likely to be single or fixed function in that they do not have the capacity or flexibility to perform other functions than envisioned prior to their deployment. Such fixed function devices still require a software/firmware update capability as discussed in [RFC8240], but they do not require handling new application deployment and associated new communication patterns.¶
The more flexible devices at the smart device edge are likely to be larger than the class 2 devices defined in [RFC7228], however if applications are sufficiently small, constrained devices might very well be edge computing devices. But in general it makes sense to think about devices of the Raspberry Pi class and larger at the smart device edge.¶
For such devices it is clear that the onboarding of the device (to the network and to some management system or controller) should be separable from the onboarding of some particular application (to its controller or management system). Hence the separation between device onboarding and application (instance) onboarding seems required from an architectural perspective.¶
Network onboarding starts at L2 access and can take several different forms such as:¶
In the world of laptop computers and smartphones such access might include traditional EAP but also additional steps such as Endpoint Assessment [RFC5209][RFC7632] before granting full access to the network. Thus the onboarding to the network is not a new thing; what is new is applying it to IoT and Edge Computing devices with to user in front of the device as it is onboarded.¶
As indicated above, if MUD [RFC8520] is used the network onboarding would logically include the retrieval and application of the usage descriptions.¶
This informational note discusses onboarding with the assumption that onboarding needs to address various security threats, but does not go into details.¶
It seems like the roots of trust used for onboarding at the different levels relates closely to the design center for the different onboarding approaches. Loosely we seem to have a few differently approaches (and this list is not exhaustive):¶
The trust might also include initial measurement/attestation of firmware/software along the lines of RATS [I-D.ietf-rats-tpm-based-network-device-attest] to create a baseline before the device leaves the factory.¶
Project EVE [eve] is an example of a secure but minimal approach to enable secure onboarding, without having a hard dependency on manufacturers and manufacturer certificates.¶
When software is installed (factory or elsewhere):¶
Then in any order¶
At that point in time the EVE controller can specify which applications to deploy/boot/halt on device.¶
Potentially EVE can also leverage [sdo], which is an open source implementation of the FIDO specification [fidospec], for the future cases where there is sufficient support in the supply chain for the FIDO signature chains.¶
There are no IANA actions needed for this document.¶