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 (W 0, W 1, A, p). W 0, W 1 min and max sender b/w A attacker max b/w p loss rate of sender

Shared Channel Model Example

Signature Flooding Attack factor R=A/W 1. 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

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,  = Mbps 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 PKC/TG Sec/TG

Selective Verification is Very Effective PKC/TG Auth Loss

Implementation

Throughputs with Independent Loss and No Attack

Throughputs with Correlated Loss

Authentication Loss

Throughputs Under Severe Attacks 8% sig o/h3% sig o/h8% sig o/h Little effect!

Hash/Parity Overheads

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: