# Enterprise Security for the Internet of Things (IoT): Lightweight Bootstrapping with EAP-NOOB
## 7 Implementation
### Architecture  
Even though the standards discussed in Section 2 all have significant differences, most of them use the same components and architectural patterns. In all of these standards, the resource-constrained IoT devices form a mesh network and rely on a controller node for connecting them to the Internet. We follow the same design pattern for our implementation. Other salient features of our implementation are explained in this section. _MAC layer:_ we use the IEEE 802.15.4 radio available on the Firefly motes. It is a popular MAC layer protocol that is used as a building block for many other standards, such as Zigbee and Thread. _Routing protocol:_ routing in our implementation is based on Routing Protocol for Low-Power and Lossy Networks (RPL) [50]. RPL networks use Destination Oriented Directed Acyclic Graphs (DODAGs) for routing packets. DODAGs contain a root node that acts as a border router between the local network and the Internet. Application layer protocol:constrained Application Protocol (CoAP) [51] is a lightweight protocol for application-layer messaging. It is similar to the Hyper-Text Transfer Protocol (HTTP), but takes into consideration the specific requirements of resource-constrained devices. For example, messages in CoAP are typically exchanged asynchronously over the unreliable User Datagram Protocol (UDP) [25]. Given the lightweight nature of CoAP, we chose to use the Contiki-NG implementation of CoAP for application-layer messaging between the devices and the controller. The controller itself is not constrained and uses HTTP over TLS for interacting with web services on the Internet. Thus, it acts a proxy that translates application payloads from CoAP to HTTP and vice-versa. EAP lower layer:EAP messages can be transported over any lower layer. In enterprise Wi-Fi deployments, EAP is typically carried directly over the IEEE 802.11 frames. Another approach, Protocol for Carrying Authentication for Network Access (PANA) [24], specifies how EAP can be transported over UDP in a network for access authentication. It is important to note the difference between the two approaches. Mainly, in enterprise Wi-Fi networks, the device is not assigned an IP address until it is authenticated and authorized to join the network. PANA, on the other hand, allows for the device to first obtain an IP address and then prove that it is authorized. However, it can be removed from the network (i.e. packets originating from it can be dropped) if it does not authenticate within the expected time. [PERSON] and [PERSON] [52] suggest the use of CoAP as a lower layer for transporting EAP messages in resource-constrained IoT networks. They argue that this approach results in shorter messages due to the lightweight nature of CoAP and that it reduces the code footprint, since the protocol can be reused after the bootstrapping phase. Due to the fact that EAP requires the order of messages to be preserved, it cannot run over raw IP or UDP. [PERSON] and [PERSON] ensure ordered message delivery by utilizing Confirmable CoAP messages [51]. The authors show a significant overhead reduction when using CoAP instead of PANA. These results are further confirmed by [PERSON] et al. [53] and shown to be most significant in multi-hop networks. Hence, in our implementation setup, we use CoAP-EAP for transporting EAP messages between the IoT device and the controller. Figure 1 shows our overall implementation setup. Let us recall that the goal of our bootstrapping solution is to authenticate IoT devices (motes) before they are allowed to communicate with other devices in the local network and send packets to the Internet. As part of the initial authentication process, they must also be registered on a AAA management server. For this, we use a standard Ubuntu 16.10 virtual machine hosted in a private cloud. The AAA server consists of the following components:  
* A web server. The web server provides a user interface for tracking IoT devices. Users are required to create an account on it before they can add or manage their devices.