## 5 MUD-Enhanced Bootstrapping
### MUD Enforcement  
After the MUD translation has been performed, the SDN Orchestrator receives one or more MSPL policies, which must be translated into specific security configurations before they can be enforced. The SDN Orchestrator analyzes the different MSPL policies to identify the main required capabilities. Based on this, it decides the most appropriate security enabler in charge of enforcing each MSPL policy. In particular, a security enabler is defined as a software component in charge of implementing the security function associated with a MSPL policy, i.e., it allows enforcing the security policy in the managed system. For example, there exist different implementations to enforce the MSPL filtering policy. Our framework supports the enforcement of such policy with two enablers: through Netconf protocol [44], and using SDN through Openflow [11]. In order to make the decision, the Security Orchestrator takes into account the current status of the underlying infrastructure and technologies, as well as the available enabler plugins. These plugins are pieces of software that implement the translation from MSPL policies into specific security configurations for the security enablers. After selecting the appropriate security enabler for each MSPL policy (based on ONOS [45] in this case), the SDN Orchestrator requests the MSPL translation to the Policy Interpreter (message 28). Then, this entity retrieves the required plugins for the selected security enablers from a repository [10] to be executed for the translation. In the current scenario, since MUD policies are represented as MSPL forwarding policies, they are translated into ONOS API northbound configurations. When the translation process has finished, configurations are sent back to the SDN Orchestrator (message 29).  
Figure 4: MUD translation.  
After that, the Security Orchestrator requests the policy enforcement for each enabler and configuration (message 30). As already mentioned, it enforces the SDN configuration through ONOS northbound API. The SDN Controller registers the configurations and performs the flows modifications by using OpenFlow _flow-mod_ messages to the corresponding SDN switch (or switches). This communication is protected through TLS. The _match_ field of the _flow-mod_ message contains the \"matches\" packets, which is equivalent to the ACLs contained in the MUD file (e.g., IP of the same-manufacturer). Likewise, the _action_ field in the _flow-mod_ message contains the actions that should be taken for matching packets, as described by the MUD file, for instance, to specify a certain port to forward allowed traffic. Then, the SDN switch(es) apply the new flow rules in their corresponding flow tables (messages 31 and 32). After the enforcement of the rules, if the process has been successfully carried out, the SDN Controller notifies the Orchestrator (message 33) that confirms the process to the IoT Controller (message 34), which, in turn, notifies the Authentication Agent (message 35). Then, the MUD-enhanced bootstrapping process is finished with an EAP Success packet, which is transported in a PANA PAR (message 36) to the smart object. Finally, this entity acknowledges this message with a PANA PAN (message 37). This way, legitimate smart objects only will be able to access the domain after their intended use (reflected by the MUD file) is enforced by the corresponding network components.  
As described, the proposed MUD-enhanced bootstrapping is intended to restrict the potential attacks to/from a certain smart object. Indeed, smart objects' communications will be only allowed once the MUD rules are enforced. After describing the required interactions, the next section describes the application of our approach in the scope of IIoT scenarios. Such use case is based on the use of _digital twins_, which represents an emerging concept to improve the processes required in industrial environments.