HANDOUT NOTES
D-o-S Meeting
2-24-99

* my current focus: message flooding attacks
* client server-model and defense strategy:

* server has a queue and 1 "service station"
* each client message requests the same service;
* server spends 1 sec on each message
* discrete-time simulation
* each client sends messages at start of each second
* number of messages sent by each client is a random variable with a memoryless (Poisson) distribution
* "good" clients send messages at a "reasonable rate"
* "bad" clients flood the server with messages
* in between the message arrivals, the server works
* every 5 sec, the server begins to checks the message Q starting at the last message in the Q:
* checks id of sender
* if sender has too many (>= cutoff) messages in the Q currently, server deletes the message.
* check time = 10 msec; delete time = 100 msec
* server continues to check messages (in between arrivals) until it reach the front of the queue
* summary of simulation operation:
continuous cycle:
* messages arrive
* server works (serving or checking/deleting) for 1 sec

* graph

* 10 graph points between 0 and 1; 1 per integer thereafter
* 20 slots
* 4 good clients
* each sends .20 msgs per time slice
* good clients keep server about 80% busy by themselves
* 1 bad client (range of arrival rates from 0 to 20 msgs per sec)
* svce time = 1 sec; check time = 10 msec; delete time = 100 msec
* range of cutoff values
* ran each simulation for 10,000 seconds

* interested in flooding defenses for DNS. why?
* critical part of infrastructure
* seems to have little protection against flooding attacks
(except that non-recursive queries can be handled
very quickly)
* zone transfers in particular may be a vulnerability (named server forks off a new process to handle a zone transfer)
1. If cutoff is too low, you end up deleting good messages. The jagged area between 0 and 1 likely relates to the 1 second process
2. ST: The client will likely see some degradation in performance (% of good messages tossed), but cutoff is a better defense than no defense at all.
3. MB: Look at how adaptive timeout would affect the curve – a load balance problem.

1. MB: Fill up the process table and take out the server
2. DOB: Peter discovered this problem two years earlier, and I challenged him to take down my machine with FTP.
3. Sendmail versus Q-mail
1. Sendmail – drops priveledges to untrusted server
2. Q-mail – spawns a separate process, but dumps in the Q directory (more of a DoS)

1. Mutual exclusion, bounded weight (denies starvation), progress (denies deadlock)
2. What happens when there are no more resources to give?

1. DOB: Deny everyone, then put in rules that are allowed
2. ST: Authentication of ID in first packet – only allow connections to friend list
3. ST: SYN Flood can’t attack lower unless it’s on the wire
1. DOB: Wedge network card or driver
2. Go back to keeping state
4. MB: Deny everything on the MAC layers – processing wouldn’t go up higher
1. Parallel computer sits at MAC level – filter at MAC layer, authentication at IP layer
2. Changes paradigm of internet security – from allowing all to denying all.
3. Automatically deny unless a port 80 connection.
4. Can still be attacked by those that are trusted.