1. Introduction to IP Traceback 交通大學 電信系 李程輝 教授 2004/3/26

2. 2 Outline  Introduction  Ingress Filtering  Packet Marking  Packet Digesting  Summary

3. 2004/3/263 Introduction

4. 2004/3/264 Introduction  Internet becomes ubiquitous The impact of network attackers is getting more and more significant  Two kind of attackers A few well-targeted packets  Ex: Teardrop attack Denial-of-service (DoS) & distributed DoS (DDoS)  Typically conducted by flooding network links with large amounts of traffics

5. 2004/3/265 DDoS (a) Direct DDoS (b) reflector attacker

6. 2004/3/266 The Difficulty to Catch the Attacker  The anonymous feature of the IP protocol Can’t identify the true source of an IP datagram if the source wishes to conceal it Solution ： ingress filtering  Somewhere spoofed source address are legal Network address translators (NATs) Mobile IP

7. 2004/3/267 IP Traceback Problem  IP traceback problem The problem of identifying the source of the offending packets Source means  Zombie  Reflector  Spoofed address  Ingress point to the traceback-enabled network  One or more compromised routers within the enabled network

8. 2004/3/268 IP Traceback Problem - Solution  Packet marking To cope with DDoS attacks Router marks packets with it’s identifications Victim can reconstruct the attack path if sufficient number of packets are collected  Packet digesting For attacks that require only a few packets Require storage of audit trails on the routers Victim ask routers if the offending packet passed before

9. 2004/3/269 Evaluation Metrics for IP Traceback Technique (1)  ISP Involvement  Number of Attacking Packets Needed for Traceback  The Effect of Partial Deployment  Processing Overhead  Bandwidth Overhead  Memory Requirements  Ease of Evasion

10. 2004/3/2610 Evaluation Metrics for IP Traceback Technique (2)  Protection  Scalability  Number of Functions Needed to Implement  Ability to Handle Major DDoS Attacks  Ability to Trace Transformed Packets Network Address Translation (NAT) Tunneling ICMP packet Duplication of a packet in multicast

11. 2004/3/2611 Ingress Filtering

12. 2004/3/2612 Ingress Filtering  Limit source addresses of IP datagrams from a network to addresses belonging to that network  If ingress filtering is not deployed everywhere attackers can still spoof any address on the Internet

13. 2004/3/2613 Why Don’t People Run Ingress Filtering ？  It is easy! It improves security! Why not run it? Some people run it in current routers It is implemented in the slow path in the software not the hardware It is easy  For the routers close to the edge of the networks where addressing rules are well defined It becomes complex and inefficient  For transit networks where packets with a different source address can enter the network in multiple locations

14. 2004/3/2614 Packet Marking

15. 2004/3/2615 Packet Marking  Probabilistic packet marking (PPM)  ICMP traceback (iTrace)  Deterministic packet marking (DPM)

16. 2004/3/2616 Probabilistic Packet Marking  Routers mark packets that pass through them  Packets for marking are selected with probability p=0.04

17. 2004/3/2617 Router Marking

18. 2004/3/2618 Pros & Cons  Pros High stability Still can work under partial deployment No bandwidth overhead Low network processing overhead (decide which packet should be marked)  Cons Only for DoS & DDoS attacks Victim requires high memory and high processing overhead Without authentication mark spoofing may happen

19. 2004/3/2619 Ability to Trace Transformed Packets  Can handle packet modification transformation of the packets directed to the victim  The ID field used for fragmentation is used for the mark If a single fragment of the original datagram is marked  The reassembly function would fail at the destination Solution: select a lower probability of marking for fragmented packet  Tunneling may create a problem for reconstruction If marks are extracted before the outer header is removed

20. 2004/3/2620 ICMP Traceback (iTrace)  ICMP traceback message (iTrace) Next hop Previous hop Timestamp As many bytes of the traced packet TTL=255

21. 2004/3/2621 “Intension-Driven” iTrace  Attack[V] =1, victim V is attacked  Intension[V] =1, victim V wants to receive ICMP traceback message  Received[R→V] How many iTrace messages from router R to victim V have been received  Generated[R] The number of iTrace messages generated by router R for all destinations  The value of ICMP packet can be a function of

22. 2004/3/2622 Architecture  Introduce a new bit – intension bit  The intension bit in routing table will set to 1 if one has intension to receive ICMP packet  Decision Module “Choose” one from routing table prefer the one with the highest value

23. 2004/3/2623 Pros & Cons  The pros and cons of iTrace is similar to that of PPM  Except iTrace has bandwidth overhead ； PPM has no bandwidth overhead Without authentication fake ICMP packet may be generated more easily

24. 2004/3/2624 Deterministic Packet Marking  Each packet is marked when it enters the network  Only mark Incoming packets  Mark ： address information of this interface  16 bit ID + 1 bit Reserved Flag

25. 2004/3/2625 The Information of Marks Pad Ideal hash

26. 2004/3/2626 Reconstruction Process  area  Each area has k segments  Each segment has bits area

27. 2004/3/2627 PPM vs. DPM  Mark spoofing (PPM) Use coding technique (but not 100%) (DPM) Spoofed mark will be overwritten  The received information (PPM) Full path (DPM) Address of the ingress router

28. 2004/3/2628 Packet Digesting Source Path Isolation Engine (SPIE)

29. 2004/3/2629 Packet Digesting  Compute digest over The invariant portion of the IP header (16 bytes) The first 8 bytes of the payload (8 bytes) 24 bytes  sufficient to differentiate all packets

30. 2004/3/2630 Prefix Length & Collision Probability  A WAN trace from an OC-3 gateway router  A LAN trace from an active 100Mb Ethernet segment

31. 2004/3/2631 Bloom Filter (1)  A technique that simply stores the digests ＊ For each packet arrived Step-1 Use k different hash function computes k independent n-bits digests Step-2 Set the corresponding bits in the bits digest table

32. 2004/3/2632 Bloom Filter (2)  If any one of them is zero The packet was not stored in the table  If all the bits are one It is highly likely the packet was stored It is possible that some set of other insertions caused all the bits to be set  Restriction Can only store a limited number of digests Saturated filters can be swapped out for a new, empty filter Change to a new filter  loss the previous digest information

33. 2004/3/2633 Architecture (1)  Data Generation Agent (DGA)  SPIE Collection and Reduction Agents (SCARs)  SPIE Traceback Manager (STM)

34. 2004/3/2634 Architecture (2)  DGA SPIE enhanced router 1. produce packet digest 2. store digests table annotated – time & hash function  SCARs Concentration points for several routers 1. produce local attack graph

35. 2004/3/2635 Architecture (3)  STM Control the whole SPIE system The interface to requesting packet trace 1. verifies the authenticity 2. dispatch the request to the appropriate SCARs 3. gather the resulting attack graphs 4. complete the attack graph 5. replies to the IDS

36. 2004/3/2636 Traceback Processing IDS determine an exceptional event has occurred STM cryptographically verifies its authenticity SCAR poll its DGAs & produce partial attack graph packet, P ； victim, V ； time of attack, T P ； V ； T another SCAR T ’ – the packet enter the region P ’ – the entering packet V ’ – the border router between the two network terminate no yes

37. 2004/3/2637 Graph Construction  Reverse path flooding R8 ； R9 R7 R4 ； S5 ； R5 R3 ； R2  The SCAR don’t need to query DGAs sequentially

38. 2004/3/2638 Ability to Trace Transformed Packets (1)  Transform lookup table (TLT) Record sufficient packet data at the time of transformation to allow the original packet to be reconstructed 1 st field ： a digest of the transformed packet 2 nd field ： the type of transformation (include a flag I) 3 rd field ： a variable amount of packet data

39. 2004/3/2639 Ability to Trace Transformed Packets (2)  Flag I (indirect flag) (1)For some transformations, such as NAT, the 32bits data field is not enough.  Set I=1, the third field is treated as a pointer (2)In many case (e.g., tunneling or NAT), packets undergoing a particular transformation are related  It is possible to reduce the storage requirement by suppressing duplicate packet data  Flag I is used for flow caching, or at least identification, so that the packets within the flow can be correlated and stored appropriately.

40. 2004/3/2640 Summary

41. 2004/3/2641 Summary  In recent years much interest and consideration have been paid to the topic of securing the Internet infrastructure  To detect the offending packets IDS (Intrusion Detection System) becomes more and more important  Detecting the offending packets (IDS)  find out attackers (IP traceback)  Several methods have been proposed Each has its own advantages and disadvantages None of the methods described has been used on the Internet When economic or political incentives become strong enough to justify deployment of IP traceback, some new requirements and metrics for evaluation might emerge

42. 2004/3/2642 References  R. K. C. Chang, “Defending against Flooding-Based Distributed Denial-of-Service Attacks: A Tutorial,” IEEE Commun. Mag., Oct. 2002, pp. 42–51.  A. Belenky and N. Ansari, “On IP traceback,” IEEE Communications Magazine, vol. 41, no. 7, July 2003  S. Savage et al., “Network Support for IP Traceback,” IEEE/ACM Trans. Net., vol. 9, no. 3, June 2001, pp. 226–37.  D. X. Song and A. Perrig, “Advanced and Authenticated Marking Schemes for IP Traceback,” Proc. INFOCOM,2001, vol. 2, pp. 878–86.  S. F. Wu et al., “On Design and Evaluation of ‘Intention-Driven’ ICMP Traceback,” Proc. 10th Int’l. Conf. Comp. Commun. and Nets., 2001, pp. 159–65.  A. Belenky and N. Ansari “IP Traceback With Deterministic Packet Marking,” IEEE Communications Letters, Vol.7, NO. 4,April 2003  A. Belenky and N. Ansari “Tracing Multiple Attackers With Deterministic Packet Marking,” IEEE PACRIM’03, August 2003  A. C. Snoeren et al., “Single-Packet IP Traceback,” IEEE/ACM Trans. Net., vol. 10, no. 6, Dec. 2002, pp. 721–34.