Findings: Limitations and Security issues
In this section, we discuss the limitations and security issues of the three prototypes described in the previous section. We investigated these implementations by setting a test environment in our lab. We understand these implementations are proofs-of-concept and are not fully implemented versions. Still, we thought this is a good starting point to understand the pros and cons of each implementation, which motivates further work in this context. Furthermore, this is the first existing analysis in this direction, which explores the challenges that must be considered during the building of a MUD capable network.
As a proof-of-concept, the main limitations of this deployment regard the MUD Manager configuration. In fact, before the beginning of the MUD Manager, the configuration of DNS resolution service is manually performed by a human operator, which implies to restart the MUD manager process if new settings have been made. The static configuration introduces scalability problems, due to the manual configuration of DNS resolution, and availability problems, because the MUD manager needs to be restarted to pick the new settings made. Thus, Cisco deployment is impractical in real environments. Another static limit, which regards the implementation itself, involves ACLs management. In particular, all rules, including ingress traffic, i.e. traffic received from external sources to the network and directed to local IoT devices, are static. Consequently, even MUD compliant IoT devices are still vulnerable to attacks originating from external domains, also though the device’s MUD file makes it clear that the device is not authorised to receive traffic from that domain. Nevertheless, dynamic rules, including egress traffic, i.e. traffic sent from IoT devices to an external domain, are supported [dodson2019securing]. Thus, an attacker is not able to establish a TCP connection with the device from an outside domain.
The SDN based PoC provided by Ranganathan et al. [ranganathan2019soft] presents some issues on packet processing. By following the tables pipeline (section Document), the first rule in MAC address (first tables) classifications stage, which is installed when the switch connects, could allow the packet sending to the controller but not to the next table. Thus, a packet may not proceed in the tables pipeline before it can be classified, which implies performance consequences, i.e. switch failure because no packets from a newly connected device can go through the first table until the rule being installed. The behaviour described may be necessary if strict ACLs are required. However, Ranganathan et al. [ranganathan2019soft] proposed a relaxed mode to manage these situations by loosening the ACE definition. In this mode packets can proceed in the pipeline while classification flow rules are being installed, which can result in the violation of the MUD ACEs with the condition that the system will become eventually compliant to the MUD ACEs. These packets could get through before the classification rule being installed at the switch.
Open Source MUD
The limits emerging from this implementation regards the deployment requirements. To host the MUD manager, only OpenWRT compliant routers using a particular version of dnsmasq can be employed in this deployment. A valuable solution provided by osMUD developers to run the MUD Manager outside OpenWRT is to compile it in C environments. However, it induces new requirements: it requires to use a compatible firewall and a DHCP server that can extract the MUD-URL from the DHCP header packet for MUD Enabled Devices. Thus, OpenWRT remains the most user-friendly alternative, as a result of availability for the majority of general-purpose routers [openwrtSupported] and making the MUD manager deployment easier. Lastly, the current implementation does not have MUD file rules for lateral movement; thus, attackers can progressively move through a network, searching for targeted key data and assets.
In this section, we summarise the potential security implications of the three MUD implementations. None of the implementations uses X.509 option to emit the MUD URL and provides support through DHCP or LLDP. Therefore, if a device is compromised, the MUD URL issued through it can potentially be spoofed. Conversely, it is secure when the device uses the X.509 extension since the MUD URL is added to the certificate by the manufacturer. This means that the MUD URL emitted by an X.509 device can not be spoofed without detection, even if the device is exploited. Further security issues are related to the MUD Specification itself. It does not provide any inherent security protections to IoT devices themselves. If a device’s MUD file permits an IoT device to receive communications from a malicious domain, traffic from that domain can be used to attack the IoT device. Similarly, if the MUD file permits an IoT device to send communications to other domains, and if the IoT device is compromised, it can be used to attack those other domains. Some security considerations to keep in mind by users implementing MUD are provided by the specification [rfc8520] in the Security Consideration section. However, we list some additional security challenges which need further addressing: (1) How to prevent a device from a compromised device’s local attack in the local environment. (2) When MUD signing certificate gets expires while MUD file is still deployed and in function locally; MUD Manager should fetch a newly signed file with signature and updates rules without interrupting the IoT device availability and functionality. (3) MUD enforced rules does not provide sufficient fine-grained control. Individual users may have their deployment setup with may require additional rules; thus a mechanism to incorporate the user policy to filter traffic to provide more fine-grained control is needed. (4) How to incorporate updates from Threat Signalling Server. The further question and investigation in this direction is - should they go through MUD file or through a generalised common server updates (and filters) for all IoT devices.
User Policy Server in a MUD enabled network
In this Section, we present and analyze our solution of problem three listed in the previous Section, which we consider of relative importance. The deployment showed in Figure Document, which was used in our testbed, has these main components: (1) OpenWRT router running osMUD Manager (2) Manufacturer MUD file server running remotely and (3) our User Policy Server (UPS) running locally on a local server. The User Policy Server is a web server based on express framework whose architecture is similar to the Manufacturer MUD File Server (MFS). Deploying this entity gives to an administrator/end-user of an internal network the opportunity to store new MUD Files (hereafter called UPS Files) containing rules more suitable for the network in which MUD is deployed. Thus, a network administrator is now able to interact with all the MUD components using a user-friendly interface. It should be noted that by using the same YANG compliant JSON files and MFS interaction, the UPS does not imply relevant changes on the overall osMUD architecture. In particular, the osMUD implementation is extended by us in order to incorporate the following workflow (Figure Document): (1) MUD Manager retrieves the MUD file from the manufacturer MUD file server; (2) MUD Manager verify and parse files and generate ACL and insert ACL on Netgear router; (3) MUD Manager asks to the UPS if there is another UPS file for the device; (4) if yes, MUD Manager retrieves the file, verify and parse files and generate ACL and insert ACL on Netgear router. The previous steps imply that router hosting osMUD has UPS’s certificate and that osMUD implementation can request a further UPS file. We assume that the MUD Manager knows a priori the UPS location. To locate UPS files and make the communication trusted, the device’s mac-address is used as UPS file name(e.g. device-mac-address.json) and each UPS file is signed by the UPS (as MFS case). After obtaining the UPS file, the MUD Manager can now process it and produce the rules to enforce in the router firewall. At the end of this procedure, the union of manufacturer and administrator rules is performed. This behaviour is appropriate to define either internal communication pattern or more relaxed rules. For example, in voice-based assistant systems (e.g., GoogleHome) case, it is hard for the manufacturer to define a communication pattern that allows all communications that it needs. Thus, the administrator can quickly build new communication patterns for the necessary services. Nevertheless, the rules union could bring out new challenges: redundancy (limited storage) and conflicting rules (packet filtering performance [firewall]). The former can be easily managed by using a matching technique, e.g. rule to insert with IP tables rules. The latter induces a vital problem that needs to be solved. For example, suppose that the manufacturer’s rules (MUD file) allow the communication with two different external hosts, say, and , but administrator rules (UPS file) allow only and . In our current system, the device for which these rules are defined is allowed to communicate with all three hosts (, and ). If a priority system is used and administrator rules have the highest priority, the previous device is able to communicate with only and . Both problems are beyond the aim of this work, but they will be considered for future UPS versions. Hence, considering the ability to remove/reversing MUD rules, using UPS needs thoughtful consideration. The UPS introduction in a MUD enabled the network to pave the way to new exciting scenarios:
Automatic UPS File generation: Use a tool that automatically generates UPS files (YANG compliant JSON files) by monitoring the internal traffic [MUDGEE].
New MUD File structure for UPS Files: Extension of current file structure to obtain more restrictive rules such as packet rate, maximum packets, time restrictions, maximum ingress and egress points. To implement this, we require extending osMUD Manager, parsing capabilities, and rule enforcement logic.
Publish/subscribe architecture: it is possible to extend the UPS infrastructure with a publish/subscribe model [Feraudo2020], where server becomes the publisher and the router becomes subscriber, in order real time rules upgrade. The server can publish, by understanding the traffic behaviour, new rules that must be inserted in the IP tables of the router. The described architecture requires signature based authentication between the router and server, otherwise an attacker could impersonate the server and insert less restrictive rules.
The system evaluations aim to check the feasibility of running such a system in home routers or small business environments. We run experiments in our lab environment on an OpenWRT compliant Netgear router (model WNDR 3700v2) and an entity that hosts the UPS (MacBook Pro, Intel Core i5 and 8 GB of RAM). To check the system feasibility, the tests are performed by considering the total time spent (latency) by the osMUD Manager in:
retrieving the MUD file;
verifying and storing the file locally at the router;
processing the file and installing the rules.
These actions depict the setting time of the rules specified in a MUD file. The tests consider router in its booting stage that represents the highest overloading phase, because of the aggregation of DHCP requests received from all connected devices (IoT and non-IoT). In case of MUD compliant IoT devices, the osMUD manager processes the MUD-URLs one by one to locate the MUD files. Hence, the file retrieving and processing is sequential. Additionally, to study the worst-case scenario, our tests examine the situation where all the IoT devices are turned on before the router boot process so that all the MUD files need to be retrieved at the same time. For testing purpose, the MUD file server provided by osMUD designers 111https://mudfiles.nist.getyikes.com/ is used. The osMUD manager, when a MUD compliant IoT device has administrator rules (UPS file), has to repeat the same operations listed above after installing the MUD file rules. It is worth noting that these UPS files are not defined for all the MUD compliant device, but only for devices for which is considered appropriate by an administrator (in our test it is simulated with a random number). The Fig. Document illustrates the performance of the osMUD manager in classical (without UPS files) and administrator (with UPS files) environment. Both the tests have been repeated 20 times with a file size range between 2-6K. In the test settings, the UPS file requests and MUD file requests are set as: (1,1), (2,2), (2,4), (3,8), (6,16). The numbers in the brackets (a,b) indicate: a = number of MUD compliant devices (random), which request for UPS file; b = number of MUD compliant devices. First of all, by considering only the one device scenario, the performance registered by the osMUD manager in the presence of UPS file is slightly worse than those achieved by the classical MUD environment, as a result of an additional request done to the UPS. Nevertheless, the results obtained are better than expected; the latency average in osMUD with the UPS file is 4.1 seconds compared with 2.9 seconds of osMUD in classical cases, which means in average only 1 second worse. One of the reasons that bring out this result comes from the evidence that requests do not leave the local network, which implies a reduction in the file download time. These results are promising and motivate the usage of a User Policy Server in a MUD deployment. Secondly, in the ideal environment, the time spent on doing these operations is not linear, as a result of not stable connectivity. However, the time is not exponential, so the number of devices do not carry excessive weight on the performance. This is not true for the administrator environment, in which the time depends on the number of devices requires additional requests. For example, the couple (6,16) reached a spike of 55 seconds, compared with 45 seconds of the ideal environment. In conclusion, in both cases with 16 devices, the time exceeds more than twice the time spent by 8 devices. The evaluation leads us to think that when the number of devices is over a certain threshold, the router starts to slow its performance, for example, in the case illustrated in Fig. Document the threshold value can be defined as 8 devices, as a result of the considerable growth reached after this number. The circumstance described represents the worst condition that could occur in case of router failure or unexpected reboot of it. In a steady condition in which at most 2 devices at a time are added, the performance registered are acceptable in both the environment even if both the devices requests an additional UPS file.
The use of MUD as an isolation-based defensive mechanism to restrict traffic generated from the devices is still in its early phase. Therefore, only a few deployment scenarios and proof-of-concept (PoC) implementations currently exist. Andalibi et al. [Andalibi2019] proposed extended MUD functionality to include traffic patterns - such as message size, peak-rate and maximum message transmissions within a time-period and proposed to implement those filtering at the fog network firewall. However, the paper does not provide any implementation. Also, it does not provide further details related to how these traffic control lists will be enforced at the fog networks and how this solution will be scalable in a large organization. Yadav et al. [Yadav2019a] have proposed the scenario of combining user control policies with MUD to provide fine-grained control of IoT data. This work lacks to provide how to use user-based policies with MUD to control messages directly exchanged with external services. Ranganathan et al. [ranganathan2019soft] presented a scalable implementation of the MUD standard on OpenFlow-enabled Software Defined Networking switches and Hamza et al. [Hamza2018a, Hamza2019]
developed machine learning methods to detect volumetric attacks such as DoS, reflective TCP/UDP/ICMP flooding, and ARP spoofing to IoT devices in MUD compliant traffic. Feraudo et al.[Feraudo2020], presented and evaluated Federated Learning in the MUD compliant Edge Network and showed a use-case of User Policy Server (UPS). Gracia et al. [Garcia2019] presented a proactive security approach managing secured and automated deployment of IoT devices by using an SDN-enabled security architecture in Industrial IoT settings. Matheu et al. [Matheu2020] presented an extended MUD model with a flexible policy language to express additional aspects, such as data privacy, channel protection, and resource authorization. Afek et al. [Afek2019] presented a system built upon the MUD specification to provide IoT security through a VNF deployed within the ISP.
Conclusions and Future works
The MUD specification presents some limits from security and architecture perspectives. There exist some behaviours which can be only defined by local policy, even when using components that are fully MUD compliant. If the default policy provided by the manufacturer is not sufficient or too restrictive for the network standard, user actions are necessary to configure the device according to a different and desired policy. Thus, our work explores the existing MUD implementations and tries to find the most convenient deployment for the general user. Furthermore, our work implements the UPS web server that provides a user-friendly interface needed to interact with the MUD components to modify their default settings when required. The behaviour defined allows building whitelist rules more suitable for the network in which MUD is deployed. Our future directions will be focused on the extension of the User Policy Server functionalities and on solving implementation inconsistencies concerns, to guarantee a higher level of security. The work we presented in this paper provides useful insight, and we hope the research and development community get benefit from this. Furthermore, this work opens up more discussions before we start adopting these solutions in real deployment scenarios.