Practical Verifiable In-network Filtering for DDoS Defense Deli Gong, Muoi Tran , Shweta Shinde, Hao Jin, Vyas Sekar, Prateek Saxena, Min Suk Kang July 8, 2019 | Dallas, TX
Large-scale volumetric DDoS attacks are common (distributed denial of service) • Hundreds DDoS attacks occur daily * • Volume of DDoS traffic is escalating • New attack vectors (e.g., amplification) and attack source (e.g., botnets) * According to Kaspersky Lab’s report on DDoS attacks in Q1 2019 (2013) (2018) 2
In-network filtering : a promising DDoS mitigation Filter rule: Drop 50% HTTP flows coming to my network AS* A DDoS victim network (* autonomous system) AS B filtering network transit networks • In-network filtering ü allows the DDoS victim to install traffic filters nearer to attack source ü not a new idea: e.g., Pushback [SIGCOMM’02], D-WARD [ICNP’02], AITF [USENIX ATC’05], StopIt [SIGCOMM’08] ü installs at 1% of ISPs can mitigate 90% of DDoS attacks ( SENSS [ACSAC’18]) 3
One ignored problem: In-network filtering creates ambiguity about packet drops With in-network filtering Without in-network filtering Network faults or Network faults! legitimate filtering? Packet drops Packet drops AS A AS A AS B AS B transit network with transit network in-network filtering What can go wrong because of this ambiguity? 4
Filtering can be used as an excuse for discriminating neighboring ASes Filter rule: Drop 50% HTTP Drop 0% traffic from A, flows coming to my network 100% traffic from B AS A DDoS victim network (e.g., AT&T) AS B filtering network transit networks (e.g., Level3) (e.g., Comcast) 5
Filtering can be used as an excuse for discriminating neighboring ASes (2013) Filter rule: Drop 50% HTTP Drop 0% traffic from A, flows coming to my network 100% traffic from B AS A DDoS victim network (e.g., AT&T) (2014) AS B filtering network transit networks (e.g., Level3) (e.g., Comcast) Several disputes already exist between transit networks 6
How to remove such an ambiguity? Verifiability of filtering distinguishes legitimate DDoS mitigation from network faults Packets are being legitimately dropped! verify filtering verify filtering Filter rule policy & operation operation AS A DDoS victim network AS B filtering network transit networks 7
How to make the operations of in-network filtering verifiable ? 8
Our contributions • We propose Verifiable In-network Filtering (VIF): ü Software networking functions with Trusted Execution Environments (e.g., Intel SGX) as root of trust. Scalable design Auditable filter Practical deployment ü multiple filters ü uses TEEs ü at Internet Exchange run in parallel ü is stateless Points (IXPs) ü detects bypass 9
VIF design: auditable filter with TEEs audit enclaved protected memory code and state enclave victim network • Filtering within Trusted Execution Environments (TEEs) (e.g., Intel SGX) ü Isolated execution ü Remote attestation 10
TEEs alone is insufficient for auditable filter design! 11
Challenge 1 : Influence from malicious inputs Trusted clock can be tampered ALLOW or Malicious packets DROP ? inserted … 𝒒 𝑞 / , 𝑢 / 𝑞 0 , 𝑢 0 • Abstract model of the filtering function for packet 𝒒 : 𝐵𝑀𝑀𝑃𝑋, 𝐸𝑆𝑃𝑄 ← 𝑔( 𝑞, 𝑢 , ( 𝑞 / , 𝑢 / , 𝑞 0 , 𝑢 0 , 𝑞 1 , 𝑢 1 , … )) Previous packets/ Arrival time packet order 12
Solution: Stateless filter design ALOW or DROP ? … 𝒒 𝑞 / , 𝑢 / 𝑞 0 , 𝑢 0 5-tuple ( srcIP, srcPort, dstIP, dstPort, protocol ) • No reliance on packet arrival time and packet order 𝐵𝑀𝑀𝑃𝑋, 𝐸𝑆𝑃𝑄 ← 𝑔( 𝑞 ) 13
Challenge 2: Traffic may be redirected to bypass filter redirect enclave 14
Solution to filter bypass: Accountable logs for bypass detection 𝒒 does not reach filter! Bypass detected! packet logs 𝒒 logs logs packet logs neighboring networks filtering network • Accountable packet logging before and after filtering ü Compare logs to detect bypass 15
Solution to filter bypass: Accountable logs for bypass detection How to check if packets are 𝒒 is dropped dropped by a transit network? drop outside TEEs! packet logs logs logs 𝒒 transit networks victim network filtering network • Accountable packet logging before and after filtering ü Compare logs to detect bypass 16
How does victim know who is dropping packets? Packets are still dropped! à Filtering network avoid AS B misbehaved! AS B victim network AS A logs logs AS C filtering network • Victim network tests individual intermediate ASes ü Rerouting inbound traffic using BGP poisoning (LIFEGUARD[SIGCOMM’12]) ü Detour takes place in a few minutes and no collaboration needed (Nyx [S&P’18]) 17
Our contributions Scalable design Auditable filter Practical deployment ü multiple filters ü TEEs ü at Internet Exchange run in parallel ü stateless Points (IXPs) ü bypass detection 18
Deployment issue: Scalability Memory footprint Throughput Mpps 20 200 MB 15 150 EPC limit (e.g., 92 MB) 10 100 5 50 0 0 0 1,000 2,000 3,000 4,000 5,000 6,000 7,000 8,000 9,000 10,000 Number of rules • Performance issues when filtering within a single enclave: ü Memory footprint grows linearly with number of rules ü Throughput degrades when number of rules exceeds ~ 3,000 19
Solution to scalability issue: multiple SGX filters VIF Filtering Network untrusted per-enclave limitations: controller (1) # rules (3,000) E 0 (2) bandwidth (10 Gb/s)* filter … victim network load balance E n-1 untrusted filter switching fabric * Demonstrated by mbTLS (CoNEXT’17) on four SGX-core machines. • More in our paper: ü How trusted filters detect misbehaviors from untrusted components ü A greedy solution to calculate filter rules among filters ü Filter rules redistribution 20
Our contributions Scalable design Auditable filter Practical deployment ü multiple filters ü TEEs ü at Internet Exchange run in parallel ü stateless Points (IXPs) ü bypass detection 21
Deployment example remote attestation victim network filter rule insertion IXP SDX [SIGCOMM’15] controller Enclave Enclave Enclave route rules rules iSDX [NSDI’16] rules filter AS A filter control filter FLANC [SOSR’16] VIF filters AS C AS B switch fabric • Internet Exchange Points (IXPs) : ü have peering relationship with hundreds ISPs ü have flexible software-defined architecture 22
Implementation • Overview ü Intel SGX SDK for Linux 2.1 ü Data Plane Development Kit (DPDK) 17.05.2 • Trusted computing base: ü modification of DPDK ip_pipeline (1,044 SLoC) 1,206 SLoC ü packet logging and optimizations (162 SLoC) • Two optimizations: ü Reducing context switches (more in our paper) ü Near-zero copy approach 23
Optimization: near-zero copy Enclave memory Enclave memory allow! allow! packet packet sketch sketch filter filter logs logs (srcIP) (5T) drop! drop! Full a/d? a/d? 5T s Near- packet packet zero Untrusted packet memory pool Untrusted packet memory pool cop y cop y allow or drop! allow or drop! packet packet only when allowed only when allowed NIC NIC Rx Queues Tx Queues Rx Queues Tx Queues Incoming packets Forwarded packets Incoming packets Forwarded packets ü low memory usage ü low packet-logging overhead 24
Data-plane implementation • Testbed • Synthetic data ü Packet generator ⟷ Filter machine ü 3,000 random filter rules ü Measurement is done at packet generator ü 10 Gb/s traffic Intel SGX Packet Generator Filter Machine ü Intel E5-2630 v3 CPU ü Intel i7-6700 CPU (2.40 GHz, 8 cores) (3.40 GHz, 4 cores) ü 32 GB memory ü 8 GB memory ü Ubuntu 16.04.3 LTS ü Ubuntu 16.04.3 LTS ü Kernel version 4.10 ü Kernel version 4.10 ü 10 GbE Intel X540-AT2 ü 10 GbE Intel X540-AT2 25
Evaluation: Data-plane performance Throughput (Gb/s) 10 8 6 4 2 0 64 128 256 512 1024 1500 Packet size (bytes) Native (no SGX) SGX with full packet copy SGX with near-zero copy • Throughput of near-zero copy: ü 8 Gb/s throughput even with smallest packet size (64 bytes) 26
Evaluation: VIF deployment at IXPs Ratio of attack source IPs handled by top- n IXPs per region 1 VIF at only top-5 IXPs 0.8 per region mitigate 0.6 up to 90% of attack 0.4 0.2 0 DNS resolvers Mirai botnets Top-1 Top-2 Top-3 Top-4 Top-5 • Simulation setup: ü Two real attack source data: 3 millions DNS resolvers and 250K Mirai botnets ü CAIDA AS relationship and IXP peering for building inter-domain topology 27
Conclusion • VIF addresses the core issue of in-network filtering ü Lack of filtering verifiability à ambiguity in handling packet drops which can be exploited by malicious ISPs • VIF: the first auditable and scalable DDoS traffic filter • VIF takes advantages of: ü Trusted execution environments as the root of trust ü Software-defined, line-rate packet processing ü IXPs for practical deployment 28
Question? Muoi Tran muoitran@comp.nus.edu.sg
Recommend
More recommend
