## 2 Related Work  
The definition of behavioral profiles (or normal behavior) for a certain device or system is key for an effective detection of potential attacks in an IoT scenario. The main purpose of the MUD specification [5] is the definition of such profiles, in order to restrict the communications from/ to a certain device to be defined by the manufacturer. The MUD standard is focused on the definition of the behavior of devices with a specific or single purpose (e.g., IoT devices), in contrast to general-purpose devices (e.g., a smartphone). The main reason is that IoT devices often communicate by following easily recognizable patterns [13]. MUD is an IETF standard, which has attracted an increasing attention across industry partners and standardization organizations. In particular, the NIST initially considered the use of MUD to mitigate IoT-based automated distributed threats [14], as well as to prevent vulnerable or insecure devices from being exploited [15]. Indeed, the use of MUD is also considered to mitigate network-based attacks in small business and home IoT devices [6]. Furthermore, the NIST is planning to create a National Thing Behavior Database (NTBD) ([[https://www.nist.gov/itl/applied-cybersecurity/nist-initiatives-iot](https://www.nist.gov/itl/applied-cybersecurity/nist-initiatives-iot)]([https://www.nist.gov/itl/applied-cybersecurity/nist-initiatives-iot](https://www.nist.gov/itl/applied-cybersecurity/nist-initiatives-iot))) as a service similar to the National Vulnerability Database (NVD) ([[https://nvd.nist.gov/](https://nvd.nist.gov/)]([https://nvd.nist.gov/](https://nvd.nist.gov/))), using industry standard specifications such as the MUD. The MUD standard provides an approach to foster a secure and automated deployment of IoT devices. This has also attracted the interest from the research community to address different aspects related to the use and generation of MUD profiles. In particular, the authors in [16] analyze the use of MUD to protect IoT devices against Distributed Denial of Service (DDoS) attacks. To do this, the authors implement a tool for generating MUD profiles using network traffic analysis over pcap files. With a similar approach, the authors in [17] proposes the development of a tool called MUDgee ([[https://github.com/ayyoob/mudgee](https://github.com/ayyoob/mudgee)]([https://github.com/ayyoob/mudgee](https://github.com/ayyoob/mudgee))), which also makes use of pcap files to generate the profiles. The tool is then applied to 28 specific IoT devices, whose profiles are publicly available ([[https://iotanalytics.unsw.edu.au/mud/](https://iotanalytics.unsw.edu.au/mud/)]([https://iotanalytics.unsw.edu.au/mud/](https://iotanalytics.unsw.edu.au/mud/))). Additionally, the authors develop a formal semantic framework to validate MUD files, as well as the compatibility with policies that can be defined in the scope of a certain organization. Based on this work, the same authors present an approach to monitor such profiles in [18]. The main objective of these proposals is to support the generation of MUD profiles to encourage the deployment of the standard. However, these works do not address the process of obtaining and enforcing the MUD profiles. Indeed, the mentioned solutions are complementary to our approach in which we assume the existence of an MUD file, which must be obtained and enforced in the domain in which a certain IoT device is deployed. For obtaining the MUD file, the standard assumes the use of an MUD URL, which the device itself needs to send to the corresponding network components in the domain where it is deployed. In particular, the MUD specification considers the use of three alternative approaches. In the first option, the MUD URL is sent through the Dynamic Host Configuration Protocol (DHCP) [19] in a DHCP Option. The second alternative considers the use of the Link Layer Discovery Protocol (LLDP) [20]. Then, the third option proposes to use the IEEE 802.1 AR standard [21] to embed the MUD URL in a X.509 certificate.