In attendance:
Matt Bishop (MB), David O’Brien (DOB), Steven Templeton (ST), and Tuomas Aura (TA)

---

TOPICS:

Discuss Tuomas Aura’s Paper "Stateless Connections" (handout)
Questions and Comments

NEXT WEEK:

Discuss the relationship between covert channels and DoS

1. Tuomas Aura’s Paper "Stateless Connections"
1. In the past, TCP attacks have been in the news. To avoid these attacks, make all protocols stateless
1. Practical and Impractical – can do a lot of things, but it’s expensive
2. Theory – Figure 1
1. A state server can serve a number of clients. Performance goes down with more clients. There is a sudden drop with a maximum number of clients.
2. With a stateless server/protocol, there is no drop with a maximum number of clients. Performance gradually goes down. Estimate traffic needed to decrease performance to a certain level. Run out of memory for storage connection data – fixed limit
3. Make a protocol so that the process is started when there is a message from the client (Ex. SSL creates a state in a stateless protocol)
1. You can establish connection without storing state
4. Section 3.1: Continue sending state to client
5. Section 3.2: Don’t always want to send state data. Protect integrity, encrypt state data. MAC added – not expensive
1. Box #2 – MAC faster than encryption
1. MAC_k(X)=SHA(K, X, K)
2. SHA (K, SHA (K, X))
2. Possible to make both server and client stateless, but not sure why you’d want to make client stateless
6. Section 3.3 – Encrypt messages; Encryption key become part of state
7. Section 4.0-4.1 – Practice; Handshake
1. In TCP protocol, make the first message exchange stateless
2. Authentication of protocol stateless
3. Ex. – X.509 Authorization Protocol – principle applied between Message 1 and 3
8. Section 4.2 – Idle periods in connection – timeout too short. Instead to breaking the connection, it would pack the state, send a message to the client, who can restore the session later.
9. Section 4.4 Implement – want buffer for caching of state data
3. Security Problems
1. DoS attack, state data could still be valid.
1. Time-stamp valid for 1-2 days, client can resend and old message to the server
2. DOB – What if you assume the packets come in order? The client sends the message the first time. Change the server key so that if client resends packet.
3. TA – Alternative to time stamping is to change server keys periodically.
4. DOB – Use one key, then can’t resuse it. TA – Server would have to remember old keys with respect to a particular client.
5. Pekka (co-author) implemented stateless TCP without caching – didn’t test how to handle attacks, didn’t measure performance
2. Calculate difference in performance
3. Flooding server – stop connection or some packets get through. After attack, timestamp duration longer than the attack, client again sends latest message.
2. Questions and Comments
1. DOB – Were the stateless protocols simulated? TA – No, it’s all theory.
2. DOB – Space? TA – No details MB: NTP (Network Time Protocol)
1. Stateless down to layer 4 (transport)
2. DOB – overcome argument about space, size of state
3. ST – In Section 3.1 you mention another application that sounds more interesting.
4. ST – Bandwidth consideration – flooding channels
5. DOB – Telnet, what does kernel keep in reference to the EMAC session in stateless protocols? TA – Application receives message from the client if every process has an identifier
1. DOB – Nothing stops from stating 100 EMACs
6. ST – What are types of problems at different levels? Maybe using authentication code as part of handshake MB – SYN cookies – state as 32 bit number
7. ST – TCP connection of SYN ACK
8. TA – Stateless protocol appears to make sniffing impossible, because you need to know state
9. ST – SYN Floods at bottom, then Broken Packet problems, Bandwidth saturation, Audit Bomb – fill up disk, overload system, Ping of Death
10. ST – Response system – human or machine – turn server off

3 layers that will relate
1. Overloading a resource
2. Exploiting a vulnerability, an error code, protocol or policy
3. Response – locking out accounts
4. Too many false alarms, turn of IDS