NetFence: Preventing Internet Denial of Service from Inside Out - - PowerPoint PPT Presentation

▶
netfence preventing internet denial of service from
SMART_READER_LITE
LIVE PREVIEW

NetFence: Preventing Internet Denial of Service from Inside Out - - PowerPoint PPT Presentation

Jan 12, 2024 153 likes •1.47k views

NetFence: Preventing Internet Denial of Service from Inside Out Xiaowei Yang (Duke University) with Xin Liu (Duke University) Yong Xia (NEC Labs China) Sigcomm 2010 Delhi, India DoS is a Formidable Threat Distributed attacks: many

slide-1
SLIDE 1

NetFence: Preventing Internet Denial of Service from Inside Out

Xiaowei Yang (Duke University) with Xin Liu (Duke University) Yong Xia (NEC Labs China) Sigcomm 2010 Delhi, India

slide-2
SLIDE 2

DoS is a Formidable Threat

  • Distributed attacks: many bots

send packet floods to exhaust shared resources

– Bandwidth, memory, or CPU

slide-3
SLIDE 3
  • 2009 Survey results

by Arbor Networks,

  • Inc. among 132

network operators

Largest Anticipated Threat – Next 12 Months

Largest DDoS Attack

  • 49 Gigabits Per Second
slide-4
SLIDE 4
  • 2009 Survey results

by Arbor Networks,

  • Inc. among 132

network operators

DDOS

Largest Anticipated Threat – Next 12 Months

Largest DDoS Attack

  • 49 Gigabits Per Second
slide-5
SLIDE 5
  • 2009 Survey results

by Arbor Networks,

  • Inc. among 132

network operators

DDOS

Largest Anticipated Threat – Next 12 Months

Largest DDoS Attack

  • 49 Gigabits Per Second
slide-6
SLIDE 6
  • 2009 Survey results

by Arbor Networks,

  • Inc. among 132

network operators

DDOS

Largest Anticipated Threat – Next 12 Months

Largest DDoS Attack

  • 49 Gigabits Per Second
slide-7
SLIDE 7
  • 2009 Survey results

by Arbor Networks,

  • Inc. among 132

network operators

DDOS

Largest Anticipated Threat – Next 12 Months

Largest DDoS Attack

  • 49 Gigabits Per Second
slide-8
SLIDE 8

Combating DoS is Difficult

  • A fundamental architecture problem
  • 1. Open: Any to any communication, and

new applications

  • 2. Robust: Non-disrupted communications

despite compromised hosts and routers

  • DoS defense must be built inside out

– Rethinking the Internet architecture

slide-9
SLIDE 9

Previous Work: Receivers as Victims

  • Much work: AIP, AITF, CenterTrack, dFence, Defense-by-

Offense, FastPass, Flow-Cookies, Kill-a-Bot, LazySusan, Mayday, OverDoSe, PacketSymmetry, Phalanx, Pushback, Portcullis, SIFF, SOS, SpeakUp, StopIt, TVA…

  • Denial of Edge Service (DoES)

– Enable receivers to suppress unwanted traffic – Network filters, network capabilities

A

Victim

slide-10
SLIDE 10

Previous Work: Receivers as Victims

  • Much work: AIP, AITF, CenterTrack, dFence, Defense-by-

Offense, FastPass, Flow-Cookies, Kill-a-Bot, LazySusan, Mayday, OverDoSe, PacketSymmetry, Phalanx, Pushback, Portcullis, SIFF, SOS, SpeakUp, StopIt, TVA…

  • Denial of Edge Service (DoES)

– Enable receivers to suppress unwanted traffic – Network filters, network capabilities

A

Victim

Filter (A,V)

slide-11
SLIDE 11

Previous Work: Receivers as Victims

  • Much work: AIP, AITF, CenterTrack, dFence, Defense-by-

Offense, FastPass, Flow-Cookies, Kill-a-Bot, LazySusan, Mayday, OverDoSe, PacketSymmetry, Phalanx, Pushback, Portcullis, SIFF, SOS, SpeakUp, StopIt, TVA…

  • Denial of Edge Service (DoES)

– Enable receivers to suppress unwanted traffic – Network filters, network capabilities

A

Victim

Filter (A,V)

slide-12
SLIDE 12

Previous Work: Receivers as Victims

  • Much work: AIP, AITF, CenterTrack, dFence, Defense-by-

Offense, FastPass, Flow-Cookies, Kill-a-Bot, LazySusan, Mayday, OverDoSe, PacketSymmetry, Phalanx, Pushback, Portcullis, SIFF, SOS, SpeakUp, StopIt, TVA…

  • Denial of Edge Service (DoES)

– Enable receivers to suppress unwanted traffic – Network filters, network capabilities

A

Victim

Filter (A,V)

slide-13
SLIDE 13

New Threat: Denial of Network Service (DoNS)

  • Bots can collude to send packet floods
  • Incapable of identifying attack traffic
slide-14
SLIDE 14

New Threat: Denial of Network Service (DoNS)

  • Bots can collude to send packet floods
  • Incapable of identifying attack traffic
slide-15
SLIDE 15

New Threat: Denial of Network Service (DoNS)

  • Bots can collude to send packet floods
  • Incapable of identifying attack traffic
slide-16
SLIDE 16

New Threat: Denial of Network Service (DoNS)

  • Bots can collude to send packet floods
  • Incapable of identifying attack traffic
slide-17
SLIDE 17

New Threat: Denial of Network Service (DoNS)

  • Bots can collude to send packet floods
  • Incapable of identifying attack traffic
slide-18
SLIDE 18

DoS

slide-19
SLIDE 19

DoS =

slide-20
SLIDE 20

Victim Denial of Edge Service (DoES)

DoS =

slide-21
SLIDE 21

Victim Denial of Edge Service (DoES)

DoS = +

slide-22
SLIDE 22

Victim Denial of Edge Service (DoES) Denial of Network Service (DoNS)

DoS = +

slide-23
SLIDE 23

Victim Denial of Edge Service (DoES)

How can we design a network architecture that can combat both DoES and DoNS?

Denial of Network Service (DoNS)

DoS = +

slide-24
SLIDE 24

Solution: NetFence

  • Design principle: inside-out, network-host

joint lines of defense

  • 1. Network controls its resource allocation
  • Combating DoNS
  • 2. End systems controls what they receive
  • Combating DoES
slide-25
SLIDE 25

Key Idea

  • 1. Hierarchical,
  • 2. Secure congestion policing in the network
  • 3. Coupled with network capabilities

+ +

Goals: Scalable, Robust, Open

slide-26
SLIDE 26

Hierarchical Congestion Policing

  • Scalable: no per-flow state in the core
  • 1. Aggregate flow policing placed at edge

routers [CSFQ]

  • 2. AS-level policing in the core
  • Fair queuing or rate limiting

ASx ASy

slide-27
SLIDE 27

Hierarchical Congestion Policing

  • Scalable: no per-flow state in the core
  • 1. Aggregate flow policing placed at edge

routers [CSFQ]

  • 2. AS-level policing in the core
  • Fair queuing or rate limiting

ASx ASy

slide-28
SLIDE 28

Hierarchical Congestion Policing

  • Scalable: no per-flow state in the core
  • 1. Aggregate flow policing placed at edge

routers [CSFQ]

  • 2. AS-level policing in the core
  • Fair queuing or rate limiting

ASx ASy

Slow down flooding senders

slide-29
SLIDE 29

Hierarchical Congestion Policing

  • Scalable: no per-flow state in the core
  • 1. Aggregate flow policing placed at edge

routers [CSFQ]

  • 2. AS-level policing in the core
  • Fair queuing or rate limiting

ASx ASy

x x y y y

Slow down flooding senders

slide-30
SLIDE 30

Secure Congestion Policing

  • Robust to compromised routers and hosts

– Efficient symmetric key cryptography – Packets carry secure tokens

  • Source AS authenticators [Passport,NSDI08] 

AS Accountability

  • Secure congestion policing feedback

ASx ASy

x x y y y

slide-31
SLIDE 31

Secure Congestion Policing

  • Robust to compromised routers and hosts

– Efficient symmetric key cryptography – Packets carry secure tokens

  • Source AS authenticators [Passport,NSDI08] 

AS Accountability

  • Secure congestion policing feedback

ASx ASy

x x y y y

slide-32
SLIDE 32

Secure Congestion Policing Feedback as Network Capabilities

  • Open

– Receiver explicitly authorizes desired traffic

  • Return if wants to receive
  • Not, otherwise

ASx ASy

x x y y y

slide-33
SLIDE 33

Secure Congestion Policing Feedback as Network Capabilities

  • Open

– Receiver explicitly authorizes desired traffic

  • Return if wants to receive
  • Not, otherwise

ASx ASy

x x y y y

slide-34
SLIDE 34

Secure Congestion Policing Feedback as Network Capabilities

  • Open

– Receiver explicitly authorizes desired traffic

  • Return if wants to receive
  • Not, otherwise

ASx ASy

x x y y y

slide-35
SLIDE 35

Secure Congestion Policing Feedback as Network Capabilities

  • Open

– Receiver explicitly authorizes desired traffic

  • Return if wants to receive
  • Not, otherwise

ASx ASy

x x y y y

slide-36
SLIDE 36

Now the Details…

slide-37
SLIDE 37

How does NetFence Work?

  • A sender sends two types of packets

Request Regular

slide-38
SLIDE 38

How does NetFence Work?

  • A sender sends two types of packets

mode link act timestamp MAC Request Regular NetFence Header

slide-39
SLIDE 39

How does NetFence Work?

  • A sender sends two types of packets

mode link act timestamp MAC Request Regular NetFence Header

slide-40
SLIDE 40

How does NetFence Work?

  • A sender sends two types of packets

mode link act timestamp MAC Request Regular nop mon No attack Attack NetFence Header

slide-41
SLIDE 41

How does NetFence Work?

  • A sender sends two types of packets

mode link act timestamp MAC Request Regular nop mon No attack Attack NetFence Header

slide-42
SLIDE 42

How does NetFence Work?

  • A sender sends two types of packets

mode link act timestamp MAC Request Regular nop mon No attack Attack NetFence Header  or 

slide-43
SLIDE 43

How does NetFence Work?

  • A sender first sends a request packet
  • Its access router stamps nop

– now  ts (timestamp), null  link, nop  mode – = MAC (src, dst, ts, null, nop) L

slide-44
SLIDE 44

How does NetFence Work?

  • A sender first sends a request packet
  • Its access router stamps nop

– now  ts (timestamp), null  link, nop  mode – = MAC (src, dst, ts, null, nop) L

slide-45
SLIDE 45

How does NetFence Work?

  • A sender first sends a request packet
  • Its access router stamps nop

– now  ts (timestamp), null  link, nop  mode – = MAC (src, dst, ts, null, nop) L

slide-46
SLIDE 46

How does NetFence Work?

  • A sender first sends a request packet
  • Its access router stamps nop

– now  ts (timestamp), null  link, nop  mode – = MAC (src, dst, ts, null, nop) L

slide-47
SLIDE 47

How does NetFence Work?

  • A sender first sends a request packet
  • Its access router stamps nop

– now  ts (timestamp), null  link, nop  mode – = MAC (src, dst, ts, null, nop) A time-varying secret key L

slide-48
SLIDE 48

How does NetFence Work?

  • A router under attack replaces nop with L

– All traffic – Signal congestion to access router – L link,   act, mon  mode – = MAC (src, dst, ts, L, mon, , ) – No downstream overwrite

L

slide-49
SLIDE 49

How does NetFence Work?

  • A router under attack replaces nop with L

– All traffic – Signal congestion to access router – L link,   act, mon  mode – = MAC (src, dst, ts, L, mon, , ) – No downstream overwrite

L

slide-50
SLIDE 50

How does NetFence Work?

  • A router under attack replaces nop with L

– All traffic – Signal congestion to access router – L link,   act, mon  mode – = MAC (src, dst, ts, L, mon, , ) – No downstream overwrite

L

slide-51
SLIDE 51

How does NetFence Work?

  • A router under attack replaces nop with L

– All traffic – Signal congestion to access router – L link,   act, mon  mode – = MAC (src, dst, ts, L, mon, , ) – No downstream overwrite

L

slide-52
SLIDE 52

How does NetFence Work?

  • A router under attack replaces nop with L

– All traffic – Signal congestion to access router – L link,   act, mon  mode – = MAC (src, dst, ts, L, mon, , ) – No downstream overwrite

L

slide-53
SLIDE 53

How does NetFence Work?

  • A router under attack replaces nop with L

– All traffic – Signal congestion to access router – L link,   act, mon  mode – = MAC (src, dst, ts, L, mon, , ) – No downstream overwrite

A shared time-varying secret key via distributed Diffie-Hellman via BGP [Passport] L

slide-54
SLIDE 54

How does NetFence Work?

  • A router under attack replaces nop with L

– All traffic – Signal congestion to access router – L link,   act, mon  mode – = MAC (src, dst, ts, L, mon, , ) – No downstream overwrite

A shared time-varying secret key via distributed Diffie-Hellman via BGP [Passport] L

slide-55
SLIDE 55

How does NetFence Work?

  • A router under attack replaces nop with L

– All traffic – Signal congestion to access router – L link,   act, mon  mode – = MAC (src, dst, ts, L, mon, , ) – No downstream overwrite

A shared time-varying secret key via distributed Diffie-Hellman via BGP [Passport] L

slide-56
SLIDE 56

How does NetFence Work?

  • A receiver use the feedback as capabilities
  • Sender sends regular packets that carry

the congestion policing feedback

– Could be nop when there is no attack – Can’t send if receiving no feedback from receiver L

slide-57
SLIDE 57

How does NetFence Work?

  • A receiver use the feedback as capabilities
  • Sender sends regular packets that carry

the congestion policing feedback

– Could be nop when there is no attack – Can’t send if receiving no feedback from receiver L

slide-58
SLIDE 58

How does NetFence Work?

  • A receiver use the feedback as capabilities
  • Sender sends regular packets that carry

the congestion policing feedback

– Could be nop when there is no attack – Can’t send if receiving no feedback from receiver L

slide-59
SLIDE 59

How does NetFence Work?

  • A receiver use the feedback as capabilities
  • Sender sends regular packets that carry

the congestion policing feedback

– Could be nop when there is no attack – Can’t send if receiving no feedback from receiver L

slide-60
SLIDE 60

How does NetFence Work?

  • A receiver use the feedback as capabilities
  • Sender sends regular packets that carry

the congestion policing feedback

– Could be nop when there is no attack – Can’t send if receiving no feedback from receiver L

slide-61
SLIDE 61

How does NetFence Work?

  • A receiver use the feedback as capabilities
  • Sender sends regular packets that carry

the congestion policing feedback

– Could be nop when there is no attack – Can’t send if receiving no feedback from receiver L

slide-62
SLIDE 62

How does NetFence Work?

  • Access router validates feedback
  • Starts congestion policing

– One leaky bucket per (src, L) limits sending rate – Not distinguish legitimate/malicious senders

  • Resets L

– now  ts,   act – = MAC (src, dst, ts, L, mon, ) L

slide-63
SLIDE 63

How does NetFence Work?

  • Access router validates feedback
  • Starts congestion policing

– One leaky bucket per (src, L) limits sending rate – Not distinguish legitimate/malicious senders

  • Resets L

– now  ts,   act – = MAC (src, dst, ts, L, mon, ) L

slide-64
SLIDE 64

How does NetFence Work?

  • Access router validates feedback
  • Starts congestion policing

– One leaky bucket per (src, L) limits sending rate – Not distinguish legitimate/malicious senders

  • Resets L

– now  ts,   act – = MAC (src, dst, ts, L, mon, )

(src, L)

L

slide-65
SLIDE 65

How does NetFence Work?

  • Access router validates feedback
  • Starts congestion policing

– One leaky bucket per (src, L) limits sending rate – Not distinguish legitimate/malicious senders

  • Resets L

– now  ts,   act – = MAC (src, dst, ts, L, mon, )

(src, L)

L

slide-66
SLIDE 66

How does NetFence Work?

  • Access router validates feedback
  • Starts congestion policing

– One leaky bucket per (src, L) limits sending rate – Not distinguish legitimate/malicious senders

  • Resets L

– now  ts,   act – = MAC (src, dst, ts, L, mon, )

(src, L)

L

slide-67
SLIDE 67

How does NetFence Work?

(src, L)

L

slide-68
SLIDE 68

How does NetFence Work?

(src, L)

L

slide-69
SLIDE 69

How does NetFence Work?

  • Establishes a congestion policing loop

– Bottleneck router signals

  • If congested, L  L
  • Otherwise, L

– Access router polices

  • Periodic Additive Increase Multiplicative Decrease

(AIMD, TCP-like) for fairness and efficiency (src, L)

L

slide-70
SLIDE 70

How does NetFence Work?

  • Establishes a congestion policing loop

– Bottleneck router signals

  • If congested, L  L
  • Otherwise, L

– Access router polices

  • Periodic Additive Increase Multiplicative Decrease

(AIMD, TCP-like) for fairness and efficiency (src, L)

L

slide-71
SLIDE 71

How does NetFence Work?

  • Establishes a congestion policing loop

– Bottleneck router signals

  • If congested, L  L
  • Otherwise, L

– Access router polices

  • Periodic Additive Increase Multiplicative Decrease

(AIMD, TCP-like) for fairness and efficiency (src, L)

L

slide-72
SLIDE 72

How does NetFence Work?

  • Establishes a congestion policing loop

– Bottleneck router signals

  • If congested, L  L
  • Otherwise, L

– Access router polices

  • Periodic Additive Increase Multiplicative Decrease

(AIMD, TCP-like) for fairness and efficiency (src, L)

L

slide-73
SLIDE 73

How does NetFence Work?

  • Establishes a congestion policing loop

– Bottleneck router signals

  • If congested, L  L
  • Otherwise, L

– Access router polices

  • Periodic Additive Increase Multiplicative Decrease

(AIMD, TCP-like) for fairness and efficiency (src, L)

L L L

slide-74
SLIDE 74

How does NetFence Work?

  • Bottleneck router
  • 1. Detect attack to start a policing cycle
  • Loss or load based
  • 2. Signal congestion within a cycle
  • Random Early Detection (RED)
slide-75
SLIDE 75

Recap: Why It Works

  • 1. Secret keys to secure congestion policing

feedback

  • 2. Periodic AIMD based on secure congestion

police feedback

  • 3. Secure congestion feedback as network

capabilities

L L

slide-76
SLIDE 76

Properties

  • Provable fairness

– Denial of Service  Predictable Delay of Service Theorem: Given G good and B bad senders sharing a bottleneck link of capacity C, regardless of the attack strategies, any good sender g with sufficient demand eventually obtains a fair share where and is a transport efficiency factor.

B G C vg  

1  

g

v

slide-77
SLIDE 77

Properties

  • Provable fairness

– Denial of Service  Predictable Delay of Service Theorem: Given G good and B bad senders sharing a bottleneck link of capacity C, regardless of the attack strategies, any good sender g with sufficient demand eventually obtains a fair share where and is a transport efficiency factor.

B G C vg  

1  

g

v

slide-78
SLIDE 78

Properties

  • Provable fairness

– Denial of Service  Predictable Delay of Service Theorem: Given G good and B bad senders sharing a bottleneck link of capacity C, regardless of the attack strategies, any good sender g with sufficient demand eventually obtains a fair share where and is a transport efficiency factor.

B G C vg  

1  

g

v

slide-79
SLIDE 79

Now the Trickier Stuff

slide-80
SLIDE 80

More Challenges

  • A broad range of attacks

– Flood request packets (with no feedback) – Hide L – Evade attack detection – On/Off – …

  • Multiple bottlenecks
  • Practical constraints

– Low overhead – Gradual deployment – Incentive-compatible adoption

slide-81
SLIDE 81

More Challenges

  • A broad range of attacks

– Flood request packets (with no feedback) – Hide L – Evade attack detection – On/Off – …

  • Multiple bottlenecks
  • Practical constraints

– Low overhead – Gradual deployment – Incentive-compatible adoption

slide-82
SLIDE 82

Limiting Request Packet Floods

  • 1. Separate request packet channel
  • 2. Per-sender request packet policing
  • 3. Priority-based backoff
  • Emulate computational puzzles

L

slide-83
SLIDE 83

Limiting Request Packet Floods

  • 1. Separate request packet channel
  • 2. Per-sender request packet policing
  • 3. Priority-based backoff
  • Emulate computational puzzles

L

slide-84
SLIDE 84

Limiting Request Packet Floods

  • 1. Separate request packet channel
  • 2. Per-sender request packet policing
  • 3. Priority-based backoff
  • Emulate computational puzzles

L

k

slide-85
SLIDE 85

Limiting Request Packet Floods

  • 1. Separate request packet channel
  • 2. Per-sender request packet policing
  • 3. Priority-based backoff
  • Emulate computational puzzles

L

k

1

2  

k

slide-86
SLIDE 86

Limiting Request Packet Floods

  • 1. Separate request packet channel
  • 2. Per-sender request packet policing
  • 3. Priority-based backoff
  • Emulate computational puzzles

L

k

1

2  

k

slide-87
SLIDE 87

Limiting Request Packet Floods

  • 1. Separate request packet channel
  • 2. Per-sender request packet policing
  • 3. Priority-based backoff
  • Emulate computational puzzles

L

k

1

2  

k

k-1

slide-88
SLIDE 88

Limiting Request Packet Floods

  • 1. Separate request packet channel
  • 2. Per-sender request packet policing
  • 3. Priority-based backoff
  • Emulate computational puzzles

L

k

1

2  

k

k-1

slide-89
SLIDE 89

Limiting Request Packet Floods

  • 1. Separate request packet channel
  • 2. Per-sender request packet policing
  • 3. Priority-based backoff
  • Emulate computational puzzles

L

k

1

2  

k

k-1

  • 1. Eventual success
  • 2. Efficient: waiting replaces proof of work
slide-90
SLIDE 90

Making hiding L ineffective

  • Robust signaling rate increase with L
  • 1. Treating the absence of L as L
  • 2. Stamping no L for sufficiently long after

congestion ends

slide-91
SLIDE 91

Making hiding L ineffective

  • Robust signaling rate increase with L
  • 1. Treating the absence of L as L
  • 2. Stamping no L for sufficiently long after

congestion ends

Bottleneck Router t1 t2 t2 + 2 Ictrl

slide-92
SLIDE 92

Making hiding L ineffective

  • Robust signaling rate increase with L
  • 1. Treating the absence of L as L
  • 2. Stamping no L for sufficiently long after

congestion ends

Bottleneck Router t1 t2 t2 + 2 Ictrl

slide-93
SLIDE 93

Making hiding L ineffective

  • Robust signaling rate increase with L
  • 1. Treating the absence of L as L
  • 2. Stamping no L for sufficiently long after

congestion ends

Bottleneck Router t1 t2 t2 + 2 Ictrl

slide-94
SLIDE 94

Making hiding L ineffective

  • Robust signaling rate increase with L
  • 1. Treating the absence of L as L
  • 2. Stamping no L for sufficiently long after

congestion ends

Bottleneck Router t1 t2 t2 + 2 Ictrl

slide-95
SLIDE 95

Making hiding L ineffective

  • Robust signaling rate increase with L
  • 1. Treating the absence of L as L
  • 2. Stamping no L for sufficiently long after

congestion ends

Bottleneck Router t1 t2 t2 + 2 Ictrl

slide-96
SLIDE 96

Making hiding L ineffective

  • Robust signaling rate increase with L
  • 1. Treating the absence of L as L
  • 2. Stamping no L for sufficiently long after

congestion ends

Bottleneck Router t1 t2 t2 + 2 Ictrl Access Router te te+ Ictrl

slide-97
SLIDE 97

Making hiding L ineffective

  • Robust signaling rate increase with L
  • 1. Treating the absence of L as L
  • 2. Stamping no L for sufficiently long after

congestion ends

Bottleneck Router t1 t2 t2 + 2 Ictrl Access Router te te+ Ictrl

slide-98
SLIDE 98

Making hiding L ineffective

  • Robust signaling rate increase with L
  • 1. Treating the absence of L as L
  • 2. Stamping no L for sufficiently long after

congestion ends

Bottleneck Router t1 t2 t2 + 2 Ictrl Access Router te te+ Ictrl

slide-99
SLIDE 99

Making hiding L ineffective

  • Robust signaling rate increase with L
  • 1. Treating the absence of L as L
  • 2. Stamping no L for sufficiently long after

congestion ends

Bottleneck Router t1 t2 t2 + 2 Ictrl Access Router te te+ Ictrl

slide-100
SLIDE 100

Making hiding L ineffective

  • Robust signaling rate increase with L
  • 1. Treating the absence of L as L
  • 2. Stamping no L for sufficiently long after

congestion ends

Bottleneck Router t1 t2 t2 + 2 Ictrl Access Router te te+ Ictrl

slide-101
SLIDE 101

Making hiding L ineffective

  • Robust signaling rate increase with L
  • 1. Treating the absence of L as L
  • 2. Stamping no L for sufficiently long after

congestion ends

Bottleneck Router t1 t2 t2 + 2 Ictrl Access Router te te+ Ictrl

slide-102
SLIDE 102

Making hiding L ineffective

  • Robust signaling rate increase with L
  • 1. Treating the absence of L as L
  • 2. Stamping no L for sufficiently long after

congestion ends

Bottleneck Router t1 t2 t2 + 2 Ictrl Access Router te te+ Ictrl

slide-103
SLIDE 103

Making hiding L ineffective

  • Robust signaling rate increase with L
  • 1. Treating the absence of L as L
  • 2. Stamping no L for sufficiently long after

congestion ends

Bottleneck Router t1 t2 t2 + 2 Ictrl Access Router te te+ Ictrl

 te+Ictrl ≤ t2 + 2Ictrl A sender can’t present L  Rate limit is reduced

slide-104
SLIDE 104

Performance

slide-105
SLIDE 105

Implementation

  • A software implementation in Linux

– XORP and Click – AES-128 as the MAC function

  • DeterLab experiments

– Dual-core Intel Xeon 3GHz CPUs – 2GB memory

slide-106
SLIDE 106

Implementation

  • A software implementation in Linux

– XORP and Click – AES-128 as the MAC function

  • DeterLab experiments

– Dual-core Intel Xeon 3GHz CPUs – 2GB memory

Encrypting the Internet!

slide-107
SLIDE 107

Implementation

  • A software implementation in Linux

– XORP and Click – AES-128 as the MAC function

  • DeterLab experiments

– Dual-core Intel Xeon 3GHz CPUs – 2GB memory

slide-108
SLIDE 108

Processing overhead

Packet type Access router Bottleneck router No Attack Request

546 ns/pkt Regular 781 ns/pkt

Attack

Request 546 ns/pkt 492 ns/pkt Regular 1267 ns/pkt 554 ns/pkt

slide-109
SLIDE 109

Processing overhead

Packet type Access router Bottleneck router No Attack Request

546 ns/pkt Regular 781 ns/pkt

Attack

Request 546 ns/pkt 492 ns/pkt Regular 1267 ns/pkt 554 ns/pkt

slide-110
SLIDE 110

Processing overhead

Packet type Access router Bottleneck router No Attack Request

546 ns/pkt Regular 781 ns/pkt

Attack

Request 546 ns/pkt 492 ns/pkt Regular 1267 ns/pkt 554 ns/pkt

slide-111
SLIDE 111

Processing overhead

One AES computation Tput ~ 2mpps

Packet type Access router Bottleneck router No Attack Request

546 ns/pkt Regular 781 ns/pkt

Attack

Request 546 ns/pkt 492 ns/pkt Regular 1267 ns/pkt 554 ns/pkt

slide-112
SLIDE 112

Processing overhead

One AES computation Tput ~ 2mpps

Packet type Access router Bottleneck router No Attack Request

546 ns/pkt Regular 781 ns/pkt

Attack

Request 546 ns/pkt 492 ns/pkt Regular 1267 ns/pkt 554 ns/pkt

slide-113
SLIDE 113

Processing overhead

One AES computation Tput ~ 2mpps ≤ 3AES computation. Parallelizable

Packet type Access router Bottleneck router No Attack Request

546 ns/pkt Regular 781 ns/pkt

Attack

Request 546 ns/pkt 492 ns/pkt Regular 1267 ns/pkt 554 ns/pkt

slide-114
SLIDE 114

Processing overhead

One AES computation Tput ~ 2mpps ≤ 3AES computation. Parallelizable

NetFence is suitable for high-speed implementation

Packet type Access router Bottleneck router No Attack Request

546 ns/pkt Regular 781 ns/pkt

Attack

Request 546 ns/pkt 492 ns/pkt Regular 1267 ns/pkt 554 ns/pkt

slide-115
SLIDE 115

Header overhead

slide-116
SLIDE 116

Header overhead

Header overhead: 20 – 28 bytes

slide-117
SLIDE 117

Simulations

  • Extensive ns-2 simulations
  • Systems compared: more state in core

– Per-sender Fair Queuing (FQ) – TVA+: capability + per-sender/receiver FQ – StopIt: filter + per-sender FQ NetFence

  • Enables receivers to suppress unwanted traffic
  • Effectively polices malicious flows

 A robust and scalable DoS solution

slide-118
SLIDE 118

A Subset of Results

slide-119
SLIDE 119

Expr 1: DoES Attacks

  • In each source AS

– 1 user sends a 20KB file to a victim via TCP – 99 attackers each send 1Mbps UDP traffic to the victim

AS1 AS2

…

… … … AS10 10Gbps Victim

slide-120
SLIDE 120

NetFence Limits DoES

  • All transfer finishes despite attackers >> users
  • No per-sender queues
slide-121
SLIDE 121

NetFence Limits DoES

  • All transfer finishes despite attackers >> users
  • No per-sender queues

Cost of scalability is acceptable

slide-122
SLIDE 122

Expr 2: DoNS Attacks

  • In each source AS

– 25% legitimate users and 75% attackers

  • In each destination AS

– One legitimate receiver or one colluding attacker

AS1 AS2

…

… … … AS10 10Gbps AS20 AS12 AS11

…

slide-123
SLIDE 123

NetFence Limits DoNS

  • Throughput ratio = avg(user)/avg(attacker)
slide-124
SLIDE 124

NetFence Limits DoNS

  • Throughput ratio = avg(user)/avg(attacker)

NetFence provides fairness

slide-125
SLIDE 125

NetFence Limits DoNS

  • Throughput ratio = avg(user)/avg(attacker)
slide-126
SLIDE 126

NetFence Limits DoNS

  • Throughput ratio = avg(user)/avg(attacker)

Per-receiver queuing. Topology dependent performance.

slide-127
SLIDE 127

NetFence Limits DoNS

  • Fairness index among legitimate users

 

2 2

) (

i i

x n x

slide-128
SLIDE 128

NetFence Limits DoNS

  • Fairness index among legitimate users

 

2 2

) (

i i

x n x

NetFence provides fairness

slide-129
SLIDE 129

Conclusion

  • NetFence

– First comprehensive solution combating DoES and DoNS attacks scalably – Design principle: inside-out, network-host joint lines of defense – Goals: Scalable, robust, and open – Key idea: Hierarchical, secure congestion policing coupled with network capabilities

Victim (DoES) (DoNS)

slide-130
SLIDE 130

Thank you!

  • Questions

– xwy@cs.duke.edu – xinl@cs.duke.edu – xia_yong@nec.cn