## 2 Background
### Technical Implementation of the Filtering Approach Using Bark  
We have previously described the general approach of filtering (in Section 2.3). Next we describe one technical solution to achieve such filtering, as well as the approach to build the filtering rules.  
In [26], [PERSON] et al. present an approach we will refer to as _Bark_ in this paper. Their approach offers fine-grained access control policies, not only with respect to remote participants on the Internet, but also between devices in the local network. In contrast to other similar approaches (e.g., [15; 17; 43], etc.), there is a specification of rules for local network traffic.  
While the authors consider the problem of authenticating clients to be out of scope, similar to the well-known work _IoT Sentinel_ of [PERSON] et al. [17], they also briefly mention the possibility of using different pre-shared keys at the access point. Something we have termed _per-device-802.11-passphrase_ and briefly discuss in future work (Section 8). Further, the approach is based on a _default-off_ policy, which means that by default no communication is allowed at all. Permitted communication is then whitelisted using a policy language, called _Bark_. _Bark_'s format is inspired by natural language constructs _rules_, containing a _subject_, an _object_, an _action_ and _conditions_.  
Both _subjects_ and _objects_ include:  
_Who_--represents the device notion, and corresponds to a MAC address or an IP address, for local or remote devices, respectively. However, in the rules, the _who_ is referenced by a human-readable name which is mapped to the corresponding identifier when a device is configured. For convenience, there is also the possibility of grouping different entities.  
_Where_--corresponds to the gateway that a device is connected to. However, because only one gateway is considered here, this aspect is ignored (Note, also the original work [26] does not explain how this would be enforced for multiple gateways).  
Only _objects_ includes:  
_What_--corresponds to a service or protocol offered by a device (e.g., HTTP, SSH, etc.) and is in most cases simply mapped to a transport protocol (TCP, UDP) and a port but can also be more complicated like DNS requests to only a specified set of addresses.  
Figure 4: For filtering a firewall is placed between the inside network and its connections to the outside; e.g., (**a**) behind the OBD interface of the car or (**b**) the Internet connection of a router.  
Figure 3: Attack against devices (**a**) inside the car coming from the outside via the On-Board-Diagnosis (OBD), (**b**) inside the IoT system coming from outside via the Internet or via an adversarial device connected to the home network.  
Only _action_ includes:  
_How_--relates to protocol-specific actions (e.g., GET/POST for HTTP) which also shows that the approach considers deep packet inspection when applicable.  
Only _conditions_ include:  
_When_--specifies time constraints, e.g., operation time.  
For example, a Bark rule can be as follows:  
Allow the _Robot Vacuum Cleaner_, at router, to _connect_  
_https/tls(IIXIX)_ of _Vacuum Cleaner's Servers_ on _mondays_.  
Of course, the above rule would require -among other details- the specification of the DNS names or IP addresses of all the allowed _Vacuum Cleaner's Servers_, as well as the MAC address or IP address of the _Robot Vacuum Cleaner_.  
We conclude that this approach provides a flexible way to filter not only external but also Local Network Communication. Hence, we decided to use it as a technological basis for our evaluation of the impact that filtering has.