Towards a More Functional and Secure Network Infrastructure

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

2. 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.

3. 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

4. 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

5. 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

6. 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

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

8. 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.

9. 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

10. x1 V x2 V x3 V Attacker floods victim via public triggers. x4 V Attacker (A) Victim dilutes attack by dropping two of its four public triggers. x3 V x4 V Victim (V) Diluting a DoS Attack

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

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

13. R1 S1 R1 idR1 idG idR1 ids1 id1 id1 idG idR2 R2 id1 R2 idR2 idG idR3 ids2 id1 S2 R3 idR3 R3 Senders Multicast Access Control (2)

14. send(R, data) id1 id2 id3 id2 send(id,data) send(id,data) Receiver (R) id R Sender id4 id1 id3 id E id4 Attacker (A) Attacker Eavesdropping Loop id2 id3 Attacker id1 id2 id2 id1 id3 id4 Attacker id2 id3 id3 V Victim (V) id3 id2 id2 id3 Dead-end Confluence Security Problems in I3

15. 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

16. 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

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

18. The End

19. y.key = hr(x) must match x y prefix key suffix 64 128 64 (a) (b) x.key = hl(y) x.key = hl(y.key) x y x y end-host address (c) (d) Trigger Constraints

20. 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!