## 4 Architecture
The translation process is supported by a Medium-level Security Policy Language (MSPL), which is intended to represent information about endpoints and communication protocols, but they are agnostic of the enforcement process. Then, these intermediate policies are translated into the corresponding flow rules. In this case, we use the well-known OpenFlow protocol [11], so that an SDN controller is enabled to install, modify, and remove SDN flows (among other operations) in such SDN switches. Based on previous considerations, Figure 2 shows our proposed architecture to manage the obtaining and enforcement of the MUD file. We consider the existence of two different domains; the _deployment domain_, in which the device is being installed (i.e., bootstrapped [22]), and the _manufacturer domain_, in which the device was created, and, consequently, it maintains the associated MUD file. Furthermore, based on the selected technologies, each component plays different _roles_ during the whole process. In particular, our architecture is composed by the following components:  
* **Smart Object**: it represents a device intended to join the deployment domain. This entity represents the device itself (a.k.a. Thing in the MUD standard, as described in Section 3). This entity acts as an EAP peer to initiate the EAP exchange, and PANA Client (PaC) to transport the corresponding EAP-PSK interactions as part of PANA messages. * **SDN Switch**: this entity acts as the entry point of the network for the smart object. Furthermore, it is responsible for enforcing the corresponding flow rules, which are derived from the rules contained in the MUD file. * **Authentication Agent**: it is the intermediate entity in charge of forwarding the EAP-PSK messages between the smart object and the AAA Server. Therefore, it acts as an EAP Authenticator in terminology EAP. For the transport of EAP messages, it acts as a PANA Authentication Agent (PAA) receiving PANA messages from the PaC, and as a RADIUS Client for the communication with the AAA Server through the RADIUS protocol. Furthermore, when the device is authenticated, it gets the MUD URL from the AAA Server and forwards to the MUD Manager. * **MUD Manager**: this is the core component of the architecture based on the functionality described in the MUD standard. Based on ANASTACIA architecture [10], this entity plays the following roles:
* **SDN Orchestrator**: it is in charge of managing the translation of MUD rules into a specific security configuration to be enforced. After receiving the intermediate translation to MSPL,
it selects a specific _security enabler_, which represents a software component in charge of implementing the security function associated with a certain security policy. It also manages the enforcement of that security configuration. * **IoT Controller**: it makes the request to the corresponding MUD File Server based on the MUD URL, which is obtained from the Authentication Agent. * **Policy Interpreter**: it is responsible for the translation process itself by converting the MUD rules into intermediate MSPL policies. Then, it translates these policies into specific security configurations based on the security enabler selected by the SDN Orchestrator. * **SDN Controller**: it manages the enforcement of the security configurations that are sent by the SDN Orchestrator. * **AAA Server**: it acts as a RADIUS Server for the exchange of EAP messages with the Authentication Agent, and as the EAP Server in EAP terminology. This entity is supposed to store the MUD URL associated with a smart object's MUD file. * **MUD File Server**: following the MUD specification [5], it hosts the MUD files associated with the devices of a specific manufacturer. Besides the identification of these components and roles, Figure 2 shows the main phases required for our approach to extend the bootstrapping of an IoT device.