Towards a More Functional and Secure Network Infrastructure Dan Adkins, Karthik Lakshminarayanan, Adrian Perrig (CMU), and Ion Stoica

Motivation The Internet is vulnerable to Denial of Service (DoS) attacks (packet floods). The Internet only does point-to-point communication well. –Other applications are difficult to deploy. In general, there is a tradeoff between adding functionality and achieving security.

DoS Assumptions Attacker power –Can flood using multiple clients –Can’t take out network –Can’t compromise I3 nodes DoS is “solved” when… –The victim’s link is no longer saturated

Traditional Solutions IP-level filtering –Must identify a pattern –Need help from your ISP –Slow response time –… but effective SYN rate limiting –Limits legitimate connections

The Woes of IP You only have one address Subnets are small enough to scan Any security can be subverted by denial of service on an IP address/subnet IP addresses can be spoofed

Functionality vs. Security Claim: More functionality = less security –Complexity leads to bugs and holes –More flexibility gives attackers more options Not necessarily! –More options = more defenses –No need to trade functionality for security

Three Principles Hide IP addresses –Must use overlay End-hosts have ability to defend against attacks (in the network) Don’t create additional vulnerabilities

I3 Solves This Problem Hide IP addresses by using I3 ID’s instead –All or nothing End-hosts can defend against DoS attacks I3 creates additional vulnerabilities –We can fix them.

DoS Solution? Can’t prevent, but can dilute Drop a fraction of incoming traffic in the network Random dropping reduces load… But also drops legitimate requests Real clients will retry

Diluting a DoS Attack Attacker floods victim via public triggers. x4x4 V x3x3 V x2x2 V x1x1 V Attacker (A) Victim dilutes attack by dropping two of its four public triggers. x4x4 V x3x3 V Victim (V)

Slowing Down a DoS Attack Server (S) Client (C) tS x A DoS-Filter (A) 1 id C 2 3

Multicast Access Control IP multicast address known to all receivers Mischievous subscribers can send to entire group I3 has efficient non-cryptographic solution

Multicast Access Control (2) id G id 1 id R3 S1 id 1 R1 R2 R3 id s 2 id G id s 1 id G S2 Senders id 1 id R2 id 1 id R 1 R1 id R2 R2 id R3 R3

Security Problems in I3 Eavesdropping Sender Receiver (R) idR send(id,data) send(R, data) Attacker (A) idE Dead-end id 4 Attacker id 2 id 1 id 3 id 2 id 3 Victim (V) Confluence id 3 V Attacker id 2 id 1 id 3 Attacker send(id,data) Loop id 4 id 1 id 2 id 3 id 1 id 4 id 3 id 2

Secure-I3 Overview Constrained triggers –Only allow trigger (x,y) if y.key=H(x) or x.key = H(y) –Solves eavesdropping, loop, confluence Pushback –Crucial to DoS solution Trigger challenges –Cannot insert triggers -> to other end-hosts

Conclusion There is hope for security –Our solution gives servers more defenses than they would have under IP –IP-level filtering is still useful, but slower More functionality and more security

Open Questions Formal model of DoS –Beats intuition and assumptions What if I3 servers are compromised?

The End

Trigger Constraints prefixkeysuffix must match xy y.key = h r (x) xy x.key = h l (y) xy x.key = h l (y.key) end-host address (a)(b) (c)(d)

If you really want security… If you have determined (and well- funded) enemies… –Learn to make friends! If you have a critical server… –Don’t place it on a public, open network! If you must be online… –Pay for excess capacity!