Skip to main content

DCon Problem Statement


The DCon provides an ability to respond to security threats.

DCon will provide an interface that allows Smart Security Agents (SSA) to contain a threat, by restricting the behaviours of one ore more end point devices.

Use cases

The following high level use cases are to be supported by DCon.


The intent of segmentation is to contain risk within classes of devices. It provides a coarse grained stratification based on risk .

  • Segment the Network: segment the network space controlled by the gateway into subsegments that cannot talk to each other. The intent of this is to contain risk within classes of devices. It provides a coarse grained stratification based on risk .
  • Allocate devices to segments: provide the method to allocate a device (or class of devices) to a segment
  • Create inter segment bridges: provide an ability to allows devices to selectively communicate across bridges

Behavioural containment

  • Restrict device(s) behaviour: this provides a method to restrict the behaviour of a device at a fine grained level. This method will load a declarative statement of expected behaviour, which can be loaded by the gateway. This allows for optimised implementation of realty time constraints

The control loop provided by D3Events->SSA->DCon, where an SSA can be arbitrary dynamic code means there are infinite number of way of dynamically programming behavioural containment.

This Restrict device(s) behaviour method is provided predominately and an optimisation.

For example it can be used to translate a declarative MUD description into IP table configuration of firewall rules.


  • Disable device(s): remove the device from the network completely, restricting its ability to interact with any internal or external network resource.


In developing a solution, we should consider the following real world scenarios

  • Multiple routers: the network that needs protecting (in the widest scope) may consist of many physical routers or gateway devices.
  • Heterogenous network types: IOT networks can consider of many different network flavours. The initial focus is IP based gateways. However, LoRa, Zibgee, BT and Zwave are all examples of networks, with distinct respective gateway devices.

The design of the DCon system should allow for the aggregation of of the control plane across multiple gateway devices and from multiple network types.


Internal vs External networks

When considering IP networks, mediated by a gateway we have four classes of communication to consider

  • Internal->External: a device on the internal network (private address space) . These constraints are relatively easy to express as the destination addresses are frequently stable, and reverse DNS allows us to add more context to the constrain.
  • External->Internal: relatively rare as a good security configuration restricts the bulk of the activity through NAT and firewall techniques. However, where this exists, the constrains can be expressed using the above method.
  • External->External: out of scope. As by definition the gateway does not mediate this communication
  • Internal->Internal: this is challenging. IP addresses are often unstable (DHCP), and there exists not secure reliable human addressing methods for internal network devices

Device Classes

Tied to the above issues, it is often desirable to restrict or contain the behaviours of whole classes of devices, rather then individual device instances.

This will require some interaction with the D3 framework to implement