The Shared Channel Model for DoS

Carl A. Gunter

With Sanjeev Khanna, Kaijun Tan, and Santosh Venkatesh

Challenge of Broadcast Authentication

Inefficient to use public key signatures for each packet.

Insecure to use a common distributed key. Inefficient, impractical, or impossible to use

unicast tunnels. Many proposals have been made to address

these problems. Delayed key release. Amortize costs of public key checks over

multiple packets.

Challenge of DoS

Attacks in broadcast case are more likely to be informed attacks in which sequence numbers and other aspects of protocol state are known. TCP is very vulnerable to informed attacks.

Authentication based on Public Key Checks (PKCs) are vulnerable to signature flooding.

FEC attacks lead to higher overheads.

Security Models for DoS

Common form of analysis: show that the victim can defend against an attack that occupies his whole channel. Effective, but too conservative.

Dolev-Yao: assume that the adversary controls the channel and can use packets of the legitimate sender. Also effective, but even more conservative.

Attacks based on limited modifications. Not a common case.

Wanted: a more realistic model of attack and countermeasures to exploit it.

Shared Channel Model

Adversary can replay and insert packets. Legitimate sender sends packets with a

maximum and minimum bandwidth. Legitimate sender experiences random loss,

but not deliberate loss. Model is a four-tuple (W0, W1, A, p).

W0, W1 min and max sender b/w A attacker max b/w p loss rate of sender

Shared Channel Model Example

S1 S2 S4 S5S3A1 A2 A4A3

Sender Packet

Attacker Packet

Dropped Sender Packet

A5

Signature Flooding

Attack factor R=A/W1.

Proportionate attack R=1. Disproportionate attack R>1. Stock PC can handle about 8000 PKC/sec. 10Mbps link sends about 900 pkt/sec, 100Mbps link

sends about 9000 pkt/sec (assuming large packets). Processor is overwhelmed by too many signature

checks. Adversary can devote full b/w to bad signatures at no cost.

Budget: no more that 5% of processor on PKCs.

Broadcast Authentication Streams

Data Stream

Hash/Parity Stream

Signature Stream

Selective Verification

The signature stream is vulnerable to signature flooding: in a proportionate attack the adversary can devote his entire channel to fake signature packets.

Countermeasure: Valid sender sends multiple copies of the

signature packet. Receiver checks incoming signatures

probabilistically.

BAS Sender Protocol

1. As data packets are produced, collect their hashes into hash packets. Send as soon as ready.

2. When enough data packets have been processed to make a TG, create parity packets and signature for the TG.

3. Interleave these with each other and with the data and hash packets of the next TG.

Interleaving of Transmission Groups

01 1 1 1 01 1 1 1 01 1 1 1 1

-10 0 0 0 -10 0 0 0 -10 0 0 0 0

BAS Receiver Protocol

1. Acquisition phase: look for a valid signature until one is found.

2. When a signature packet is found, search a collection of packets before and after it to find candidate hash and parity packets.

3. Check hashes of these against the signature packet, and then use the parity packets to reproduce missing hash packets.

4. Continue searching for the next valid signature by checking each signature packet with specified probability .

Sample Numbers

10Mbps with 20% loss and 2 second latency 1584 data packets 11 hash packets, 11 parity packets 20 signature packets, = .25

100Mbps with 40% loss and 1 second latency 8208 data packets 57 hash packets, 66 parity packets 200 signature packets, = .025

Selective Verification is Very Efficient

0

0.02

0.04

0.06

0.08

0.1

0.12

1 4 7 10 13 16 19 22 25 28 31 34

TGs x 64

sec/

TG

0

1000

2000

3000

4000

5000

6000

7000

8000

9000

1 4 7 10 13 16 19 22 25 28 31 34

TGs x 64

no

of

fake

sig

nat

ure

s

PKC/TG

Sec/TG

Selective Verification is Very Effective

0.00%

1.00%

2.00%

3.00%

4.00%

5.00%

6.00%

1 4 7 10 13 16 19 22 25 28 31 34

TGs x 64

auth

lo

ss r

ate

0

1000

2000

3000

4000

5000

6000

7000

8000

9000

1 4 7 10 13 16 19 22 25 28 31 34

TGs x 64

no

of

fake

sig

nat

ure

s

PKC/TG

Auth Loss

Implementation

144 Hashes(b) HLH

FEC Parity Data(c) HLH

SN Rng

40 1456

40 14402 2

(d) HLH

40

Sig HRng PRng Hashes

128 2 2 Variable

SN

4

Pad

Variable

IP Payload(a) UDP RTP

20 8 12 Up to 1460

Time

4

Throughputs with Independent Loss and No Attack

100-40100-20100-5

10-40

10-2010-5

0

50

100

150

200

250

300

1 2 3 4 5 6

Th

rup

ut

(Mb

ps)

sender

receiver

Throughputs with Correlated Loss

180

185

190

195

200

205

210

215

220

225

230

10 30 50 70 90 110

130

150

170

190

Burst Rate

Th

rup

ut(

Mb

ps)

"10-5"

"10-20"

"10-40"

Proportionate Attack

120130140150160170180190200210220

10 30 50 70 90 110

130

150

170

190

Burst Rate

Th

rup

ut

(Mb

ps)

10-5

10-20

10-40

Factor 10 Attack

Authentication Loss

0.00%

2.00%

4.00%

6.00%

8.00%

10.00%

12.00%

14.00%

16.00%

18.00%

20.00%

1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20

Burst Rate (Pkts x 10)

Au

th L

oss

Rat

e(%

)

100-40

100-5

"10-40"

"10-5"

Throughputs Under Severe Attacks

100/40100/20100/5100/40100/20100/5

10/4010/2010/5

0

50

100

150

200

250

300

Th

rup

ut

(Mb

ps)

sender

receiver

Factor 10400 PKC/TG

Factor 51000 PKC/TG

Factor 5400 PKC/TG

8% sig o/h 3% sig o/h8% sig o/h

Little effect!

Hash/Parity Overheads

1.01

1.39

2.08

0.82

1.06

1.5

0

0.5

1

1.5

2

2.5

10M/5 10M/20 10M/40 100M/5 100M/20 100M/40

BandWidth(Mbps)/Drop Rate(%)

Ove

rHea

d%

Lessons and Extensions

Other models (e.g. Dolev-Yao) are too conservative: they show DoS threat where effective countermeasures can be found.

Selective verification can be done in many ways. Sequential: check each packet successively

with given probability. Bin: classify signatures into “bins”, check bins

with the fewest elements. Learn more: http://www.cis.upenn.edu/gunter