A Two-Level Source Address Spoofing Prevention ... - Semantic Scholar

A Two-Level Source Address Spoofing Prevention based on Automatic Signature and Verification Mechanism Yan Shen, Jun Bi, Jianping Wu, and Qiang Liu Network Research Center, Tsinghua University China Education and Research Network (CERNET) Beijing 100084, China

Abstract IP source address spoofing is used by DDoS and DrDoS attacks in the Internet. This paper presents a signature-and-verification based IP spoofing prevention method, Automatic Peer-to-Peer Based Anti-Spoofing Method (APPA). APPA has two levels: Intra-AS (Autonomous System) level and Inter-AS level. In the Intra-AS level, the end host tags a one-time key into each outgoing packet and the gateway at the AS border verifies the key. In Inter-AS level, the gateway at the AS border tags a periodically changed key into the leaving packet and the gateway at border of the destination AS verifies and removes the key. The most prominent characteristic ofAPPA is the automatically synchronizing state-machine, which is used to update keys automatically and effectively. The benefits of APPA are: (1) preventing IP address spoofing strictly, end systems can't even spoofaddresses in the same AS or subnet, (2) providing very low running and management costs, (3) supporting anti-replay attacks and incremental deployment.

1. Introduction IP source address spoofing is used in many attacks in the Internet, such as some DDOS/DrDoS attacks. In DDOS/DrDOS attacks, spoofing source IP address is used to: (1) Amplify the attacks such as DNS amplification attacks [1][2][3]; (2) Weaken victim's defensive ability since the victim can't filter the abnormal packets by IP source address, such as TCP SYN Flooding [4]; (3) Conceal the real attacker. According to the research of [5], about 3000-4000 large-scale DDOS attacks were launched every week. Botnets and SPAM became a serious problem in modem internet. A Cisco research report [6] shows that by Nov 2006 the traffic of SPAM is about 7.8 times

more than the normal traffic in Internet. The scale of botnets is increasing fast and can't be controlled unless IP spoofing is stopped. Many methods have been proposed to prevent IP address spoofing, such as Ingress Filtering [7], uRPF [8], SPM [9]. However, these mechanisms all have some deficiencies, which lead to the fact that none of them has been widely deployed. Besides, current methods can't prevent spoofing in a fine granularity. We still need a safe, efficient mechanism with a fine granularity. This paper presents a signature-and-verification based IP source address spoofing prevention method, Automatic Peer-to-Peer Based Anti-Spoofing Method (APPA). APPA has two levels: Intra-AS level and Inter-AS level. In the Intra-AS level, the end host tags a one-time key into each departing packet and a gateway verifies the key. In Inter-AS level, the router at the source AS border tags a periodically changed key into the leaving packet and the one at the border of the destination AS verifies and removes the key. The most prominent characteristic of APPA is the automatically synchronizing state-machine, which is used to update keys automatically and effectively. The benefits of APPA are: (1) preventing IP address spoofing strictly, end systems can't even spoof addresses in the same AS or subnet, (2) providing very low running and management costs, (3) supporting anti-replay attacks and incremental deployment. The presented method is proposed to be considered in IPv6 protocols design and deployment. The rest of this paper is organized as follows. Section 2 introduces related work. Section 3 presents the state machine based key generation and verification process for APPA, section 4 discusses the details of APPA solution, section 5 analyzes the security and performance issues and carry out some comparison, and section 6 concludes the paper.

978-1-4244-2703-1/08/$25.00 ©2008 IEEE 392

Authorized licensed use limited to: Tsinghua University Library. Downloaded on January 5, 2009 at 10:59 from IEEE Xplore. Restrictions apply.

2. Related Work Many Inter-AS level methods have been proposed. Some of them are based on internet topology, such as uRPF, Ingress Filtering and traceback. Others are signature and verification based methods like SPM, Hop-Count [10], and Authentication Header [11]. Up to now there are a few methods focusing on prevent spoofing in Intra-AS or subnet level, such as [12]. Traceback methods trace the real source of the packet instead of filtering spoofed packets. When the victim network is attacked, traceback mechanism starts to trace the real source of the packets. There are three ways used by traceback to find the real source of the packets in general. The first way is that the routers transmitting the packets tag information into them, so the victim could retrieve the route according to the tagged information [13][14][15]. The second way is that the router sends ICMP packets to the destination as soon as it transmits ordinary packets, so the destination could keep awareness of the packet's real source [16] [17]. The third way is that the router keeps the digest of the packets transmitted by itself, so the victim could trace the source of the packet according to the digest information [18][19]. Traceback needs the cooperation among all the nodes on the packets' route. If it is partly deployed, it may fail to rebuild the route or build an imprecise route. Besides, it can't provide real time attack prevention or damage mitigating. Ingress Filtering and uRPF based method both filter packets according to the reverse route table information. Points on the same route could spoof each other's IP address even if the mechanisms are fully deployed. Hop-Count, Authentication Header and SPM are signature and verification based methods. In HopCount, the destination infers the final TTL value in the packets coming from each AS by a special algorithm. Packets with wrong TTL values will be filtered. This method is very easy to implement and works independently. However, its essence is to use TTL as the authentication key. As TTL field only has 8 bits, experienced attackers could easily get the right TTL value to tag into packets by brute enforcement. Authentication Header is designed for the secure session between two end systems and could also be used for IP source address verification. The authentication header which is produced from heavy computation is tagged at the source and verified at the destination. However, as a method for anti-spoofing, its cost is too heavy hence not DOS-resilient. If the attackers pretend to be the end system which is in a session with the victim and sends spoofed packets to the victim, the victim would perform heavy computation on each packet to verify its authenticity and exhaust its resource. SPM is a lightweight method,

but its key-updating mechanism is not attack-resilient. Passport [20] is a new signature-and-verification method, the packet leaving an AS is tagged with several keys, and each router in the path verifies its corresponding key. But its overhead is heavy and will cause a waste of network bandwidth. Most of the current methods can't stop spoofing on a fine granularity. Attackers could easily spoof IP address in the same domain. The method proposed in this paper could prevent spoofing strictly and support incremental deployment, its cost is lightweight.

3. The State-machine based Generation and Verification

Key

3.1 The characteristics of State-machine based Key Generation and Verification As a signature-and-verification method, APPA tags a key into each packet at the source and verifies the key at the destination. The key is used only in one packet and will be changed in the next one. This scheme makes APPA an anti-replay method. As each packet needs a unique key, there must be a way to produce keys rapidly at the source and verify keys rapidly at the destination. That is The State Machine (TSM). It has many states and the state transforms from one to another under certain conditions. Each state is mapped into one key by an algorithm. The transition between states brings the change of the key. Sending a packet triggers the state transition at the source while receiving a packet with the right key does the same at the destination, as shown in figure 1. TSM at source tags a key in each packet q2 ql qO

TSM at destination verifies the key qO ql q2 O~()===:t()·

···OF==O~O

.

transtktl) + key2

key!

keyO

keyO

key!

key2

Figure 1. TSM The state machine produces keys at the source and verifies keys at the destination. Each key is mapped to one state of the state machine. TSM must satisfy the following characteristics in consideration of efficiency and safety: 1. The states of TSM must be huge in number and the cycling periods must be very long. 2. Same TSMs make the same key sequence. The destination could easily use the same TSM as the

393

Authorized licensed use limited to: Tsinghua University Library. Downloaded on January 5, 2009 at 10:59 from IEEE Xplore. Restrictions apply.

3.

4. 5.

source to verify keys. It is hard to infer the TSM from known key sequence. This makes TSM safe against eavesdropper. It is fast and lightweight to produces keys. The space requirement of TSM is light-weighted. The number of TSM must be huge since attackers may guess the TSM by brute-force.

3.2 The Design of State-Machine In summary, the 5 characteristics of TSM are fast, large state space and long period, lightweight space, not inferable and large choice space. We discuss some possible implementations and give an excellent one. Hash-Chain [21] is one possible implementation, but it is not fast enough and the space requirement is not light-weight, so it's not a good implementation. As analyzed in our former paper[22], we use good RNGs (Random Number Generators) to implement the TSM, such as KISS[23], Mersenne Twister[24]. We use two RNGs to generate two sequences of random numbers, each pair of which denotes one state of the TSM. The key comes from a XOR computation of two counterpart random numbers. This is similar to the One-Time-Pad (OTP) stream cipher mechanism [25] in cryptology. Because the key changes after each packet, TSM requires that the disorder and missing of packets not be serious. But packets may get lost or become disordered in real environments. We will solve this problem in the next section.

4. APPA

4.1 Inter-AS and Intra-AS

Figure 2. The two-level APPA Scheme As mentioned in the last section, in APPA, TSM produces a unique key for each packet. But the packets

can't reach the destination in serious disorder or miss a lot. Within a small scale of network like a subnet, this requirement can be easily met. But between different ASes, packets may become disordered or get lost in the route due to many reasons such as QoS or congestion control. So we need two sets of mechanisms for different scenarios. Besides, a hierarchical structure will help with increment deployment. Thus, we proposed APPA solutions on two levels: Inter-AS and Intra-AS. In Inter-AS level, the border router in the source AS tags a periodically changed key into each packet and the border router in the destination AS checks the key. In Intra-AS level, the end-system tags a unique key into each packet and a gateway verifies the authenticity of the key. The difference between Inter and Intra-AS is that key changes in each packet in Intra AS level while it changes periodically in Inter-AS level. The whole APPA solution is shown in Figure 2.

4.2 The Inter-AS level The Inter-AS level is used to enforce incremental deployment among ASes, which has the following steps: 1. Exchange TSM. Gateway in AS A sends its TSM (A, B) to the gateway in AS B and also receives TSM (B, A) from B. This exchange process could be carried out with a security method such as Diffle-Hellman protocol. 2. Synchronization. A and B start APPA at the same time. It is important to synchronize the TSMs between two ASes so we have special strategy described in the following part. 3. Tag and verify key. A produces key (A to B) with TSM (A, B) and key (B to A) with TSM (B, A), then save them in out-table and in-table respectively for future look-up. 4. Update key. Keys are updated every 200 seconds. The reason to update keys is that keys may be revealed by accident such as brute-force guessing or eavesdropping. Changing keys frequently could mitigate the threat of key disclosure. Synchronized clocks of TSMs between ASes are important. If there is only a tiny timing difference between two ASes, then setting a critical time could easily solve the problem. In the critical time both the old key and the new key are allowed. But if the timing difference if large or clock drifting exists between two ASes, we need to recover the synchronization before things get worse. To recover the synchronization, each AS pair maintains two special TSMs, one for sending and the other for receiving. Recovery-packet is used for resynchronization. Special TSM generates keys to tag in

394

Authorized licensed use limited to: Tsinghua University Library. Downloaded on January 5, 2009 at 10:59 from IEEE Xplore. Restrictions apply.

recovery-packet, which is sent periodically such as every 100,000 seconds. SPM is a similar method to APPA Inter-AS level. We have compared SPM with APPA Inter-AS level in [22]. The conclusion is that APPA Inter-AS is much safer and more efficient.

4.3 The Intra-AS level The Intra-AS level is designed to prevent spoofing within the same AS or subnet. Some attacks are based on IP spoofing within the same subnet, like imputation attacks. These attacks may not be serious today, but may become a problem in the foreseeable future. The Intra-AS mechanism will help solve the problem. It works as follows: 1. Get IP address and TSM. When the end system connects to the Internet, it receives a TSM from the gateway which is bound with the host's IP address. The place of the gateway will be discussed in the following part. 2. Tag key. The end system tags a unique key into each packet. Each key is used only in one packet. Keys are generated by the TSM. As each key is used only in one packet, it significantly mitigates the threat of sniff. 3. Verify the key. The gateway verifies the key to check if the source IP address is spoofed. The same TSM is used to verify the key. Not many methods can prevent spoofing in IntraAS level. APPA Intra-AS level is more efficient than [12] and the performance on anti-replay is perfect, since the verification is quite light-weight (a table look-up) and every key is used only once. Because the key is changed after each packet, the strict order of the keys is very important. We've got two problems here. 1. In intra-AS level, as keys are tagged at the end-system and verified at the gateway, the location of the gateway must be carefully selected. 2. How to resynchronize the system when packet loss or disorder happens. The 'gateway' is a virtual conception. It may be a device or a system with several devices, depending on the implementation. It is supposed to be near to end-systems, such as the first router. The end-system sends packets with keys and the keys are verified in this 'gateway'. The ratio of packets loss or disorder from the same end-system can't be serious. If the packet loss or disorder is not serious, we can use a sliding-window with size 32 to deal with the situation, which is similar to AH of IPSec. We've done an experiment in the scenario that there is a router between the 'gateway' and end-systems. The result shows that a sliding-window with length 32 is resilient to packet loss or disorder. We suggest deploy APPA Intra-AS level at the first layer-3 hop (e.g. the first

router on the path), then spoofed packets could be filtered as soon as possible. To recover synchronization, the synchronization-recovery mechanism used in InterAS level could be used here too. The most prominent feature of Inter-AS solution is that it prevents replay naturally. Each key is used only once, hence replay a key is not better than guess a key. We use a 32-bit key so it is almost impossible to replay successfully. This replay-prevention scheme is much better than traditional anti-replay methods such as Time-Stamp and Sequence Number.

4.4 Combination of Intra-AS and Inter-AS To achieve better efficiency and incremental deployment, we combine Intra-AS with Inter-AS level together, which has the following work steps: 1. End system tags a unique key into each packet. TSM produces the key. 2. The gateway checks the Intra-AS key and discards the packet if the key is wrong. 3. The border router checks the destination IP address of the packet to see if the destination AS has deployed APPA. If not, the packet is directly transmitted. Otherwise the Inter-AS key is retrieved. 4. The border router tags the Inter-AS key retrieved in step 3 into the packet, and then transmits it. S. The border router in destination AS verifies the Inter-AS key of the packet. Inter-AS keys change every 200 seconds.

4.5 Anti-sniff in Inter-AS level The key is changed periodically in Inter-AS level, so it may not be safe enough when sniffing exists. It is not feasible to use the same one-time-key mechanism as Intra-AS level because packets disorder problem is serious in Inter-AS level. To solve this problem, we have proposed a solution in [22], which takes advantage of the algorithms in [26] [27]. However, we didn't implement this mechanism in our prototype because it brings unnecessary complexity and we suppose it's hard to compromise routers.

4.6 Other Considerations The length of the key is variable and we think currently 32-bit key is safe enough. It could be tagged in IP extension header in IPv6 and IP option field in IPv4. Although APPA could be used in both IPv4 and IPv6, we strongly propose to deploy it in IPv6, because it is not feasible or cost-effective to change the current IPv4 infrastructure.

395

Authorized licensed use limited to: Tsinghua University Library. Downloaded on January 5, 2009 at 10:59 from IEEE Xplore. Restrictions apply.

5. Analysis and Experiments 5.1 Feasibility and Safety In Intra-AS level, the gateway maintains the following data for each host: one TSM for sending, one TSM for receiving and another TSM for spare. Each TSM needs 256 bits for basic information, 32 bits for sequence number, and 32*32 bits for signature (32 bits) and its sliding-window. The total memory is less than 1.5K bits for each host. An AS with 10,000 hosts needs about 15M bits of memory spaces at the gateway. The most important intention of the experiment is to verify if one-time-key mechanism works at Intra-AS level. The experiment is carried out in Tsinghua campus network, between the hosts and the gateway there are 4 hops. 1000 processes on 40 computes simulate 1000 hosts to send packets with APPA IntraAS solution. The gateway handled the packets effectively and the one-time-key mechanism worked well. Large-scaled experiment will be done in future. In Intra-AS level, attackers can't replay the keys or packets because each key is only used once. We developed a prototype and proved the safety in IntraAS level with an experiment. In the experiment, B replays the key used by A and guess the key to spoof A's address. B tried 10,000,000 spoofed packets and only 1 packet was accepted by the gateway, so the probability of success was 1x 10-7 • Since the key is 32bit, the theoretic probability is about9.3x 10-10 •

of DOS attack. APPA updates keys fast and stably, each packet has a unique key hence eavesdropping doesn't effect. 2. SPM can't prevent spoofing in the same AS while APPA could.

5.2 Performance In Intra-AS level, TSM is deployed at both the endsystem and the gateway. At the end system, TS~ can produce over 2 million keys per second, so It can support a transmission speed of 2 million pps. At the verification gateway, the computing cost comes from key verification. In Inter-AS level, TSM is deployed at the border routers of ASes. At the border router, the computing cost comes from key tagging. In our prototype (Linux, PMl.6 CPU with IG memory) .the gateway deployed with APPA Intra-AS mechanIsm could deal with about 309m bits per second. The border router deployed with APPA Inter-AS mechanism could deal with about 231m bits per second. So it is light-weighted and feasible. Besides, if the entire Internet deploys APPA Intra-AS mechanism, the Inter-AS level could be cancelled and the bandwidth between ASes will be loseless. Location

Bandwidth (mb/S)

Border Router

1024

Border Router( with APPA Inter-AS mechanism) Gateway( with APPA Intra-AS mechanism) Border Router (fully deployed, InterAS level is cancelled)

231 309 1024

Figure 4. The Bandwidth Comparison

6. Conclusion and Future Work

Figure 3. Host B wants to spoof Host A's address by guessing A's key or replaying A's key. Host B sends over 10,000,000 spoofed packets and only 1 of them is accepted by the gateway. APPA is much safer than SPM because: 1. SPM key-update can't be very fast due to the negotiation process, which is not stable and may become the target

Because the current Internet addressing architecture does not verify the source address of packets received and forwarded, it is difficult and not cost-effectively to change from the current Internet infrastructure. The development of the IPv6 based next generation Internet will give us the opportunity to implement new source address validation architecture. This paper presents a tag-key-and-verify-key based two-level IP source address anti-spoofing method, APPA. The state machine is used to produce and verifies keys automatically. In Intra-AS level, APPA produces a unique key for each packet and hence could prevent spoofing in the same AS and disable the replay attacks. In Inter-AS level, APPA changes keys frequently and makes it attack-resilient. APPA is ligh~­ weighted and supports incremental deployment. It IS

396

Authorized licensed use limited to: Tsinghua University Library. Downloaded on January 5, 2009 at 10:59 from IEEE Xplore. Restrictions apply.

also a feasible method to prevent IP source address spoofing strictly. The presented method is proposed to be considered in IPv6 protocols' design and deployment. In the future work, we will focus on designing the whole protocol and improving the performance of APPA to make it safer and more light-weight.

7. References [1] US-CERT report, "The Continuing Denial of Service Threat Posed by DNS Recursion", 2006. [2] SSAC Advisory SAC008, "DNS Distributed Denial of Service (DDOS) Attacks", 2006. [3] CERT Advisory CA-98.01. "Smurf IP denial-of-service attacks", 1998, http://www.cert.org/advisories/CA-98Ol.html [4] CERT Advisory CA-96.21. "TCP SYN flooding and IP spoofing", 2000, http://www.cert.org/advisories/CA-9621.html [5] D.Moore, G.Voelker and S.Savage, "Inferring internet Denial-of-Service activity", in Proc. USENIX Security Symposium, 2001. [6]http://www.cisco.com/univercd/cc/td/doc/product/lan/cat3 750/index.htm [7] P.Ferguson and D.Senie, "Network ingress filtering: Defeating denial of service attacks which employ IP source address spoofing", 2000, RFC 2827. [8] Cisco IDS, "Unicast reverse path forwarding", 1999. [9] A.Bremler-Barr and H.Levy, "Spoofing Prevention Method", in Proceedings of IEEE INFOCOMM 2005. [10] CJin, H.Wang, and K.G. Shin, Hop-count filtering, "An effective defense against spoofed DDoS traffic", in Proceedings of ACM CCS 2003. [11] S.Kent, "IP Authentication Header, RFC 4302", 2005. [12] L.Z. Xie, J.Bi, J.P. Wu, "An Authentication Based Source Address Spoofing Prevention Method Deployed in IPv6 Edge Network", Lecture Notes in Computer Science, Vol. 4490, pp801-808, 2007. [13] Daw, X.Song and A.Perrig, "Advanced and authenticated marking schemes for IP traceback", in Proceedings IEEE INFOCOMM 2001. [14] K.Park and H.Lee, "On the effectiveness of probabilistic packet marking for IP traceback under denial of service attack", Tech. Rep. CSD-00-013, Department of Computer Sciences, Purdue University, 2000. [15] M.Adler, "Tradeoffs in probabilistic packet marking for IP traceback", in Proceedings of 34th ACM Symposium on Theory of Computing (STOC), 2002. [16] Belenky and Ansari, "On IP Traceback. IEEE Communications Magazine",Volume 41, Issue 7, July 2003. [17] S.Bellovin, M.Leech, and T.Taylor, "Icmp traceback messages", IETF draft, 2003. [18] A.Snoeren, C.Partridge, L.Sanchez, CJones, F.Tchakountio, B.Schwartz, S.Kent, and W.Strayer, "Singlepacket IP traceback". ACM/IEEE Transactions on Networking, Dec.2002. [19] W.T.Strayer, C.EJones, F.Tchakountio, and R.R.Hain, "SPIE-IPv6: Single IPv6 Packet Traceback", IEEE Conference on Local Computer Network 2004.

[20] X.Liu, X.W.Yang, D.Wetherall, and T.Anderson, "Efficient and Secure Source Authentication with Packet Passports", 2nd USENIX Steps to Reduce Unwanted Traffic on the Internet workshop (SRUTI 2006), pp7-13, San Jose, CA, July 2006. [21] H.Y.Chun, M.Jakobsson, A.Perrig, "Efficient Constructions for One-way Hash Chains", 2003, CMU-CS03-220. [22] Y.Shen, J.Bi, J.P.Wu, Q.Liu, "The Automatic Peer-toPeer Anti-Spoofing Method", Lecture Notes in Artificial Intelligence, Vol. 4692, pp855-863, 2007. [23] G. Marsaglia, "The KISS generator", http://oldmill.uchicago.edul--wilder/Code/random/Papers/Ma rsaglia_2003.html. [24] Matsumoto and Nishimura, "Mersenne twister: A 623dimensionally equi distributed uniform pseudo-random number generator", ACM Trans. Model. Comput. Simul. Vol. 8, No.1, 3-30, 1998. [25] MJ.B Robshaw, "Stream Ciphers", RSA Laboratories Technical Report TR-701, July 23, 1995. [26] Baptista M.S. "Cryptography with chaos" [J].Physics Letters A,1998,50-54. [27] L. Fan, P. Cao, J. Almeida, and A. Z. Broder. "Summary cache: A scalable wide-area web cache sharing protocol". Technical Report 1361, Department of Computer Science, University of Wisconsin-Madison, 1998.

397

Authorized licensed use limited to: Tsinghua University Library. Downloaded on January 5, 2009 at 10:59 from IEEE Xplore. Restrictions apply.