Patent Description:
More particularly, the present invention refers to a method and system of network topology obfuscation within an Autonomous System (AS) to alleviate any attack (e.g., Link Flooding Attacks: LFAs), which can be launched more efficiently and/or effectively if the adversary knows the network topology.

Adversaries who have information about the network topology can typically perform certain attacks in a more efficient, effective and stealthy manner.

It is widely acknowledged that Distributed Denial of Service (DDoS) attacks constitute one of the Internet's major threats today. In recent years, DDoS attacks have been aggravated by the rise in the number of insecure Internet-of-Things (IoT) devices connected to the Internet. In the literature, there exist two main types of DDoS attacks: (i) those that target end-hosts and servers (i.e., volume-based attacks) and (ii) those that target the network infrastructure, also known as Link Flooding Attacks (LFAs). Volume-based attacks are simple yet effective attacks whose goal is to overload a server by sending a large volume of traffic to it. One prominent example of such an attack is the Mirai botnet, which affected many popular websites such as Twitter or Netflix. Fortunately, these attacks can now be prevented to a large extent using Content Delivery Network (CDN) infrastructures. Instead, LFAs aim to disrupt the network connectivity of as many users as possible by congesting network links. The goal of adversaries is to inject a large amount of (separate) flows such that they all simultaneously traverse a set of core network links to overload them. For this purpose, adversaries can use low-volume, separate flows that are indistinguishable from normal traffic, making it difficult for network operators to develop defences to protect against LFAs. Note that adversaries do not require knowledge of any information about the capacity or the load of links and routers to conduct LFAs.

According to <NPL>), executing a LFA against an arbitrary link without knowing the network topology requires five times more flows than when the adversary knows the network topology. Similarly, the number of flows needed to perform a LFA against a target link is orders of magnitude higher when the topology is not known. Indeed, having some knowledge of the network topology is an important prerequisite to execute effective, efficient and stealthy LFAs. This is important for adversaries, as their goal is always to conduct attacks that cause significant damage while minimizing the cost of their attacks (i.e., the number of flows they have to create) and the chances of being detected as much as possible.

At first glance, one might argue that keeping the network topology confidential could be an effective mechanism for network operators to increase the cost to perform successful LFAs. This defence would align well with today's Internet Service Providers (ISPs) since they usually regard their network topologies as confidential. However, researchers have shown that existing path-tracing tools, such as traceroute, can be used to reveal previously unknown ISPs' network topologies including their forwarding behaviour and tracing flow distributions, i.e., the number of traceroute flows received by each router's interface. Hence, these techniques are bound to be applied by adversaries to carry out more efficient and effective LFAs.

Over the last few years, researchers have proposed several reactive and proactive countermeasures against LFAs. Reactive defence methods can only detect such attacks, while proactive countermeasures (i.e., network topology obfuscation solutions) mitigate such attacks by exposing a virtual (false) network topology that conceals potential bottleneck links and nodes while in some cases also attempting to maintain the utility of the information provided by path tracing tools. Note that proactive countermeasures do not prevent LFAs, but rather significantly increase the cost to realize them, thus also reducing the incentives to execute such attacks.

The goal of existing proactive network obfuscation solutions is to conceal potential bottleneck links from adversaries by exposing secure virtual network topologies while (in some cases also) maintaining the utility of the path tracing information. Below, the three state-of-the-art proactive network obfuscation solutions are briefly described:.

After a thorough, systematic analysis of the three state-of-the-art network obfuscation defences, four fundamental weaknesses can be identified in all of them:.

Note that fixing these weaknesses, which can significantly lower the security and utility of the generated virtual topologies, would require major changes in existing defences or even fully redesigning them. Besides the aforementioned limitations, another problem of existing solutions is that none of them tested their obfuscation algorithms using real router-level network topologies for which the IP addresses are known.

Therefore, there is a need in the state of the art for providing networks with methods and techniques to conceal the network topology from adversaries and offer increased resistance against cyber-security attacks, while still allowing network operators to use standard debugging tools to find failures within the network.

<NPL>, is also relevant prior art to the present invention.

The present invention solves the aforementioned problems and overcomes previously explained state-of-art work limitations by providing a secure and practical proactive defence for long-term network topology obfuscation that alleviates any attack where adversaries can benefit from knowing the network topology (e.g., Link Flooding Attacks (LFAs)).

The main objective is to prevent adversaries who use path tracing tools from gaining any advantage over blind (inefficient) LFAs executed without such tools. This purpose is achieved by equalizing tracing flow distributions over nodes and links so that adversaries are unable to distinguish which of them are the most important ones, thus significantly increasing the cost of performing LFAs. LFAs benefit from the fact that some nodes and links in the network appear more than others in the tracing responses obtained by adversaries. As the proposed network topology obfuscation aims to equalize the path tracing flow distribution over network nodes and links, the adversaries are convinced that all nodes and links are equally "popular" (i.e., important) in the network. Meanwhile, the present invention preserves subnet information and maintains the utility of the information collected by path tracing tools, helping network operators who use path tracing tools to debug their networks.

In the context of the present invention, two types of network topology are distinguished: (i) the physical topology and (ii) the logical topology. The former consists of the routers and the (physical) links between them, whose configuration is only known to network operators. Instead, the latter comprises a set of logical nodes (i.e., the routers' ingress interfaces) and the interconnections between them, i.e., the logical links. This is the network topology view adversaries can obtain through path tracing tools.

The present invention aims to expose virtual topologies with equalised path tracing flow distribution over all network nodes and links. This way, adversaries who use path tracing tools (to retrieve network topology information) are unable to distinguish between popular and non-popular nodes by looking at the number of times each node appears in their tracing responses. One of the main challenges is how to achieve the latter while maintaining the utility of the information provided by path tracing tools. Thus, the goal is to generate virtual topologies that jointly maximize security and utility. A virtual topology comprises real nodes and virtual nodes, and the latter are the ones created by the present invention.

The present invention works well even in an adversarial environment where adversaries try to carry out attacks with the purpose of decreasing the security and utility of the virtual topologies generated by the method/system proposed here.

An aspect of the present invention refers to a method of network topology obfuscation as defined in claim <NUM>.

Another aspect of the present invention refers to a system comprising the following components communicated with each other and implementing the method of network topology obfuscation described above: (i) a topology analyser, (ii) a topology obfuscator and (iii) a topology deployer.

The method and system in accordance with the above-described aspects of the invention overcomes the limitations of previous solutions and has a number of advantages with respect to the aforementioned prior art, which can be summarized as follows:.

These and other advantages will be apparent in the light of the detailed description of the invention.

For the purpose of aiding the understanding of the characteristics of the invention, according to a preferred practical embodiment thereof and in order to complement this description, the following Figures are attached as an integral part thereof, having an illustrative and non-limiting character:.

The embodiments of the invention can be implemented in a variety of architectural platforms, operating and server systems, devices, systems, or applications, and can be applied to any network. Any particular architectural layout or implementation presented herein is provided for purposes of illustration and comprehension only and is not intended to limit aspects of the invention.

A preferred embodiment of the invention relates to a system implementing a method for long-term obfuscation of a network topology, as shown in <FIG>. The system comprises three main components: i) the topology analyser <NUM>, ii) the topology obfuscator <NUM> and iii) the topology deployer <NUM>.

The network operator <NUM> provides <NUM> as input <NUM> for the proposed method/system for long-term obfuscation, in the example of <FIG>: the physical topology <NUM> and its forwarding behavior, and the adversary's tracing flows <NUM> and also, in this example, the obfuscation threshold τ. The topology analyzer <NUM> computes the logical topology which is delivered <NUM> to the topology obfuscator <NUM> and obtains the tracing flow distribution from the adversary's perspective, through a tracing flow simulation <NUM>, to identify popular nodes P. The topology obfuscator <NUM> generates virtual nodes and links forming a virtual topology which equalizes <NUM> the tracing flow distribution and is delivered <NUM> to the topology deployer <NUM>. And last but not least, the topology deployer <NUM> continuously monitors tracing flows and generates tracing responses <NUM> with real or virtual IP addresses.

Table <NUM> summarizes the notation used throughout this description of the embodiments of the invention.

Given an unprotected (i.e., with imbalanced tracing flow distributions) network topology, the goal of the proposed method for network topology obfuscation is to generate a virtual topology that significantly reduces the topology leakage in the network. As a first step, the view of the network topology from the adversary's perspective is analysed and the topology leakage is computed. Subsequently, virtual nodes are created (by instructing real nodes to reply to tracing packets with IP addresses different to theirs) for two different purposes: (i) to conceal real nodes from adversaries long-term and (ii) to decrease the popularity of the most observed nodes and links. The latter is crucial to decrease the topology leakage. The network operators can specify to the proposed method their desired level of obfuscation depending on the level of security that they need and the overhead that they are willing to tolerate. Meanwhile, the proposed method assigns virtual nodes IP addresses within the same subnet as the one from the real node from which they originate, maintaining the utility of path tracing information. Whenever a node appears too frequently in the adversary's tracing responses compared to the other nodes, the proposed method automatically adjusts the exposed virtual topology to decrease the topology leakage based on the level of security that the network operators wish to have.

The metrics used to measure the level of security and utility of the generated virtual topologies are described below.

Two variants or embodiments are proposed: The first one estimates the adversary's view of the network topology offline based on information provided by the network operators. Then, it uses this information along with the obfuscation threshold (also specified by the network operators) to compute (offline) the number of virtual nodes required to guarantee that the topology leakage is below the obfuscation threshold. Afterwards, the network topology obfuscation method exposes a virtual topology that attempts to reduce the topology leakage in a best-effort manner using solely the number of nodes created offline. This first variant is suitable for network operators who do not want to create too many virtual nodes. Yet, it requires network operators to possess information about the adversary's behaviour (which may be unavailable or inaccurate). In contrast, the second variant operates fully online and performs the obfuscation tasks on-the-fly (i.e., as tracing packets arrive to the network) without requiring the definition of the adversary's behaviour. The second variant computes firstly the topology leakage and then attempts to decrease it. Here, rather than providing the desired topology leakage reduction, network operators are required to provide the maximum difference in number of tracing flows they can tolerate between any pair of nodes. In this case, the goal of the proposed method is to guarantee that the topology leakage does not exceed the tolerated number.

Below, the main components of the proposed system (topology analyser <NUM>, topology obfuscator <NUM> and topology deployer <NUM>) implementing the network topology obfuscation method are introduced for each of the two aforementioned variants, focusing on how these three components work when applied to the first variant and the second variant. Next, the details of the first variant/implementation are described first, followed by an explanation of how the second variant differs from the first one.

The topology analyser <NUM> starts by inspecting a given (unprotected) network topology in order to infer the network topology view observed by an adversary who uses path tracing tools. Then, the topology analyser <NUM> analyses the tracing flow distribution to find the most popular nodes and links.

In order to build the adversary's logical topology, the topology analyser <NUM> initially conducts a series of simulations offline to find the network topology the adversary would observe from the tracing responses it obtains. To that end, in the first variant, two possible ways for obtaining the adversary's behaviour are distinguished: (i) network operators provide the network topology and its forwarding behaviour themselves (e.g., based on past attacks), or (ii) network operators rely on some default settings (e.g., assuming that the adversary can send packets from anywhere in the network).

On the contrary, in the second implementation/variant, no assumptions on the adversary's tracing behaviour are made by the system: it simply obfuscates the network topology "on-the-fly" (i.e., as packets are sent to the network).

Going back to the first implementation/variant, the topology analyser <NUM> requires network operators <NUM> to provide the network (physical) topology and its forwarding behaviour, and (according to the first implementation variant of the invention) the adversary's tracing flows. For the latter, one option is to let network operators <NUM> specify the adversary's behaviour themselves (e.g., based on traces from past attacks).

Alternatively, the topology analyser <NUM> can use some default configuration, e.g., assume a worst-case scenario where adversary's flows are sent from all ingress routers. In the example below, it is assumed that network operators <NUM> have valuable information about past attacks which they can use to model the adversary's tracing behaviour.

The topology analyser <NUM> proceeds with its (offline) simulations as follows: i) receiving the input adversary's tracing flows, ii) sending them to the corresponding destination nodes and iii) collecting the produced tracing responses. The adversary's tracing flows are given as a triplet containing the source and destination IP prefix blocks (or wildcard rules) along with their corresponding flow amounts. For example, a triplet (<NUM>. <NUM>/<NUM>, <NUM>. <NUM>/<NUM>, <NUM>) mimics the behaviour of an adversary who uses source nodes in <NUM>. <NUM>/<NUM> to send <NUM> different tracing flows to destination nodes in <NUM>. <NUM>/<NUM>.

<FIG> shows an example of the network topology view observed by an adversary who sends <NUM> tracing flows between all source-destination pairs in the network. Rectangles denote source S1, S2, S3 and destination nodes D1, D2, D3. The white and black circles refer respectively to physical nodes A-K (not seen by path tracing tools) and logical nodes A1,. J1, J3,K1 visited by flows. The displayed numbers on the links denote the sum of the expected flow count (i.e., their flow density) per logical link. The topology analyser <NUM> can identify the popular nodes and links based on the path tracing flows that nodes receive.

Next, the graph-based algorithm used to construct the network's logical topology from a given physical topology and adversary's tracing behaviour is introduced and called Algorithm <NUM>. Given a physical topology, its forwarding behaviour and the adversary's tracing flows as input <NUM>, the algorithm picks the first adversary's tracing flow, which specifies how many tracing flows a are sent from the source host s to the destination host d (line <NUM> of the algorithm). Then, the algorithm (line <NUM>) computes the physical path paths→d , which contains all physical nodes along the shortest path from the source s to destination d. Starting from the source, a tracing flow visits each i-th physical node npi along the physical path paths→d (lines <NUM> to <NUM>). For each visited physical node, the algorithm obtains a tracing response with the IP address of the router's ingress interface (lines <NUM> to <NUM>). Then, a logical link li from the previous node (the last visited one) ni-<NUM> to the current node ni is created (line <NUM>). If the logical node and link do not (yet) exist in the logical topology, they are added to it (lines <NUM> to <NUM>). The algorithm also adds the number of tracing flows a to the flow density of the corresponding link and node, respectively (denoted as fdL(li) and fdN(ni)) (lines <NUM> to <NUM>). This process is repeated for all physical nodes along this specific path then for all other adversary's tracing flows. Finally, the algorithm returns the logical topology G which reflects the adversary's view of the network (line <NUM>).

<FIG> shows the measured tracing flow distribution in our running example. The value inside each bar denotes the z-core of each router's interface, while the arrow of double point refers to the current topology leakage L in the network.

Besides revealing the logical topology, tracing responses can provide the adversary with insights about the tracing flow distribution in the network. Unfortunately, regardless of their size, networks typically contain a few nodes that handle most of the traffic, provoking an imbalanced path tracing distribution over nodes and links. Considering the network topology shown in <FIG> and its corresponding tracing flow distribution depicted in <FIG>, due to the imbalanced tracing flow distribution, there exists a significant difference in flow density between the most popular logical node (i.e., G1) and the least popular ones (i.e., F1 and J3). As a result, the current network topology has a high topology leakage, meaning that valuable information about the network characteristics is disclosed to adversaries.

The proposed system/method allows network operators <NUM> to set up an obfuscation threshold τ to limit the maximum topology leakage permitted in the network. This provides greater flexibility since it allows adjusting the topology according to the needs of network operators. Here, the obfuscation threshold τ refers to the topology leakage reduction (measured in %) which network operators <NUM> wish to achieve with respect to the topology leakage in the original network topology. The higher the topology leakage reduction is, the more equalised the tracing flow distribution will be, and thus the more difficult it will be for adversaries to gain insights about the popularity of nodes and links. However, this typically also comes at the cost of generating more virtual nodes, which is undesirable. Therefore, there is the need to find a suitable balance between the obfuscation threshold chosen by the network operator <NUM> and the number of virtual nodes generated by the proposed system, as is explained further below.

The topology obfuscator <NUM> equalizes the path tracing distributions over nodes and links in a best-effort manner while keeping the number of created virtual nodes relatively small. Therefore, the aim of the topology obfuscator <NUM> is estimating the number of virtual nodes to obfuscate the network topology.

Suppose the topology leakage in the original network topology is <NUM> flows, as depicted in <FIG>, and that network operators wish an <NUM>% topology leakage reduction. In such a case, the goal of the proposed obfuscation method is to lower the topology leakage from <NUM> flows to (at most) <NUM> flows.

<FIG> illustrates the procedure through which the offline algorithm used by the topology obfuscator <NUM> equalizes the tracing flow density of a popular node (e.g., G1) by adding virtual nodes: V1, V2, and V3, as shown in <FIG>.

In a possible implementation, the following offline obfuscation algorithm, called here Algorithm <NUM> and defined in detail below, is used by the topology obfuscator <NUM> to estimate the number of virtual nodes needed and decide where they need to be created:
<IMG>.

The process of equalizing the tracing flow distribution depends on the topology leakage and the obfuscation threshold specified by the network operator <NUM>. Initially, the algorithm takes as input the logical topology G, the leakage reduction τl (e.g., <NUM>%), and the number of fixed virtual nodes per real node virtualfixed (e.g., <NUM>) and then computes the maximum leakage allowed leakallowed based on the current leakage leakcurrent and the specified leakage reduction (lines <NUM> to <NUM> of Algorithm <NUM>). Next, the obfuscation algorithm proceeds to add a fixed number (virtualfixed ) of virtual nodes to all real nodes, and to connect those nodes with their neighbours, forming virtual links (lines <NUM> to <NUM>). The algorithm is executed for as long as the current topology leakage leakcurrent is above the allowed leakage leakallowed (line <NUM>). To reduce leakcurrent, the algorithm first chooses the node ncurr whose flow density is the highest among all nodes (line <NUM>), retrieves its existing virtual nodes N'curr and checks whether the flow density of (at least) one of them is below the allowed leakage leakallowed (lines <NUM> to <NUM>). If so, the algorithm chooses such virtual node (denoted as n'curr ) to lower the current leakage leakcurrent (lines <NUM> to <NUM>). Otherwise, it does so by creating a new virtual node n'curr (upon checking that there are IP addresses available in the corresponding subnet) (lines <NUM> to <NUM>). Either with the existing or the newly generated virtual node, the algorithm aims to equalize the flow density of the current node. For this purpose, it creates virtual nodes in all its previous neighbour nodes (lines <NUM> to <NUM>). This task is achieved through the sub-procedure "EQUALIZEFLOWSFORPREVNODES" (line <NUM>). To that end, it first explores all previous nodes for a given current node ncurr (line <NUM>). For each previous node nprev, it attempts to find a previous virtual node n'prev that is connected with the current virtual node n'curr (lines <NUM> to <NUM>). If no previous virtual node is found, it creates a new virtual node for the previous node (if there are IP addresses in the previous node) (lines <NUM> to <NUM>). Following this, it creates an incoming virtual link and splits the flow density to the virtual link l'in and real incoming link lin equally (lines <NUM> to <NUM>). This process is repeated in a recursive way until virtual nodes are created for all previous nodes (line <NUM>), and then also in the opposite direction for all its subsequent nodes (lines <NUM> to <NUM>). Whenever a single loop is finished (lines <NUM> to <NUM>), the algorithm recomputes the current leakage leakcurrent (line <NUM>) and repeats this process again until the leakage is reduced to the desired leakage leakdesired.

Independently of the topology leakage in the original logical topology, the first step for the topology obfuscator <NUM> is always to generate a small, fixed number of (guard) virtual nodes in all real nodes in order to protect them from adversaries who can observe multiple, slightly different virtual topologies exposed over time. For example, all real nodes in <FIG> contain two virtual nodes each for this purpose (V4 and V7 in node E, V5 and V8 in node G, and V6 and V9 in node I). Essentially, the intuition behind this method is to use those virtual nodes to produce a sort of anonymity set - whose size does not need to be large - to avoid adversaries from inferring which nodes are real long-term. Therefore, those virtual nodes must always be present in any virtual topology exposed by the proposed method.

Afterwards, for each real node, the offline algorithm used by the topology obfuscator <NUM> equalizes the tracing flow distribution among the real nodes and the existing (guard) virtual nodes and computes the new topology leakage. If the topology leakage is still higher than the target (i.e., <NUM> flows), the topology obfuscator <NUM> creates additional virtual nodes (e.g., in <FIG>, the virtual node V2 is created by the topology obfuscator) to further split tracing flows among virtual nodes, causing the popularity of certain nodes and links to decrease even further. To maintain consistent logical paths, all subsequent tracing packets within the same flow get the same set of logical and virtual nodes as the first tracing packet.

There exists an important aspect to be considered when adding virtual nodes to the virtual topology. From a security point of view, it is important for virtual logical nodes not to be connected to real logical nodes, since there can only be one node connected to a router's interface at a time and the latter are already connected to other (real) logical nodes. Otherwise, this could disclose to adversaries that two IP addresses belong to the same node. To satisfy this requirement, whenever the topology obfuscator <NUM> creates a virtual node in a real node (e.g., virtual node V2 in real node G), the topology obfuscator <NUM> also creates a virtual node in each of its neighbour nodes (e.g., virtual node V1 in real node E and virtual node V3 in real node I) and then connects them so that they form fully disjoint paths from those containing all real logical node, as shown in <FIG>. As a result, adversaries who use path tracing tools can either obtain (i) E3 → G1 → <NUM>, (ii) V4 --t V <NUM> --t V6, (iii) V7 --t V <NUM> --t V9 or (iv) V1 → V <NUM> --t V3.

The procedure is then repeated until the topology obfuscator <NUM> generates a virtual topology whose topology leakage is equal or below the target previously defined (e.g., <NUM> flows in the previous example) or until there are no IP addresses available in (at least) one of the subnets. Once this is finished, the topology obfuscator <NUM> outputs the number of virtual nodes that need to be created considering the previously defined obfuscation threshold. These are the virtual nodes available to the topology deployer <NUM> to obfuscate the network topology online, as explained right below.

The last step is to deploy the previously virtual topology generated by the topology obfuscator <NUM> in the network leveraging SDN. The topology deployer <NUM> generates flow-rules and instructs routers to reply to tracing packets either with their real IP addresses or with a fake one (the IP address of the real node or the IP address of any of the created virtual nodes). The deployment of the virtual topology can be divided into two steps, III. i) the realization of virtual nodes using SDN and III. ii) the assignation of IP addresses to virtual nodes, here explained:
III. i) Realizing virtual nodes: Leveraging the lack of security mechanisms to preserve the integrity and authenticity of tracing packets, the topology deployer <NUM> modifies the source IP address field in tracing responses in order to create virtual nodes and links in the logical topology. This requires some (minor) configuration changes in the network that only need to be done once. As SDN-enabled routers do not decrease the TTL value by default, the topology deployer <NUM> installs a permanent flow-rule in all routers with the action Decrement IP TTL, so that they decrement the TTL field by one in the tracing packets that the routers receive. It is important to note that only one flow rule is required for this in each router and that the topology deployer <NUM> does not require routers to keep any other state. In addition, the SDN controller <NUM> sends a Set Async Config OpenFlow packet to each router to enable the Invalid TTL flag. By doing so, every time a router receives a tracing packet for which the TTL is invalid, the router automatically encapsulates it within a Packet-In OpenFlow packet and forwards it to the SDN controller <NUM>. The controller <NUM> keeps an obfuscation map that is constantly being updated, which comprises one or more tuples of three elements: {flow ID, router interface and response IP address}. Table <NUM> shows an example of <NUM>-tuples forming the obfuscation map.

The flow ID refers to an identifier of a tracing packet flow from a source <NUM> to a destination <NUM> and is defined by the source and destination IP address prefix, the interface denotes the router interface where the tracing packet is received, and the response IP address corresponds to the IP address assigned to the tracing response by the topology deployer <NUM>.

<FIG> shows an example of tracing response generation by the topology deployer <NUM>. Suppose the interface G1 receives a tracing packet (belonging to a new tracing flow). The first step is for router G to send it to the controller via an Open Flow Packet-In packet. (Note that in any SDN network, tracing packets are processed by the control plane and hence always need to be forwarded to the SDN controller <NUM>). Then, the controller <NUM> chooses a valid response IP from the obfuscation map and sends an OpenFlow Packet-Out packet to router G containing a crafted tracing response with the virtual IP address V2 (see <FIG> shows the example scenario to realize virtual nodes V1 and V2 in the path tracing tool when detecting a tracing packet whose TTL is <NUM> from the interface G1. The following Table <NUM> shows the corresponding result of response generation; in the example of Table <NUM>, the result value of the virtual IP address of node V1 is <NUM>. <NUM> and the result value of the virtual IP address of node V2 is <NUM>.

ii) Assigning IP addresses to virtual nodes: To assign IP addresses to newly generated virtual nodes, the topology deployer <NUM> can follow various strategies. One possibility is to allocate random IP addresses to virtual nodes. However, the use of random IP addresses in tracing responses might be noticeable to adversaries, which could then leverage this information to distinguish between real and virtual nodes. Moreover, this approach might not maintain the utility of the path tracing information. Instead, the topology deployer <NUM> opts for assigning virtual nodes randomly-chosen IP addresses within the same subnet as their real logical nodes. To avoid using already assigned IP addresses, the topology deployer periodically interacts with the SDN controller <NUM> and retrieves the list of assigned IP addresses from its topology discovery services. The idea is to choose IPs within the same subnet as the real node at random but excluding those that have already been assigned.

Once the virtual topology is exposed, the topology deployer <NUM> continuously monitors all incoming tracing flows for obfuscating the network topology in long term. Every time a node receives an expired tracing packet (with TTL=<NUM>) in one of its interfaces, it notifies the topology deployer <NUM> and the topology leakage of the virtual topology is re-computed. If the topology obfuscator <NUM> detects that the topology leakage is above the defined obfuscation threshold, it makes the necessary changes to the exposed virtual topology to decrease the topology leakage while creating as few virtual nodes as possible. The virtual topology is adjusted by the topology obfuscator <NUM> only if, after receiving a new tracing flow, the topology obfuscator <NUM> detects that the topology leakage is above the defined threshold value (based on the obfuscation threshold or tolerated limit defined as input by the network operator <NUM>). The goal is always to keep the current leakage below the allowed_leakage. If this condition is not satisfied, the virtual topology is re-adjusted so that the current leakage is reduced sufficiently to meet the previous condition. Recall that the maximum number of virtual nodes that can be produced is determined by the output of the topology obfuscator <NUM>. Otherwise, the topology deployer <NUM> balances the incoming tracing packets among existing real and virtual nodes.

The addition or removal of virtual nodes to/from the virtual topology (to decrease its topology leakage) does not leak any useful information to adversaries. This is because the topology obfuscator <NUM> adds a fixed number of virtual nodes - which are always present in all virtual topologies exposed - to permanently protect all real nodes in the network. It is not a problem if a few real nodes are added or removed, since adversaries are unable to know how many of such nodes are real nodes and how many of them are virtual ones. In practice network operators could decide to generate a different number of permanent virtual nodes per node. This approach makes it even harder for adversaries to learn any information about the number of real and virtual nodes being added or removed.

Above, the main components of the system have been described for the first variant of implementation to hinder adversaries from knowing which are the most popular nodes and links. Next, a second variant of implementation is described by explaining the differences from the first one.

Unlike the first variant, the second variant equalizes the tracing flow distributions on-the-fly (i.e., as tracing packets are sent to the network) and hence is fully online. This allows network operators <NUM> who do not have (or do not want to use) past attack data to use the invention too, since network operators <NUM> only need to provide the network topology as input to the system/method in this second variant. The network operators <NUM> can set the desired obfuscation (tolerated) limit as input to the topology analyser <NUM>. All this input information is used along with the received tracing packets to compute the current topology leakage and reduce it to a large extent. In this case, the desired obfuscation limit refers to a tolerated number of tracing flows, which is the maximum difference in number of tracing flows between any pair of nodes allowed/tolerated in the network. From this point onward, the system/method in this second variant follows a similar obfuscation procedure to the one shown in the first variant. The only difference compared to the first variant is that now the topology obfuscator <NUM> is not limited to using solely the number of virtual nodes generated offline. As a result, the topology obfuscator <NUM> can create as many virtual nodes as needed to keep the topology leakage under the maximum tolerated value for as long as there are IP addresses in the subnets of the real nodes available for the topology deployer <NUM> to deploy the created virtual nodes.

To demonstrate the feasibility of the proposed solution, in any of the two variants, a full prototype has been implemented by using Software-Defined Networking (SDN). Unlike prior-art systems, the experiments disclosed here have been performed using realistic network topologies along with their corresponding real IP addresses. Extensive evaluations both in software and hardware have been performed and the following results show that the proposed solution is effective at equalizing the tracing flow distributions of small, medium and large networks at the cost of creating a reasonable number of virtual nodes and while preserving the utility of path tracing information, even when only a small number of routers within the network support SDN. Overall, the proposed solution allows for a significant reduction of the topology leakage and hence increases the cost of performing successful LFAs. Also, the security of the solution under a wide variety of attacks has been proved.

For the prototype, a separate SDN application implemented each of the three modules described before, namely (i) topology analyser, (ii) topology obfuscator and (iii) topology deployer. Two additional SDN applications are included in the proposed obfuscation system: a) tracing flow forwarding manager and b) alias resolution handler. The former is used to maintain information about the tracing flows sent to routers and to install rules for forwarding unexpired tracing packets to a destination, whereas the latter intercepts tracing packets that target virtual nodes and generates valid responses to those packets in order to prevent adversaries from fingerprinting routers. The SDN applications run atop Ryu v4. <NUM>, a widely known open-source SDN controller. To evaluate the proposed obfuscation algorithms, it was leveraged the Mininet network simulator, which runs Open vSwitch v2. <NUM> and supports the OpenFlow v1. <NUM> specification, and the CAIDA Internet Topology Data Kit (ITDK) dataset, which comprises a set of router-level network topologies. As those datasets incorporate real IP addresses observed in the wild, they can be used for simulating adversaries who use path tracing tools to discover popular nodes within an AS. The following three networks were selected: (i) AS <NUM> (<NUM> physical nodes and <NUM> links), (ii) AS <NUM> (<NUM> physical nodes and <NUM> links), and (iii) AS <NUM> (<NUM> physical nodes and <NUM> links) in order to evaluate the suitability of the proposed system when applied to small, medium, and large-sized networks. It is considered that each node sent <NUM> tracing flows to each of the remaining nodes in the network to construct the initial logical topology. Similarly, for evaluations <NUM>-<NUM>, each host sent <NUM> tracing flows to each of the remaining hosts.

The two variants of the proposed system were tested using several obfuscation thresholds. In the first variant, the obfuscation threshold denoted by τI, refers to the desired topology leakage reduction. In contrast, in the second variant, the obfuscation threshold denoted by τII, refers to the maximum difference in number of tracing flows between any pair of nodes allowed in the network. <FIG> show the inverse Complementary Cumulative Distribution Functions (CCDF) of flow densities respectively measured in the three network topologies for the first variant, and <FIG> show the inverse CCDF of flow densities respectively measured in the three network topologies for the second variant: <FIG> and <FIG> correspond to small-sized network (AS <NUM>), <FIG> and <FIG> correspond to medium-sized network (AS <NUM>), and <FIG> and <FIG> correspond to large-sized network (AS <NUM>). An ideal result would be that tracing flow distributions in nodes and links exhibit close to horizontally flattened patterns (i.e., the τI =<NUM>% case is the best one). As expected, the selection of strict obfuscation thresholds leads to very equalised path tracing flow distributions. However, for both variants, the tracing flow distributions in the three network topologies are largely equalised even when the least strict obfuscation thresholds are used (i.e., τI =<NUM>% and τII =<NUM>). For example, about top <NUM>% nodes in small and medium ASes and top <NUM>% of nodes in the large AS exhibit similar flow density values with the least strict obfuscation threshold τII =<NUM> (see dashed green lines). Overall, this experiment shows that the obfuscation algorithms used to equalize the tracing flow distributions are very effective at hiding the popularity of nodes and links in the network. The more horizontally flattened graphic in <FIG> and <FIG>, the more flow density distributions are equalized.

For the analysis of the number of virtual nodes required to be created for achieving different levels of obfuscation, <FIG> show that the stricter the obfuscation threshold is, the more virtual nodes are needed. For example, in the first variant, as shown in <FIG>, using the strictest obfuscation threshold (τI =<NUM>%) in the large AS requires around <NUM> virtual nodes in each router, which is 9x larger than when the loosest threshold (τI =<NUM>%) is applied. However, only with the loosest threshold, the proposed system can equalize the tracing flow distribution of the large AS considerably while creating a reasonably small number of virtual nodes (around <NUM> virtual nodes in each real node which results in a total number of virtual nodes of around <NUM>). <FIG> shows the same for the second variant.

Moreover, some experiments were performed to investigate the relationship between the number of virtual nodes generated and the achieved topology leakage reduction for the three network topologies. <FIG> shows the trade-off between topology leakage and the required virtual nodes for a single router. One leakage denotes the amount of <NUM> million flows (i.e., flow density). For the large AS network, the number of virtual nodes required grows linearly as the topology leakage reduction increases, as shown in <FIG>. However, it is observed that this does not always hold in all network topologies. For example, using <NUM> virtual nodes in each router in the small AS achieves a <NUM>% topology leakage reduction; note that this only improves the topology leakage reduction by just <NUM>% compared to the case when <NUM> virtual nodes are used in each router. This experiment shows that there is a need to find an optimal balance between the topology leakage reduction and the number of virtual nodes such that the topology leakage is reduced significantly while keeping the number of created virtual nodes as small as possible. As the results reveal, there might be a point where it is required to add many virtual nodes to lower the topology leakage only very slightly. The network operators can use this to determine the optimal number of virtual nodes that need to be created.

Furthermore, the feasibility of deploying the proposed obfuscation method in networks where only a subset of routers support SDN is analysed too. In such a case, only SDN-enabled routers can obfuscate their interfaces; other routers are forced to expose their real interfaces to tracing flows. Particularly, the case in which network operators decide to use SDN in centralised core routers is considered. To that end, firstly the betweenness centrality is computed for all physical nodes and incrementally the nodes with the highest centrality as SDN routers are selected. Then, the topology leakage reduction is measured when varying the percentage of SDN-capable devices in the network. As it is expected that such central routers will receive many more tracing flows than others, the strictest obfuscation threshold is used: τII =<NUM>. <FIG> shows that, by just having <NUM>% of SDN-capable routers, the proposed obfuscation method was able to reduce the topology leakage by <NUM>% in the small and medium ASes. In contrast, in the case of the large AS, the results indicate that there exists a linear relation between the topology leakage reduction and the number of SDN-capable routers in the network. Interestingly, these results also show that having SDN in more than <NUM>% and <NUM>% of their routers for the small and medium ASes does not lead to significant improvements in terms of leakage reduction, making this deployment strategy (<NUM>% and <NUM>%, respectively) the most optimal. As these high-centrality nodes received many tracing flows, EqualNet was able to efficiently apply its obfuscation algorithms in order to lower the topology leakage. Overall, the experiments showed that the proposed obfuscation method can also significantly reduce the topology leakage in networks where only some of its routers support SDN.

To assess the security, the topology similarity of virtual topologies generated by the proposed obfuscation method is measured and compared them with those virtual topologies produced by existing network obfuscation solutions. Moderate obfuscation thresholds (τI =<NUM>% and τII =<NUM>) are used in both variants of the proposed methods. <FIG> shows a comparison between the two variants and existing solutions (NetHide and LinkBait) in terms of the topology similarity that they offer. The lower topology similarity (in %), the more secure the virtual topology is. The results show that the proposed obfuscation method is able to produce the most dissimilar virtual topologies (in the best case a <NUM>% similarity reduction is achieved). This stems from the fact that the proposed obfuscation method expands the topology space by adding virtual nodes and links. This is in contrast to previous solutions, whose virtual topologies did not experience a significant similarity reduction. To illustrate this, consider the <NUM>-hop obfuscation strategy followed by LinkBait, which exhibited (at best) <NUM>% similarity reduction. For a fair comparison with the proposed obfuscation method and Nethide, recall that, unlike the previous, LinkBait does not intend to provide utility in the virtual topologies it generates; without this requirement we note that it is easier to expose dissimilar virtual topologies.

Furthermore, the topology utility of the created virtual topologies is analysed using the definition of this utility metric described before. For this, different subnet-level traces (e.g., <NUM>. <NUM>/<NUM> → <NUM>. <NUM>/<NUM>) from the CAIDA dataset are simulated. To that end, a realistic range of prefixes that can be employed for a single node or link (e.g., from /<NUM> to /<NUM>) is considered. <FIG> shows that the proposed obfuscation method can provide <NUM>% utility in average for all network prefixes. The case when it did not achieve high utility (<NUM>% in AS <NUM> for /<NUM> prefix) is because of the way the IP assignment is done. In that AS, there are several physical nodes with IP addresses which, under various possible prefixes, would belong to the same subnet.

In order to verify the scalability of Algorithms <NUM> and <NUM> previously presented, <NUM> ASes from the CAIDA dataset whose size spans over small (<NUM> nodes) to large networks (<NUM> nodes) are randomly selected. For each of the <NUM> ASes, <FIG> show respectively the distributions of: (i) the measured time it takes to generate logical topologies (measured execution time for Algorithm <NUM>) and (ii) the measured time it takes to estimate virtual nodes needed offline (measured execution time for Algorithm <NUM>). The results indicate that logical topology generation (Algorithm <NUM>) takes less than <NUM> milliseconds in most ASes (around <NUM>%) whose size is less than <NUM> nodes. For large-sized networks (<NUM> nodes), it is observed that this can take up to <NUM> milliseconds. Similarly, estimating the number of virtual nodes needed (Algorithm <NUM>) takes less than <NUM> seconds in most cases (around <NUM>%) regardless of the chosen value for topology leakage reduction. If a stricter obfuscation threshold is chosen, the time it takes for the algorithm to be completed will increase (e.g., <NUM> seconds in τI =<NUM>%). Given these results, re-running the algorithms (e.g., when the physical topology changes significantly) will not impose a significant overhead.

Claim 1:
A method for network topology obfuscation, comprising the following steps:
- analysing a network topology, by a topology analyser (<NUM>), to obtain a logical topology corresponding to an adversary's view of the network topology and a tracing flow distribution, from an input (<NUM>) to the topology analyser (<NUM>) consisting of a physical topology provided by a network operator (<NUM>), a forwarding behaviour of the network topology and tracing flows of the adversary;
- generating a virtual topology, by a topology obfuscator (<NUM>) receiving the logical topology and the tracing flow distribution from the topology analyser (<NUM>), wherein the virtual topology comprises a number of virtual nodes and links, the virtual nodes being created by the topology obfuscator (<NUM>) to equalize the tracing flow distribution, wherein the number of virtual nodes created by the topology obfuscator (<NUM>) which equalizes the tracing flow distribution is determined by a topology leakage computed as the difference between flow density of the most popular node and flow density of the least popular node, wherein the most popular node is the node receiving the most tracing flows and the least popular node is the node receiving the least tracing flows in the network;
- deploying the generated virtual topology, by a topology deployer (<NUM>), into real nodes and links of the network using software-defined networking, SDN;
- continuously monitoring all the tracing flows incoming in the network and compares the topology leakage with a threshold value defined by the network operator (<NUM>) and, if the topology leakage exceeds the threshold value, the number of virtual nodes and links created by the topology obfuscator (<NUM>) is adjusted and notified to the topology deployer (<NUM>) to balance the incoming tracing flows among real nodes and the adjusted number of virtual nodes created by the topology obfuscator (<NUM>).