## 5 MUD-Enhanced Bootstrapping
### MUD Translation  
Once the MUD file's signature has been validated, MUD rules can be enforced in different ways depending on the organization. However, before the enforcement of such rules, they should be translated to specific security configurations for a certain domain. Figure 4 shows the MUD file translation process at a high-level. The MUD file is provided to a domain-specific MUD translator, which is in charge of transforming the MUD rules in domain-specific security policies (i.e., MSPL policies). In order to perform the translation, the MUD translator needs to gather specific system domain information, such as the information regarding devices from the \"same-manufacturer\", or the concrete data of the field \"my-controller\". That is, it needs to translate the high-level MUD terms into a set of specific devices. After getting such information, the MUD translator transforms each rule in a set of security policies based on the translation configuration, and depending on the type of security policies implemented by the organization. In our proposal, the MUD translator was implemented as a module of the Policy Interpreter. Therefore, according to Figure 3, when the SDN Orchestrator receives an MUD enforcement request (message 25) with the MUD file and IP address of the smart object, it requests the MUD translation to the Policy Interpreter (message 26). Then, the MUD translator module parses the MUD file and performs the translation as follows: (i) it retrieves system model informationfor the end-points and technologies involved in the MUD ACL; (ii) it identifies the main capability (i.e., an available feature of the system, such as filtering or channel protection) for the MUD ACL by taking into account a combination of the ACL information and the system model information. For instance, if the ACL aims to allow the communication between the smart object and a specific service (e.g., a Network Time Protocol (NTP) [42] service), a _forwarding_ capability is detected. Furthermore, if the organization implements traffic encryption by default, then also channel protection (e.g., based on Datagram Transport Layer Security (DTLS) [43] could be detected; (iii) for each capability, the MUD Translator instantiates a capability-specific policy modelled MSPL. MSPL is used to represent security policies at medium-level abstraction, which represent information of the endpoints and communications, such as IPs and protocols, but they are interoperable and agnostic of the enforcement process. For instance, a filtering MSPL policy could be enforced in a traditional firewall or in an SDN network; (iv) the MUD translator repeats the process according to the number of MSPLs based on the devices and capabilities. It should be noted that, during this process, the new MSPL policies generated from the MUD file could represent conflicting restrictions with the security policies deployed in the deployment domain. Although it is out of the scope of this paper, a _policy conflict detection_ procedure could be used to identify such issues. Finally, the result of the MUD translation process is notified to the SDN orchestrator (message 27).