WO2006004556A1

WO2006004556A1 - Traffic redirection attack protection method and system

Info

Publication number: WO2006004556A1
Application number: PCT/SG2005/000217
Authority: WO
Inventors: Ling Ling Vrizlynn Thing; Chee Jwai Henry Lee
Original assignee: Agency For Science, Technology And Research
Priority date: 2004-07-02
Filing date: 2005-07-01
Publication date: 2006-01-12

Abstract

A method of and system for filtering data transmissions in a network for protection against malicious communications. The method comprises determining one or more apparent originating addresses sending communications to a first electronic address over a first path; instructing the determined apparent originating addresses to redirect future communications intended for the first electronic address to a second path; and filtering out communications sent from the determined apparent originating addresses to the first electronic address over the first path.

Description

TRAFFIC REDIRECTION ATTACK PROTECTION METHOD AND SYSTEM

Field of the Invention

This invention relates broadly to a method of and system for filtering data transmissions in a network for protection against malicious communications.

Background

Attacks such as denial of Service (DoS) and Distributed DoS (DDoS) pose an immense threat to the Internet by exhausting the target computer or network's resources. A number of DDoS attacks that shut down some high-profile Web sites, such as Yahoo and Amazon, in February 2000, have demonstrated the severe consequences of these attacks and the importance of efficient DoS/DDoS defence mechanisms.

In DoS/DDoS attacks, malicious packets are typically sent with spoofed IP addresses. In addition, the stateless nature of the Internet makes it difficult to identify the real origin of the packets, making it possible for the attackers to hide their identity. It has been shown that DoS attacks are prevalent in the Internet, whereby more than 12,000 attacks against more than 5,000 distinct targets were observed in a 3-week long data collection period in 2001. In recent years, the research community has been actively working on defending against DoS/DdoS attacks.

Traceback mechanisms such as IP marking, IP logging and ICMP Traceback, for instance as are described by: Stefan Savage et al, in "Practical network support for IP traceback", ACM Sigcomm 2000; Alex C. Snoeren et al, in "Hash-Based IP Traceback", ACM Sigcomm 2001, Aug. 2001 , pp. 3-14; and Steve Bellovin et al, in "ICMP Traceback Messages", IETF Internet Draft, Version 4, Feb. 2003, have been proposed to trace the true source of the DDoS attackers to institute accountability, as attack packets are often sent with spoofed IP addresses to hide the identities of the attackers. In traceback, the attack path or graph is constructed to provide information on the route/s the attack packets have taken to arrive at the victim. It is an attacker identification tool which requires further deployment of a third-party detection and mitigation tool to counter or defend against DoS/DDoS attacks.

A preventive measure to DoS/DDoS attacks is to ensure the authenticity of packets by eliminating source address spoofing. Ingress filtering schemes filter packets with spoofed source addresses at the first router encountered on entering the Internet, which typically has information about valid source addresses that are allowed to pass through it. In Source Address Validity Enforcement (SAVE) protocol, for instance as described by Jun Li et al, in "SAVE: Source address validity enforcement protocol", IEEE lnfocom 2002, pp. 1557-1566, SAVE messages propagate valid source address information from the source location to all destinations, allowing each router along the way to build an incoming table that associates each incoming interface of the router with a set of valid source address blocks. Packets with invalid source addresses are therefore identified as attack packets.

Pushback, as described by Ratul Mahajan et al, in "Controlling High Bandwidth

Aggregates in the Network", ACM Sigcomm 2002, Vol. 62, No. 3, pp. 62-73, is a rate limiting mechanism which imposes a rate limit on data streams characterised as "malicious". It involves a local mechanism for detecting and controlling high bandwidth aggregate at a single router by performing rate limiting on the incoming traffic, and a co- operative pushback mechanism in which the router can ask upstream routers to control the aggregate. However, in this way, all high bandwidth traffic no matter whether legitimate or malicious will be subjected to this rate limiting. Filtering mechanisms on the other hand, filter out an attack stream completely. This is used in the case where the data stream is reliably detected as malicious; otherwise, it may run into the risk of accidentally denying service to legitimate traffic.

Reconfiguration mechanisms change the topology of the victim under attack or the intermediate network to either add more resources or isolate attack machines. The Secure Overlay Services (SOS), for instance as described by A. D. Keromytis, V. Misra, D. Rubenstein, in "SOS: Secure Overlay Services", ACM Sigcomm 2002, architecture is constructed using a combination of secure overlay tunnelling, routing via consistent hashing, and filtering. Entry points to the overlay network are responsible for performing authentication verification and will only allow legitimate traffic to pass. After entering the overlay network, the route taken by the traffic is computed to be passed on to designated beacons and then servlets, all of which are kept secret from the correspondents. Potential targets are protected by filters which only allow traffic forwarded by the chosen secret servlets. Randomness and anonymity is in this way introduced into the architecture, making it difficult for an attacker to target nodes along the path to a specific SOS-protected destination.

Mechanisms such as traceback, rate limiting, and filtering require a third-party detection tool to be triggered. The way the detection tools detect an attack is therefore very important to determine how reliable it is and which of the above-mentioned or other mechanisms to use. Detections are classified into two main categories, which are Anomaly Detection and Misuse Detection.

Anomaly detection techniques assume that all intrusive activities are anomalous and a "normal activity profile" could therefore be established for a system. Activities not matching the profile would then be considered as intrusions/attacks. However, an action which is not intrusive but not recorded formerly in the profile would then be treated as an attack, resulting in false positive. Filtering such a request for service or packets would in a way result in DoS by the defence system itself. In situations whereby intrusive activities, which are not anomalous, occur, it would result in attacks not detected and therefore false negatives. Such scenarios are possible if DoS/DDoS attacks are launched that simply flood the target/victim with legitimate request for service or data packets.

The concept behind misuse detection schemes is that there are ways to represent attacks in the form of a pattern or signature so that even variations of the same attack can be detected. However, they can only be used to detect known attacks. For new attacks for which the characteristics of the attack packets and pattern are unknown, such schemes are of little use. Such schemes are also unable to detect DoS/DDoS attacks that are launched to simply flood the target/victim with legitimate packets.

Summary In accordance with a first aspect of the present invention there is provided a method of filtering data transmissions in a network for protection against malicious communications, the method comprising determining one or more apparent originating addresses sending communications to a first electronic address over a first path; instructing the determined apparent originating addresses to redirect future communications intended for the first electronic address to a second path; and filtering out communications sent from the determined apparent originating addresses to the first electronic address over the first path.

The first path may comprise first routing information to the first electronic address, and the second path comprises different, second routing information to the first electronic address.

The filtering may be performed at the first gateways of the network, at routers of the network, or both.

The second path may comprise a second electronic address for sending the communication intended for the first electronic address to the second electronic address.

The second electronic address may be a co-located electronic address in the network or a co-located foreign agent address in the network.

An entity associated with the first electronic address may be in a foreign network when the redirection is instructed, and the second electronic address may be an electronic address in the foreign network or a foreign agent address in the foreign network.

A proxying home agent in the network may route communications to the first electronic address.

A proxying home agent in the network may tunnel communications to the entity associated with the first electronic address via an electronic address in the foreign network or the foreign agent in the foreign network.

The filtering may be performed at the home agent in the network. The home agent may be implemented in a gateway with home agent functionality, and the filtering is performed at the gateway.

Determining the apparent originating addresses may be based on amounts of data sent to the first electronic address from respective addresses.

Determining the apparent originating addresses may comprise identifying addresses from which a higher than a threshold amount of data is sent to the first electronic address.

Determining the apparent originating addresses may comprise identifying addresses from which a higher than an average amount of data from respective addresses is sent to the first electronic address.

Determining the apparent originating addresses may comprise identifying addresses ranked from a highest amount of data sent to the first electronic address by respective addresses.

The network may comprise the Internet.

The method may comprise instructing only the determined apparent originating addresses to redirect future communications intended for the first electronic address to the second path.

The apparent originating addresses may comprise one or more spoofed addresses, whereby malicious communications from addresses from which the communications associated with the spoofed addresses are sent are filtered out after the redirection instruction.

The method may further comprise conducting a resource utilisation monitoring process, and the determining, instructing and filtering steps are commenced based on the monitoring process. The monitoring process may comprise measuring the resource utilisation; and measuring a consumption growth in the resource utilisation.

The monitoring process may comprise setting an initial sampling rate; measuring the resource utilisation; measuring the consumption growth in the resource utilisation since a last sample; and activating an alarm based on the measured resource utilisation; or setting a new sampling rate based on the measured resource utilisation and activating the alarm or returning to loop to the measuring of the resource utilisation based on the measured growth rate.

The filtering may be activated based on receipt of respective acknowledgement messages from the apparent originating addresses.

The filtering may be activated after the respective acknowledgement messages are received or after the respective acknowledgement messages have not been received within a selected time period.

The method may further comprise rate-limiting traffic to the first electronic address using the first path.

The rate-limiting traffic may be effected by dropping packets at a selected probability.

The probability may be selected based on a current resource utilisation.

In accordance with a second aspect of the present invention there is provided a system of filtering data transmissions in a network for protection against malicious communications, the system comprising means for determining one or more apparent originating addresses sending communications to a first electronic address over a first path; means for instructing the determined apparent originating addresses to redirect future communications intended for the first electronic address to a second path; and means for filtering out communications sent from the determined apparent originating addresses to the first electronic address over the first path. In accordance with a third aspect of the present invention there is provided a system of filtering data transmissions in a network for protection against malicious communication, the system comprising a detector determining one or more apparent originating addresses sending communications to a first electronic address over a first path; a processor executing an application program to instruct the determined apparent originating addresses to redirect future communications intended for the first electronic address to a second path; and a filter filtering out communications sent from the determined apparent originating addresses to the first electronic address over the first path.

In accordance with a fourth aspect of the present invention there is provided a data storage medium having stored thereon computer readable code means for instruction a computer to execute a method of filtering data transmissions in a network for protection against malicious communications, the method comprising determining one or more apparent originating addresses sending communications to a first electronic address over a first path; instructing the determined apparent originating addresses to redirect future communications intended for the first electronic address to a second path; and filtering out communications sent from the determined apparent originating addresses to the first electronic address over the first path.

Brief Description of the Drawing

Embodiments of the invention is further described by way of non-limitative example with reference to the accompanying drawings, in which:

Figure 1 a is a schematic drawing illustrating a traffic redirection attack protection system and method according to an example embodiment;

Figure 1b is a schematic drawing illustrating a traffic redirection attack protection system and method according to an example embodiment;

Figure 2 is a schematic drawing illustrating a traffic redirection attack protection system and method, according to an example embodiment; Figure 3 is a schematic drawing illustrating a traffic redirection attack protection system and method, according to an example embodiment;

Figure 4 is a schematic drawing illustrating a traffic redirection attack protection system and method, according to an example embodiment; Figure 5 is a schematic drawing illustrating a traffic redirection attack protection system and method, according to an example embodiment;

Figure 6 is a schematic drawing illustrating a traffic redirection attack protection system and method, according to an example embodiment;

Figure 7 is a schematic drawing illustrating a traffic redirection attack protection system and method, according to an example embodiment;

Figure 8 is a schematic drawing illustrating a traffic redirection attack protection system and method, according to an example embodiment;

Figure is a schematic drawing illustrating a traffic redirection attack protection system and method, according to an example embodiment; Figure 10 is schematic drawing illustrating is a flowchart of a traffic congestion and overloading detection mechanism according to an example embodiment; and

Figure 11 is an example of a detection mechanism graph using bandwidth as the resource to be monitored according to an example embodiment.

Figure 12 is a schematic drawings illustrating a computer system for implementing a method and system according to an example embodiment.

Figure 13 is schematic drawing illustrating a flowchart of a traffic redirection attack protection method according to an example embodiment.

Detailed Description

Embodiments of the invention provide a real-time DDoS mitigation mechanism, in the form of a traffic redirection attack protection system. In the example embodiments, the victim under attack confirms the authenticity of a source by informing the sender of the data streams to send subsequent data to another address or through another route. In DoS/DDoS attacks, the source is using spoofed IP addresses. Therefore the attacker would not be updated with this redirection information and will continue sending through the old route. A gateway which formerly allowed through packets with the sender's address as the source and the victim's address as the destination, will then start filtering off these packets. Rate limiting is also activated at the gateway to rate limit traffic for the victim, as most good traffic will have been redirected and the traffic left are most probably attack packets with randomly generated spoofed IP addresses.

Embodiments of the invention also provide algorithms for traffic congestion and overloading detection, and DDoS alleviation by performing good traffic redirection, bad traffic filtering and rate-limiting.

Example embodiments are incorporated with Mobile IPv4 and IPv6, but the present invention is not limited to such implementations. The main reason is that Mobile IP is found to be well-suited for performing the necessary traffic redirection functionality of the example embodiments, and with the expected wide implementation of Mobile IP in the Internet, deployment of such embodiments will only require minor changes to the victim network, which network is the most motivated to sacrifice some resources for increased security. There would also be no need for extensive router upgrade, and scalability issues are also taken care of by transferring the role of filtering from the gateways to the home agents.

Another advantage of embodiments of the invention is that the embodiments do not require prior traffic flow characterisations unlike in most existing intrusion detection and DDoS defence systems, and therefore the embodiments allow for a real-time response, even in the event whereby DDoS attacks constitute brute-force flooding of a victim with requests for legitimate services. By the traffic redirection in example embodiments, Quality of Service is also maintained for good high bandwidth traffic. Embodiments of the invention are suitable for both high-end powerful systems and embedded systems, as the embodiments are simple to implement and do not require especially sophisticated algorithms, unlike those used in other existing schemes.

Referring now to Figure 1a, in an example embodiment, when severe traffic congestion or overloading is detected at an address for a victim 100, average throughput from all existing connections with that address for victim 100 is computed. Comparisons are made between the amount of traffic from the individual existing connections and the computed average. Traffic that is greater than the average throughput and a configured threshold is selected for redirection. Redirection of that traffic is then activated to inform these correspondents which provide greater than the average (and threshold) traffic, nominally at addresses Correspondent Nodes (CNs) 102, to send correspondence to a new address. At the same time, the gateways GWs 104 are informed to drop all packets destined for the original address of victim 100 at a certain probability for rate-limiting traffic to the victim 100 (e.g. the gateways let through, say, 10% of such correspondence, randomly).

The gateways 104, then discard packets for the victim 100 sent to the old address at the same probability, without the need to know which gateway 104 may receive more traffic for the victim 100, as those gateways 104 which receive more will drop more packets in this case. The dropping of a certain number of packets allows the easing of congestion to prevent the victim from being overwhelmed by the flood. After the victim 100 receives acknowledgements regarding the redirection from the correspondents CNs 102, the victim 100 informs the gateways 104 to drop all subsequent packets from the informed correspondents 102 to the victim 100, when such packets are taking the old address. Moreover, in an embodiment the same happens for traffic from any correspondent 102 informed of the redirection which does not acknowledge within a certain predetermined period of time.

Therefore, legitimate on-going high bandwidth traffic will be redirected but still getting through (i.e. existing legitimate connection will not be disrupted due to attacks) and malicious on-going high bandwidth traffic (e.g. if an attacker 108 is using a spoofed source address) will be filtered out.

With reference to Figure 1 b, routing information may be utilised to implement the redirecting and filtering in another embodiment. In one such example embodiment, the CNs 102 identified for redirection are informed to use new routing information for traffic intended for the victim 100, but continuing to use the same address for victim 100. At the same time, the gateways 104 are informed to drop all packets destined for the victim 100 using the old routing information at a certain probability for rate-limiting traffic to the victim 100. After the victim 100 receives acknowledgement regarding the redirection from the correspondent 102, the victim 100 informs the gateways 104 and the routers 110 to drop all subsequent packets from the informed correspondent 102 to the victim 100, when such packets are using the old routing information. Moreover, in an embodiment the same happens for traffic from any correspondent 102 informed of the redirection which does not acknowledge within a certain predetermine period of time. In the example embodiment, the routers 110 can handle internal attackers for which packets bypass the gateways 104.

In the above embodiments, all correspondents 102 with higher traffic are informed of the redirection at the same time. In an alternative embodiment, the correspondents 102 are informed one by one, e.g. highest traffic first, until the attack or flooding is deemed over.

In the case of DDoS attacks, whereby multiple small streams of malicious traffic are directed at the victim 100 with randomly generated spoofed source addresses, traffic redirection and filtering are not feasible, unless the numbers from each address are still high. Therefore, the remaining attacks in traffic not redirected most likely fall under this classification of attack. This traffic will be rate-limited, by dropping packets with a given probability at the gateways in an example embodiments (i.e. a more lenient approach), as there is also a possibility that the traffic contains newly initiated connection requests or small streams of traffic from legitimate sources. However, in a DoS/DDoS attack, an enormous amount of traffic destined for the victim 100 will be sent from the attacker 108, instead of from new legitimate sources. Therefore, rate-limiting will result in a high chance that the packets dropped are from the attackers 108. The following subsections describe the traffic redirection and filtering, traffic congestion and overloading detection, and rate- limiting in more detail.

1. Traffic Redirection

With reference to Figure 2, in an example embodiment, a Correspondent Database 202 (CD) is kept by the victim 200 Mobile Node (MN), which records information about the packets the victim 200 MN receives. The following are examples of fields of the database 202 updated by the victim 200 when it receives a packet. - Source address (S_k - unique key field); and - Number of packets received from this source (M_k), where k (from 0 to K-1) is the sequence number of the entries in the CD 202, and K is the total number of entries in CD 202. An expiry time is in place, whereby CD 202 is refreshed periodically so as to keep the data set updated for monitoring the latest on-going traffic.

When congestion or overloading is detected from data in the CD 202 for traffic redirection activation, the victim 200 looks up the CD 202 to locate the correspondent with the highest ongoing traffic. This traffic is chosen for redirection. The reason is that since the traffic flow with this correspondent is high, it should not be rate limited at gateways if it belongs to the category of legitimate traffic. However, if it is malicious high-volume traffic, it should then be totally filtered off. Therefore, only high-volume traffic will be chosen in the example embodiment for redirection due to overhead and scalability considerations.

In the event of a DDoS attack, most of the source addresses in the CD 202 will be randomly generated spoofed addresses. With an updating interval in place, there may be only a few packets (even 1 if a small value of updating interval is chosen and the range of addresses used by the attackers is large) matched to each unique spoofed source address. It will be appreciated that if a small range of spoofed addresses is used, the attack traffic generated from each of the spoofed addresses would typically have to be high bandwidth for the DDoS attack to be successful. Therefore, such addresses would be selected for notification and be filtered off in example embodiments. If certain traffic is not chosen for redirection, that traffic will still be subjected to rate limiting in an example embodiment.

According to an embodiment, the equation (1) below is used for choosing correspondents to perform traffic redirection. In this case, entries in the CD 202 with number of packets M equal to or greater than the averaged number of packets received from entries {D, ...K} will be chosen. In addition, in this embodiment the entries must also satisfy the condition of exceeding a pre-determined threshold value TH (equation (2).

K-I

^{Mk ≥M≡}^T^{~ (1)}" ^and

M_k ≥ TH (2) 1.1 Redirection with Mobile IP

In example embodiments, the basic mechanisms used for the redirection is the Internet protocol Mobile IP. Mobile IP is found to be well-suited for performing the necessary traffic redirection functionality. Further, since Mobile IPv4 is an IETF standard and Mobile IPv6 has now become an IETF standard too, wide implementation of the protocols will be in place in the Internet, and deployment of embodiments of the invention will only require a minor effort of changes to the network to be protected from DoS/DDoS. No change will be required on the rest of the infrastructure. In Mobile IP, Home Agents 204 (HAs) are responsible for proxying and intercepting the packets on behalf of MNs 200, therefore the tasks of filtering and forwarding of the packets destined to MNs 100 can be performed by HAs 204 instead of by gateways. In this embodiments, the gateways (not shown) are relieved from having to handle the hosts for activating the redirection system in the network. In this way, more effective workload distribution and thus higher scalability can be achieved.

Although Mobile IP is used in this embodiment and the victim under DoS/DDoS attacks is referred to as MN 200 here, this scheme is applicable for situations whether the victim (MN) is at a home or a foreign network, and operating in the static or mobile mode. Considerations on different scenarios, issues such as movement detection and modifications required for the exemplary Mobile IP for IPv4 and IPv6 are explained as follows.

1.1.1 Redirection with Mobile IPv4

In an IPv4 network, the Mobile IPv4 mechanism is used for performing traffic redirection. The victim MN 200 obtains a new address (i.e. a "Care-of Address" 206 (CoA)) and sends a registration request message to an available HA 204. The CN 208 (i.e. the chosen correspondent) will also be informed of the CoA 206 through a binding update message to update its binding cache. With reference to Figure 3, in Mobile IPv4, MN's 200 CoA 206 could alternatively be obtained in the form of utilising a Foreign Agent (FA) 300 or by obtaining a new IPv4 address (i.e. co-located CoA) through mechanisms such as Dynamic Host Configuration Protocol (DHCP). Figures 2 and 3 show the two scenarios using and HA 204 and a FA 300 respectively after traffic redirection is performed in the protected network.

The boxes containing address indications in the figures represent packet formats, as follows:

1) where there are just two boxes side by side, for instance box 302 with CN beside box 304 with HoA, the first mentioned address is the source address

(e.g. CN) and the second address is the destination address (e.g. Home Address (HoA))

2) where there are four boxes side by side, for instance box 306 with CN beside box 308 with FA beside box 310 with CN beside box 312 with HoA, this is a tunnelled packet, where the first mentioned address is the outer source address (e.g. CN), the second address is the outer destination address (e.g. CoA), the third address is the inner source (e.g. CN) and the fourth address is the inner destination (e.g. HoA).

In Figure 2 (Traffic redirection using co-located CoA 206 in protected network), traffic redirection is performed using a co-located CoA 206 in the protected (e.g. home) network. When a legitimate CN 208 is notified of the new location of MN 200, CN 208 will tunnel subsequent packets previously destined to MN's original address (HoA) 210 to the new address (CoA) 206. MN 200 on receiving these packets will perform decapsulation itself. As the redirected traffic must be sent from the correspondents to MN 200 directly in this redirection system, route optimisation may be in place for this scheme. If an attacker

207 is using CN's 208 address as its spoofed address for attacking MN 200 with high bandwidth traffic, that attacker 207 will not be informed of MN's 200 CoA 206 (i.e only CN

208 would be informed) and therefore attacker 207 will still be sending, using CN's 208 as the spoofed address, to MN's 200 original address, HoA 210. In this case, HA 204, which is now responsible for intercepting packets destined to MN's 200 HoA 210 will receive these malicious packets and perform the appropriate filtering, see boxes 212, 214. In Figure 3 (Traffic redirection using FA 300 in protected network), traffic redirection is performed using FA's 300 address as the CoA 310. On receiving the redirection address, CN 208 sends subsequent packets destined to MN's 200 original address to FA 300 by first performing encapsulation. FA 300, on receiving the tunnelled packets, will decapsulate them and forward them to MN 200. Since MN 200 is still within its home network, the selected FA 300 can be a router which is able to provide FA's 300 functionality to foreign hosts visiting this network.

In Mobile IPv4, a "returning home" procedure is typically activated when MN 200 receives agent advertisements from its HA 204. However, in the above examples, MN 200 is still within the home network 201 and is able to receive advertisements from HA 204 at all times. Therefore, MN's 200 code can be modified in the example embodiment so as not to perform deregistration for bindings performed for the purpose of the redirection system as a result of this automated "Returning Home" detection in Mobile IPv4. Instead, deregistration is only initiated by MN 200 when the flooding has subsided.

After registration for redirection, the traffic condition at the victim (MN) 200 is monitored and if flooding continues, the bindings will be updated to prevent them from expiring due to the lifetime of the registrations. Further details on detecting the flooding and its subsidence, and rate limiting after the traffic redirection registration are discussed below. It is noted that even if ingress filtering is in place, reverse tunnelling will not be required for MN 200 to tunnel packets to CN 208 through HA 204 in the example embodiment. This is due to the fact that MN 200 is still within its home network 201.

Turning now to Figure 4, another possible situation for embodiments of the invention is where the redirection scheme is activated while MN 200 is in a foreign network 400. With route optimisation, if MN 200 prohibits the disclosure of its new location (e.g. 'P' bit set to our in registration request to HA 204), CNs 208 will not be informed of MN's 200 CoA. Therefore, MNs 200 implementing the redirection scheme send registration requests with the 'P' bit set to zero in an example embodiments. Other than this change, normal Mobile IPv4 operations will not be affected by the implementation of the redirection scheme. If all CNs 208 are informed of MN's 200 CoA by default through normal Mobile IPv4 registration process, redirection activation will only result in informing HA 204 to perform filtering. However, if the CNs 208 are not informed of MN's 200 CoA initially, traffic redirection and filtering is performed.

The following description considers possible scenarios when the redirection scheme is activated while MN 200 is in the foreign network 400, in example embodiments.

In Figure 4 to 7, the dotted lines represent routes before activation of the redirection scheme and the solid lines represent routes after activation of the redirection scheme.

Figures 4 and 5 show traffic redirection when MN 200, HoA 204, is under attack.

Traffic redirection is performed using co-located CoA 402, 500 acquired by MN 200 in the foreign network 400. In Figure 4 (Traffic redirection using co-located CoA 402 in foreign network 400 (initial binding using co-located CoA 404)), the initial CoA 404 used is a co- located CoA. When the redirection scheme is activated, this CoA is reused as CoA 402 for traffic redirection by informing CN 208 of this 'new' location of MN 200. In Figure 5 (Traffic redirection using co-located CoA 500 in foreign network 400 (initial binding using FA 502 as CoA)), the initial CoA 503 used is FAs 502 address. Therefore, in this situation, MN 200 acquires a co-located CoA 500 to be used for the redirection scheme. This new address 500 is then disclosed to CN 208 so that CN 208 will subsequently tunnel packets directly to MN 200. In both situations, after CN 208 is notified of the co-located CoA 402, 500 of MN 200, HA 204 will be informed to perform filtering for packets with source address, box 406, = CN and destination address, box 408, = MN's HoA. Packets not matching the filtering will be processed normally by Mobile IP and therefore, be tunnelled through to MN 200 or FA 502, as illustrated by Figures 4 and 5 respectively, by HA 204.

Figures 6 and 7 show traffic redirection performed using FA's 602 address as MN's 200 CoA 604, 700 in the foreign network 400 in example embodiments. In Figure 6 (Traffic redirection using FA 602 in foreign network 400 (initial binding using co-located CoA 600)), the initial CoA used is a co-located CoA 600.

When the redirection scheme is activated, MN 200 selects an available FA 602 to perform traffic redirection. CN 208 is then notified of this new CoA 604 (FA's 602 address) and will tunnel subsequent packets for MN 200 to this new location. In Figure 7 (Traffic redirection using FA 701 in foreign network 400 (initial binding using FA 701 as CoA)), the initial CoA 702 used is FA's 701 address. When the redirection scheme is activated, MN 200 informs CN 208 of FA's 701 address as the CoA 700. Therefore, CN 208 subsequently tunnels packets destined to MN's 200 HoA 704 directly to the FA 701. Similar to the above scenarios using co-located CoA for the redirection scheme (Figures 4 and 5), HA 204 will be informed to perform filtering for packets with source address, box 705, = CN and destination address, box 706, = MN's 200 HoA, after CN 208 is notified of the new CoA of MN 200. Packets not matching the filtering will be processed normally by Mobile IP and therefore, be tunnelled through to MN 200 directly, or via FA 701 , as illustrated by Figures 6 and 7 respectively, by HA 204.

1.1.2 Redirection with Mobile IPv6

Figure 8 (Traffic redirection using Mobile IPv6 in protected network) shows the traffic redirection in the home network 800. For an IPv6 network 800, an embodiment of the invention uses the Mobile IPv6 mechanism for performing the traffic redirection. When an attack alarm is triggered, MN 802 obtains a new IPv6 address (CoA 804) and sends a binding update to MN's 802 HA 806 and the chosen CN 808. In this embodiment, the Type 2 Routing Header in IPv6 is used , i.e. this header is set to the original HoA, and the destination address CoA 804 is swapped with the HoA in this header when the packet(s) reach MN 802 so that the final destination address for this packet is HoA. A route optimisation functionality is built-in in Mobile IPv6 and therefore no additional module may be required for implementing the embodiment in the IPv6 network 800.

For the situation whereby MN 802 has moved to a foreign network (not shown), all

CNs 808 would be notified of the new location (MN's 802 CoA) by default in Mobile IPv6. Therefore, MN's 802 HoA 810 should no longer be used as the destination by legitimate CNs 208. In this case, filtering of packets with source addresses equal to selected CNs 208 by the redirection scheme and destination equal to MN's 802 HoA 810 is carried out at HA 806. No additional task is required at the foreign network (not shown) in an example embodiment. In Mobile IPv6, the "returning home" procedure is activated when MN 802 is notified that its home subnet prefix is again on-link, through the router advertisements MN 802 receives. Where MN 802 is still within its home network 800, its home subnet prefix will not be off-link. Therefore, MN 802 takes note not to activate the "Returning Home" procedure if the bindings are due to the redirection scheme activation in the example embodiment. In addition, the traffic condition at MN 802 may be monitored to decide on appropriate refreshing of the binding at CN 808 to prevent the redirection binding from expiring.

1.1.3 Gateways with HA Functionality

With reference to Figure 9, as mentioned earlier, the task of filtering is transferred to HA 900 from the gateway 902 with the use of Mobile IP in example embodiments. This allows for a more effective workload distribution and thus higher scalability. However, by not stopping the DoS/DDoS attacks at the gateways 902, the protected network 904 may sacrifice some resources due to the propagation. Malicious packets may therefore be filtered off at the gateway 902 instead if HA functionality is built-in, to prevent attack flood from entering the protected network 904. Therefore, if the gateways 902 are built with HA functionality in example embodiments, the effect of the attacks on the network 904 can be minimised by filtering off the malicious packets at the "edges" to protect the entire network 904.

1.2 Traffic Congestion and Overloading Detection

The traffic and resource monitoring system is proposed to be implemented on the victim to detect flooding and severe resource consumption at the victim in example embodiments. A simple method can be to observe the resource (e.g. bandwidth and computing resources) utilisation at the victim and to activate the traffic redirection mechanism when a threshold is reached. Another way can be through monitoring gradual depletion of one or more resources at the victim. For traffic monitoring, the aggregate incoming traffic can be observed for checking bandwidth utilisation and traffic growth rate computed, so as to detect seemingly abnormal traffic behaviour in an example embodiment. As e.g. for computing resource monitoring, parameters such as memory consumption can be observed and consumption growth rate computed to detect any signs of attack directed at the victim. The following describes an example embodiment of the bandwidth based detection method in detail.

1) Let X_n (bandwidth or other resources' utilisation in percentage) be the alerting points whereby resource consumption growth rate monitoring has to be started, with n > 0 and X_n > X_n-I > ... > X2 > x-i-

2) Let g_n (consumption growth in percentage) correspond to each X_n whereby an alarm is "sounded" and traffic redirection activated if reached. Detection sensitivity is increased as the resource utilisation gets larger. Therefore, allowable consumption growth rate is set smaller for increasing monitoring stages, g_n < g_n-i < ... < g_∑ < gi

3) Let Δt_n be the sampling rate of each stage (in seconds, n = 0 for sampling rate before first alerting point and n > 0 for sampling rate during alerting stages). Similar to the consumption growth, the detection sensitivity is increased as the alerting point is advanced, Δt_n < Δt_n-i < ... < Δt₂ < At₁ This could be set through the sampling rate by allowing more frequent sampling at later/crucial monitoring stages.

4) Let y be the final alert point or the alarm point, whereby an alarm is immediately "sounded" as soon as the resource utilisation reaches or exceeds this point.

Figure 10 shows a flowchart of the above detection mechanism. After the start (step 1000), the sampling rate is set to Δt₀ (step 1002). The resources utilised (R_u) and the consumption growth (C₉) since the last sample are measured (step 1004). A determination is made (step 1006) whether the resources utilised (R_u) are greater than or equal to y, and, if not, if the resources utilised (R₁₁) are greater than or equal to X_n (step 1008), and, if not, if the resources utilised (R₁₁) are greater than or equal to x_n.i (step 1010) and so on down to whether the resources utilised (R₁₁) are greater than or equal to X₁ (step 1012).

If the resources utilised (R_u) are greater than or equal to y, then an alarm activates traffic redirection (step 1014) and the process ends (step 1016). If the resources utilised (Ru) are not greater than or equal to y, but are greater than or equal to X_n, the sampling rate is set to Δt_n (step 1018). If the resources utilised (R_u) are not greater than or equal to y or X_n, but are greater than or equal to X_n-1, the sampling rate is set to Δt_n-1 (step 1020), and so on until if the resources utilised (R_u) are only greater than or equal to X₁, the sampling rate is set to At₁ (step 1022). If the resource utilised (R_u) are smaller than X₁, the monitoring loops back to step 1004 without changes in the sample rate

If the sampling rate is set to Δt_n, a determination is made whether the consumption growth (C₉) since the last sample is greater than or equal to g_n (step 1024). If the sampling rate is set to Δt_n-1, a determination is made of whether the consumption growth (C₉) since the last sample is greater than or equal to g_n-1 (step 1026) and so on until if the sampling rate is set to At₁, a determination is made of whether the consumption growth (C₉) since the last sample is greater than or equal to g^ (step 1028).

If the determination of the comparison between the consumption growth (C₉) and the relevant consumption growth in percentage (step 1024) yields a negative result, then the process reverts to measuring the resources utilised (R₁₁) and the consumption growth (C₉) since the last sample (step 1004). On the other hand, if the result is positive, the process passes to the alarm and traffic redirection activation step (step 1014) and then ends (step 1016). Similarly, if the results of steps 1026 and 1028 respectively yield a negative result, then the process reverts to step 1004, and if the result is positive, the process passes two steps 1014 and 1016.

Figure 11 shows an example embodiment of a detection mechanism graph 1100 using bandwidth as the resource to be monitored. Simultaneous monitoring of other resources could be carried out, whereby an alarm triggered by any or combination of some of the monitoring systems would result in traffic redirection. The graph 1100 indicates the safe region 1102 (below line), alert region 1104 (70 to 90% bandwidth utilisation) and alarm region 1106, which also includes region on and above lines e.g. 1108 in graph 1100, with the following parameters, assuming alert is started at the 100th sec when bandwidth utilisation reaches X₁, which is 70%, and the sampling rate is set to At₁.

- Δt₀ = 5 sees - X₁ = 70%, X₂ = 80%

- g₁ = 5%, g₂ = 2.5%

- At₁ = 3 sees, Δt₂ = 1 sec

- y = 90% The allowable growth gi = 5% is assumed to not be reached at the 100th sec. At the 103rd sec (At₁ = 3 sees), the maximum allowable bandwidth utilisation before triggering the alarm based on consumption growth is <75%, line 1108. In this example, it is taken to be measured at 73%, dot 1110, which is also still smaller than X₂. Therefore, the next threshold based on consumption growth is set at 78% (g-i = 5%), line 1112. It is assumed that the bandwidth utilised at this sampling time (106th sec) is 77.5%, dot 1114 and the next (109th sec) is at 81%, dot 1116. Although the 82.5% threshold based on consumption growth, line 1118, is not exceeded at the 109th sec, the bandwidth utilised now exceeds X₂ (80%), and therefore, the sampling rate is changed to Δt₂ = 1 sec and the allowable traffic growth to g₂ = 2.5%, i.e 83.5% next threshold, line 1120. The sample at 110th sec shows 82%, dot 1122, and the next allowable traffic growth threshold is set at 84.5%, line 1124. However, at the 111th sec, the bandwidth utilisation is 85% (dot 1126), which has exceeded the consumption growth limit, line 1124, and therefore, the alarm is triggered.

Flooding subsidence

To prevent frequent toggling between activation and deactivation of the redirection scheme, resulting in high overheads, three parameters may be used in an example embodiment to determine if the DDoS attack has subsided. For example, the redirection scheme may only be deactivated if possible resource consumption without the redirection scheme is maintained within an acceptable level (R₃), for at least T_a seconds with a low probability (P_a) of rate limiting at the gateways. Possible resource consumption without the redirection scheme can be measured by totalling resource consumption at the victim, resource conservation due to filtering at HA and resource conservation due to rate limiting at the gateways. The three parameters can be configured by the user, taking into consideration the following equation, for an example embodiment.

Frequency of toggling α (R_a x P_a)/T_a

1.3 Rate Limiting at Gateways After the redirection scheme is activated, resource consumption at the victim may be constantly monitored to adjust the rate-limiting probability at the gateways in the home network. An allowable stable resource consumption level, R_c, is configured at the victim in an example embodiment. The initial probability for rate-limiting, p₀, may be derived from R₀ when the alarm is triggered for the redirection scheme activation. For example, if R_c is 85% of bandwidth and aggregate incoming traffic at the victim is utilising 95% of it's bandwidth, Po will be (95-85)/95, which is approximately 0.1053. This value may be sent to the gateways to perform rate limiting for this particular victim (i.e. destination of packets == victim). Resource consumption, which may be constantly monitored at the sampling rate, Δt_n, as described in Section 1.2 above, may be used for adjusting the probability setting.

One of the main advantages of a redirection scheme according to an embodiment of the present invention over prior mechanisms is that it does not require prior characterisations of good and bad traffic. Embodiments of the invention can provide a Denial of Service / Distributed Denial of Service attacks real-time detection and mitigation system.

The redirection scheme according to an embodiment may be categorised as a reconfiguration mechanism by changing the routes to the victim under attack. However, unlike e.g. SOS, an overlay network and complex algorithms (e.g. chord routing algorithm, consistent hashing) need not be built or implemented. In SOS, only certain destinations are chosen for protection. Direct DoS/DDoS attacks on these destinations are prevented due to filtering to only allow traffic forwarded by selected servlets. However, nodes serving as beacons and servlets could be subjected to these attacks instead. It is recommended in Secure Overlay Services (SOS), for instance as described by A. D. Keromytis, V. Misra, D. Rubenstein, in "SOS: Secure Overlay Services", ACM Sigcomm 2002, to have a large number of nodes serving as beacons and servlets so as to provide redundancy when an attack on the overlay network is going on. Nodes overwhelmed by the attacks would then be "removed" and their jobs will be handled by the remaining active ones. In the redirection scheme according to an embodiment of the invention, on the other hand, any node running the MN module would be able to bring itself under protection in the event of attacks by activating the traffic redirection. Redundancy which results in resource allocation to maintain the network during attacks is therefore not necessary. The processes described can be provided by way of software operating from a single source or distributed over various points or bodies associated with a network such as the Internet. The method and system of an example embodiment can be implemented on a computer system 1200, schematically shown in Figure 12. It may be implemented as software, such as a computer program being executed within the computer system 1200, and instructing the computer system 1200 to conduct the method of the example embodiment.

The computer system 1200 comprises a computer module 1202, input modules such as a keyboard 1204 and mouse 1206 and a plurality of output devices such as a display 1208, and printer 1210.

The computer module 1202 is connected to a computer network 1212 via a suitable transceiver device 1214, to enable access to e.g. the Internet or other network systems such as Local Area Network (LAN) or Wide Area Network (WAN).

The computer module 1202 in the example includes a processor 1218, a Random Access Memory (RAM) 1220 and a Read Only Memory (ROM) 1222. The computer module 1202 also includes a number of Input/Output (I/O) interfaces, for example I/O interface 1224 to the display 1208, and I/O interface 1226 to the keyboard 1204.

The components of the computer module 1202 typically communicate via an interconnected bus 1228 and in a manner known to the person skilled in the relevant art.

The application program is typically supplied to the user of the computer system 1200 encoded on a data storage medium such as a CD-ROM or floppy disk and read utilising a corresponding data storage medium drive of a data storage device 1230. The application program is read and controlled in its execution by the processor 1218. Intermediate storage of program data maybe accomplished using RAM 1220. Figure 13 shows a flowchart 1300 illustrating a method of filtering data transmissions in a network for protection against malicious communication, according to an example embodiment. At step 1302 one or more apparent originating addresses sending communications to a first electronic address over a first path are determined. At step 1304, the determined apparent originating addresses are instructed to redirect future communications intended for the first electronic address to a second path. At step 1306, communications sent from the determined apparent originating addresses to the first electronic address over the first path are filtered out.

It will be appreciated by a person skilled in the art that numerous variations and/or modifications may be made to the present invention as shown in the specific embodiments without departing from the spirit or scope of the invention as broadly described. The present embodiments are, therefore, to be considered in all respects to be illustrative and not restrictive.

Claims

1. A method of filtering data transmissions in a network for protection against malicious communications, the method comprising: determining one or more apparent originating addresses sending communications to a first electronic address over a first path; instructing the determined apparent originating addresses to redirect future communications intended for the first electronic address to a second path; and filtering out communications sent from the determined apparent originating addresses to the first electronic address over the first path.

2. A method according to claim 1 , wherein the first path comprises first routing information to the first electronic address, and the second path comprises different, second routing information to the first electronic address.

3. A method according to claim 2, wherein the filtering is performed at the first gateways of the network, at routers of the network, or both.

4. A method according to claim 1 , wherein the second path comprises a second electronic address for sending the communication intended for the first electronic address to the second electronic address.

5. A method according to claim 4, wherein the second electronic address is a co-located electronic address in the network or a co-located foreign agent address in the network.

6. A method according to claim 4, wherein an entity associated with the first electronic address is in a foreign network when the redirection is instructed, and the second electronic address is an electronic address in the foreign network or a foreign agent address in the foreign network.

7. A method according to claims 4 or 5, further comprising routing communications to the first electronic address utilising a proxying home agent in the network.

8. A method according to claim 6, further comprising tunnelling communications to the entity associated with the first electronic address via an electronic address in the foreign network or the foreign agent in the foreign network utilising a proxying home agent in the network.

9. A method according to claims 7 or 8, wherein the filtering is performed at the home agent in the network.

10. A method according to claim 9, wherein the home agent is implemented in a gateway with home agent functionality, and the filtering is performed at the gateway.

11. A method according to any one of the preceding claims, wherein determining the apparent originating addresses is based on amounts of data sent to the first electronic address from respective addresses.

12. A method according to any one of claim 11 , wherein determining the apparent originating addresses comprises identifying addresses from which a higher than a threshold amount of data is sent to the first electronic address.

13. A method according to any one of claim 11 , wherein determining the a appppaarreenntt o orriiggiinnaattiinngg a adαdαrreesssseess c coommpprriisseess i ιdαeenπtuifτyyiιnπgg a adαdαrreesssseess f τrroomm w whπiicchπ a a h πiigghπeerr t mhaann a ann a avveerraaαgee a ammoouunntt o off d daattaa f frroomm r reessnpeencttiivvfie a addddrreesssseess i iss s seenntt t tno t thhee f fiirrsstt e ellfe?rc.ttrrnonniirc. a addddmresss.

14. A method according to any one of claim 11 , wherein determining the apparent originating addresses comprises identifying addresses ranked from a highest amount of data sent to the first electronic address by respective addresses.

15. A method according to any one of the preceding claims, wherein the network comprises the Internet.

16. A method according to any one of the preceding claims, comprising instructing only the determined apparent originating addresses to redirect future communications intended for the first electronic address to the second path.

17. A method according to any one of the preceding claims, wherein the apparent originating addresses comprise one or more spoofed addresses, whereby malicious communications from addresses from which the communications associated with the spoofed addresses are sent are filtered out after the redirection instruction.

18. A method according to any one of the preceding claims, further comprising conducting a resource utilisation monitoring process, and the determining, instructing and filtering steps are commenced based on the monitoring process.

19. A method according to claim 18, wherein the monitoring process comprises measuring the resource utilisation; and measuring a consumption growth in the resource utilisation.

20. A method according to claim 19, wherein the monitoring process comprises: setting an initial sampling rate; measuring the resource utilisation; measuring the consumption growth in the resource utilisation since a last sample; and activating an alarm based on the measured resource utilisation; or setting a new sampling rate based on the measured resource utilisation and activating the alarm or returning to loop to the measuring of the resource utilisation based on the measured growth rate.

21. A method according to any one of the preceding claims, wherein the filtering is activated based on receipt of respective acknowledgement messages from the apparent originating addresses.

22. A method according to claim 21 , wherein the filtering is activated after the respective acknowledgement messages are received or after the respective acknowledgement messages have not been received within a selected time period.

23. A method according to any one of the preceding claims, further comprising rate-limiting traffic to the first electronic address using the first path.

24. A method according to claim 23, wherein the rate-limiting traffic step comprises dropping packets at a selected probability.

25. A method according to claim 24, wherein the probability is selected based on a current resource utilisation.

26. A system of filtering data transmissions in a network for protection against malicious communications, the system comprising: means for determining one or more apparent originating addresses sending communications to a first electronic address over a first path; means for instructing the determined apparent originating addresses to redirect future communications intended for the first electronic address to a second path; and means for filtering out communications sent from the determined apparent originating addresses to the first electronic address over the first path.

27. A system of filtering data transmissions in a network for protection against malicious communication, the system comprising: a detector determining one or more apparent originating addresses sending communications to a first electronic address over a first path; a processor executing an application program to instruct the determined apparent originating addresses to redirect future communications intended for the first electronic address to a second path; and a filter filtering out communications sent from the determined apparent originating addresses to the first electronic address over the first path.

28. A data storage medium having stored thereon computer readable code means for instruction a computer to execute a method of filtering data transmissions in a network for protection against malicious communications, the method comprising: determining one or more apparent originating addresses sending communications to a first electronic address over a first path; instructing the determined apparent originating addresses to redirect future communications intended for the first electronic address to a second path; and filtering out communications sent from the determined apparent originating addresses to the first electronic address over the first path.