## 4 Architecture  
This section describes the architectural components, as well as the technologies and protocols of our solution. Furthermore, we identify different phases for the obtaining and enforcement of MUD files that will be further detailed in Section 5. To foster the deployment of the MUD standard, our architecture is based on the components already defined in Section 3.2. In particular, our solution extends the MUD architecture to accommodate the obtaining of the MUD file into the bootstrapping process of an IoT device. This process is defined in [22] as the phase of a device's lifecycle in which it is installed and commissioned within a network. This way, the MUD policies are obtained and deployed in the network even before the device gets access. This is a key aspect of our solution, since we adopt a proactive approach to avoid potential attacks (e.g., DoS attacks) to target devices. Furthermore, as will be described in Section 5, the process is transparent to the device itself; that is, network components are responsible for getting the MUD URL, MUD file, as well as to translate and enforce the rules contained in such file. Our proposed architecture also represents an instantiation of the MUD processes by using standard technologies to encourage its use and deployment. In particular, we propose the use of the Extensible Authentication Protocol (EAP) [9], which is employed together an Authentication, Authorization and Accounting (AAA) Framework [29] for the bootstrapping phase. EAP is a flexible authentication framework, which allows different types of authentication mechanisms or EAP methods (e.g., pre-shared key (PSK) or Transport Layer Security (TLS) [30]). Indeed, the use of an EAP-AAA infrastructure is suggested in the MUD standard, but considering X.509 certificates. In contrast, we consider the EAP-PSK method [31], as a lightweight EAP method to be used even with resource-constrained devices, which cannot perform public key cryptographic operations. It should be noted that an EAP-AAA infrastructure has been widely considered for bootstrapping of IoT devices [32; 33] for scalability reasons and support for multi-domain scenarios. In this case, an EAP session is established between an EAP peer (the device) and an EAP server through an EAP authenticator, which acts as a mere EAP packet forwarder. For the transport of the EAP messages between the EAP peer and EAP authenticator (a.k.a. low layer protocol in EAP terminology [34]), we use the Protocol for Carrying Authentication for Network Access (PANA) [8]. Although there is a plethora of technologies and protocols proposed for IoT bootstrapping [35], PANA is an IETF protocol that is used by ZigBee IP [36] and the European Telecommunications Standards Institute (ETSI) Machine-to-Machine (M2M) [37]. Furthermore, as described in [38], PANA provides a more lightweight alternative than the Internet Key Exchange Protocol Version 2 (IKEv2) [39], which represents a standard alternative for the transport or EAP messages [34]. In the case of the communication between the EAP authenticator and the EAP server, we use the well-known Remote Authentication Dial In User Service (RADIUS) [40], in which the MUD URL is included after the device or thing is successfully authenticated, as will be described in Section 5. As already mentioned, MUD files are enforced using an SDN-based approaches based on the architecture defined in the scope of the EU H2020 project ANASTACIA [10]. In particular, we accommodate some of the components of such architecture into the MUD manager, which represents the main architectural building block of the MUD standard. Furthermore, we extend their functionality to support the translation of MUD files into flow rules to be enforced by the corresponding network components (i.e., SDN switches). To this aim, we design and implement a component responsible for translating MUD abstractions (e.g., \"same-manufacturer\" or \"my-controller\") into specific security configurations.