Introduction Assumptions and Goals Architecture Design Details Analysis Implementation and...

44
NetFence: Preventing Internet Denial of Service from Inside Out Xin Liu, Xiaowei Yang Dept. of Computer Science, Duke University Yong Xia Networking Systems Group, NEC Labs China SIGCOMM 2010

Transcript of Introduction Assumptions and Goals Architecture Design Details Analysis Implementation and...

Page 1: Introduction Assumptions and Goals Architecture Design Details Analysis Implementation and Evaluation Discussion 2 A Presentation at Advanced Defence.

NetFence: Preventing Internet Denial of Service from

Inside OutXin Liu, Xiaowei Yang

Dept. of Computer Science, Duke University

Yong XiaNetworking Systems Group, NEC Labs

China

SIGCOMM 2010

Page 2: Introduction Assumptions and Goals Architecture Design Details Analysis Implementation and Evaluation Discussion 2 A Presentation at Advanced Defence.

A Presentation at Advanced Defence Lab 2

Outline

Introduction Assumptions and Goals Architecture Design Details Analysis Implementation and Evaluation Discussion

Page 3: Introduction Assumptions and Goals Architecture Design Details Analysis Implementation and Evaluation Discussion 2 A Presentation at Advanced Defence.

A Presentation at Advanced Defence Lab 3

Introduction

A survey from Arbor Networks shows that DoS attacks continue to grow in both scale and sophistication.(2009)

Page 4: Introduction Assumptions and Goals Architecture Design Details Analysis Implementation and Evaluation Discussion 2 A Presentation at Advanced Defence.

A Presentation at Advanced Defence Lab 4

Page 5: Introduction Assumptions and Goals Architecture Design Details Analysis Implementation and Evaluation Discussion 2 A Presentation at Advanced Defence.

A Presentation at Advanced Defence Lab 5

Today’s Research

There have been several proposals addressing this challenge.

But …

the best defense mechanism these systems can offer is per-host queuing at the flooded link to separate legitimate traffic from attack traffic.

TCP

D oS

Page 6: Introduction Assumptions and Goals Architecture Design Details Analysis Implementation and Evaluation Discussion 2 A Presentation at Advanced Defence.

A Presentation at Advanced Defence Lab 6

Assumptions and Goals

Threat Model› Flood-based network attacks› Strong adversary

Victim

Page 7: Introduction Assumptions and Goals Architecture Design Details Analysis Implementation and Evaluation Discussion 2 A Presentation at Advanced Defence.

A Presentation at Advanced Defence Lab 7

Assumptions and Goals (cont.)

Assumptions› Trust

We assume that routers managed by the network are much less likely to be compromised than end systems.

› Line-speed lightweight cryptography Some current hardware can support AES

operations at 40Gbps. Intel AES Instructions Set[link]

Page 8: Introduction Assumptions and Goals Architecture Design Details Analysis Implementation and Evaluation Discussion 2 A Presentation at Advanced Defence.

A Presentation at Advanced Defence Lab 8

Assumptions and Goals (cont.)

Goals› Guaranteed network resource fair share› Open network› Scalable and lightweight

low communication, computation, and memory overhead

› Incrementally adoptable› Network self-reliant defense

Our hypothesis is that extra dependencies increase security risk and may create deployment deadlocks.

Page 9: Introduction Assumptions and Goals Architecture Design Details Analysis Implementation and Evaluation Discussion 2 A Presentation at Advanced Defence.

A Presentation at Advanced Defence Lab 9

Architecture

Page 10: Introduction Assumptions and Goals Architecture Design Details Analysis Implementation and Evaluation Discussion 2 A Presentation at Advanced Defence.

A Presentation at Advanced Defence Lab 10

Packet Type

NetFence has three types of packets: request packets, regular packets, and legacy packets.› The first two have a shim NetFence header

between their IP and upper-layer protocol headers.

Page 11: Introduction Assumptions and Goals Architecture Design Details Analysis Implementation and Evaluation Discussion 2 A Presentation at Advanced Defence.

A Presentation at Advanced Defence Lab 11

Design Details

Congestion policing feedback› nop: indicating no policing action is

needed.› mon: indicating the connection must be

monitored. L ↑ or L ↓: indicating the link L is overloaded

or underloaded.

Page 12: Introduction Assumptions and Goals Architecture Design Details Analysis Implementation and Evaluation Discussion 2 A Presentation at Advanced Defence.

A Presentation at Advanced Defence Lab 12

Protecting the Request Channel

It limits the request channel on any link to a small fraction (5%) of the link’s capacity.

It combines packet prioritization and priority-based rate limiting› the sender is limited to send level-k

packets at half of the rate of level-(k-1) packets

Page 13: Introduction Assumptions and Goals Architecture Design Details Analysis Implementation and Evaluation Discussion 2 A Presentation at Advanced Defence.

A Presentation at Advanced Defence Lab 13

Protecting the Regular Channel

Monitoring cycle› When a router suspects that its outgoing link L is

under attack, it starts a monitoring cycle for L The router’s average utilization The average loss rate p (using EWMA algorithm[

link]) and the threshold pth

› It marks L as in the mon state

Page 14: Introduction Assumptions and Goals Architecture Design Details Analysis Implementation and Evaluation Discussion 2 A Presentation at Advanced Defence.

A Presentation at Advanced Defence Lab 14

Updating Congestion Policing Feedback

If the packet carries nop, stamp L↓.

Otherwise, if the packet carries L’ ↓ stamped by an upstream link L’, do nothing.

Otherwise, if L is overloaded, stamp L↓.

Page 15: Introduction Assumptions and Goals Architecture Design Details Analysis Implementation and Evaluation Discussion 2 A Presentation at Advanced Defence.

A Presentation at Advanced Defence Lab 15

Regular Packet Policing at Access Routers

We implement a rate limiter as a queue whose de-queuing rate is the rate limit, similar to a leaky bucket.› use the queue to absorb traffic bursts

Page 16: Introduction Assumptions and Goals Architecture Design Details Analysis Implementation and Evaluation Discussion 2 A Presentation at Advanced Defence.

A Presentation at Advanced Defence Lab 16

Robust Rate Limit Adjustment

The L↑ and L↓ feedback enables an access router to adjust a rate limiter (src,L)’s rate limit rlim with an AIMD algorithm.

Page 17: Introduction Assumptions and Goals Architecture Design Details Analysis Implementation and Evaluation Discussion 2 A Presentation at Advanced Defence.

A Presentation at Advanced Defence Lab 17

Robust Rate Limit Adjustment (cont.)

However, a malicious sender can manipulate this design by hiding the L ↓ feedback to prevent its rate limit from decreasing.

So…

Page 18: Introduction Assumptions and Goals Architecture Design Details Analysis Implementation and Evaluation Discussion 2 A Presentation at Advanced Defence.

A Presentation at Advanced Defence Lab 18

Robust Rate Limit Adjustment (cont.)

For each rate limiter (src,L), the access router Ra keeps two state variables: ts and hasIncr.› If hasIncr is true, Ra compares the

throughput of the rate limiter with 1/2 rlim.

› Otherwise, Ra will decrease rlim to (1 −δ )rlim.

Page 19: Introduction Assumptions and Goals Architecture Design Details Analysis Implementation and Evaluation Discussion 2 A Presentation at Advanced Defence.

A Presentation at Advanced Defence Lab 19

Securing Congestion Policing Feedback

Feedback format

Stamping nop feedback› ),,,,( noplinktsdstsrcMACtocken nullKnop a

Page 20: Introduction Assumptions and Goals Architecture Design Details Analysis Implementation and Evaluation Discussion 2 A Presentation at Advanced Defence.

A Presentation at Advanced Defence Lab 20

Securing Congestion Policing Feedback (cont.)

Stamping L↑ feedback›

› Also inserts a tokennop into the tokennop field.

Stamping L ↓ feedback›

› The router Rb erases tokennop field afterwards to prevent malicious downstream routers from overwriting its feedback

),,,,,( incrmonLtsdstsrcMACtockenaKL

),,,,,,( nopKLtockendecrmonLtsdstsrcMACtocken

ai

Page 21: Introduction Assumptions and Goals Architecture Design Details Analysis Implementation and Evaluation Discussion 2 A Presentation at Advanced Defence.

A Presentation at Advanced Defence Lab 21

Securing Congestion Policing Feedback (cont.)

Validating feedback› A feedback is considered invalid if its ts

field is more than w seconds older than the access router’s local time tnow: |tnow − ts| > w, or if the MAC field has an invalid signature.

Page 22: Introduction Assumptions and Goals Architecture Design Details Analysis Implementation and Evaluation Discussion 2 A Presentation at Advanced Defence.

A Presentation at Advanced Defence Lab 22

Localizing Damage of Compromised Routers

A NetFence router can take several approaches to localize the damage of compromised ASes, if its congestion persists after it has started a monitoring cycle, a signal of malfunctioning access routers.

Page 23: Introduction Assumptions and Goals Architecture Design Details Analysis Implementation and Evaluation Discussion 2 A Presentation at Advanced Defence.

A Presentation at Advanced Defence Lab 23

Localizing Damage of Compromised Routers (cont.)

All approaches require a router to correctly identify a packet’s source AS, which can be achieved using an IP-to-AS mapping tool if the packet’s source IP address is not spoofed.

NetFence uses Passport to prevent source address spoofing.

IP Header Passport Payload

Page 24: Introduction Assumptions and Goals Architecture Design Details Analysis Implementation and Evaluation Discussion 2 A Presentation at Advanced Defence.

A Presentation at Advanced Defence Lab 24

Parameter Settings

Page 25: Introduction Assumptions and Goals Architecture Design Details Analysis Implementation and Evaluation Discussion 2 A Presentation at Advanced Defence.

A Presentation at Advanced Defence Lab 25

Parameter Settings (cont.)

A request packet size is estimated as 92 bytes that includes a 40-byte TCP/IP header, a 28-byte NetFence header and a 24-byte Passport header.

We set the attack detection threshold pth to 2%, since at this packet loss rate, a TCP flow with 200ms RTT and 1500B packets can obtain about 500Kbps throughput

Page 26: Introduction Assumptions and Goals Architecture Design Details Analysis Implementation and Evaluation Discussion 2 A Presentation at Advanced Defence.

A Presentation at Advanced Defence Lab 26

Analysis - Scalability

As a closed-loop design, NetFence can place different functions at different locations to provide per-sender fairness.

We think 100 links per legitimate sender is a reasonable upper bound.› If an access router serves 10K end hosts.› The total amount of memory requirement is less

than 2GB.› The per-packet processing time on our

benchmarking PC is less than 1.3μs during attack times. This translates into a throughput more than 9Gbps

Page 27: Introduction Assumptions and Goals Architecture Design Details Analysis Implementation and Evaluation Discussion 2 A Presentation at Advanced Defence.

A Presentation at Advanced Defence Lab 27

Analysis - Security

Malicious End Systems› Forgery or Tampering

MAC and robust AIMD

› Evading attack detection Packet loss rate p

› On-off attacks prolonged monitor cycle

Page 28: Introduction Assumptions and Goals Architecture Design Details Analysis Implementation and Evaluation Discussion 2 A Presentation at Advanced Defence.

A Presentation at Advanced Defence Lab 28

Analysis – Security (cont.)

Malicious On-path Routers› A malicious router downstream to a

congested link may attempt to remove or modify the L ↓ feedback. MAC

› A malicious on-path router may discard packets to completely disrupt end-to-end communications, duplicate packets, or increase packet sizes to congest downstream links. Passport

Page 29: Introduction Assumptions and Goals Architecture Design Details Analysis Implementation and Evaluation Discussion 2 A Presentation at Advanced Defence.

A Presentation at Advanced Defence Lab 29

Analysis - Incremental Deployment

Routers at congested links and access routers need to be upgraded, but well-provisioned routers that can withstand tens of Gbps attack traffic may not need to upgrade.

Page 30: Introduction Assumptions and Goals Architecture Design Details Analysis Implementation and Evaluation Discussion 2 A Presentation at Advanced Defence.

A Presentation at Advanced Defence Lab 30

Implementation and Evaluation

Page 31: Introduction Assumptions and Goals Architecture Design Details Analysis Implementation and Evaluation Discussion 2 A Presentation at Advanced Defence.

A Presentation at Advanced Defence Lab 31

Micro-benchmarking We have implemented NetFence in

Linux using XORP [link] and Click [link]. We benchmark the Linux

implementation on Deterlab [link] with a three-node testbed.

A---B--{5Mbp}—C› Send 100Kbps UDP request and 1Mbps

UDP regular› 1 Mbps UDP req and 10Mbps UDP reg for

DoS

Page 32: Introduction Assumptions and Goals Architecture Design Details Analysis Implementation and Evaluation Discussion 2 A Presentation at Advanced Defence.

A Presentation at Advanced Defence Lab 32

Micro-benchmarking

Page 33: Introduction Assumptions and Goals Architecture Design Details Analysis Implementation and Evaluation Discussion 2 A Presentation at Advanced Defence.

A Presentation at Advanced Defence Lab 33

Mitigating DoS Flooding Attacks

Using ns-2 simulations Compare with other solutions

› TVA+ Uses network capabilities and per-host fair

queuing to defend against DoS flooding attacks.

› StopIt StopIt is a filter and fair queuing based DoS

defense system.› Fair Queuing

Page 34: Introduction Assumptions and Goals Architecture Design Details Analysis Implementation and Evaluation Discussion 2 A Presentation at Advanced Defence.

A Presentation at Advanced Defence Lab 34

Mitigating DoS Flooding Attacks

Unwanted Traffic Flooding Attacks

victim

1 legitimate and 99 attacker

Rbl Rbr

Page 35: Introduction Assumptions and Goals Architecture Design Details Analysis Implementation and Evaluation Discussion 2 A Presentation at Advanced Defence.

A Presentation at Advanced Defence Lab 35

Mitigating DoS Flooding Attacks (cont.)

Page 36: Introduction Assumptions and Goals Architecture Design Details Analysis Implementation and Evaluation Discussion 2 A Presentation at Advanced Defence.

A Presentation at Advanced Defence Lab 36

Mitigating DoS Flooding Attacks (cont.)

Colluding Attacks› Single Bottleneck

victim

25% legitimate Rbl Rbr

10 ASes

Page 37: Introduction Assumptions and Goals Architecture Design Details Analysis Implementation and Evaluation Discussion 2 A Presentation at Advanced Defence.

A Presentation at Advanced Defence Lab 37

Single Bottleneck

Two metrics› Throughput Ratio, the ratio between the

average throughput of a legitimate user and that of an attacker

› Fairness Index among legitimate users. Let xi denote a legitimate sender i’s throughput, and the fairness index is defined as (Σ xi)2/(n Σ xi

2 ).

Page 38: Introduction Assumptions and Goals Architecture Design Details Analysis Implementation and Evaluation Discussion 2 A Presentation at Advanced Defence.

A Presentation at Advanced Defence Lab 38

Single Bottleneck (cont.)

Page 39: Introduction Assumptions and Goals Architecture Design Details Analysis Implementation and Evaluation Discussion 2 A Presentation at Advanced Defence.

A Presentation at Advanced Defence Lab 39

Multiple Bottlenecks (In Technical Report)

A

B

C

CL1

CL2

Page 40: Introduction Assumptions and Goals Architecture Design Details Analysis Implementation and Evaluation Discussion 2 A Presentation at Advanced Defence.

A Presentation at Advanced Defence Lab 40

Multiple Bottlenecks (cont.)

Page 41: Introduction Assumptions and Goals Architecture Design Details Analysis Implementation and Evaluation Discussion 2 A Presentation at Advanced Defence.

A Presentation at Advanced Defence Lab 41

Multiple Bottlenecks (cont.)

Multi-bottleneck feedback in a NetFence header

Page 42: Introduction Assumptions and Goals Architecture Design Details Analysis Implementation and Evaluation Discussion 2 A Presentation at Advanced Defence.

A Presentation at Advanced Defence Lab 42

Strategic Attacks (On-off Attack)

Page 43: Introduction Assumptions and Goals Architecture Design Details Analysis Implementation and Evaluation Discussion 2 A Presentation at Advanced Defence.

A Presentation at Advanced Defence Lab 43

Discussion

Fair Share Bound› O( C/(G+B) )

Congestion Quota› If we assume legitimate users have limited

traffic demand while attackers aim to persistently congest a bottleneck link, we can further weaken a DoS flooding attack by imposing a congestion quota.

Page 44: Introduction Assumptions and Goals Architecture Design Details Analysis Implementation and Evaluation Discussion 2 A Presentation at Advanced Defence.

A Presentation at Advanced Defence Lab 44

Discussion

Convergence Speed› It may take a relatively long time (e.g.,

100s-200s) for NetFence to converge to fairness.

Equal Cost Multiple Path› NetFence assumes that a flow’s path is

relatively stable and the bottleneck links on the path do not change rapidly.