Transcript Towards a More Functional and Secure Network Infrastructure

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.
Victim dilutes attack by
dropping two of its four public
triggers.
x1 V
x2 V
x3 V
x4 V
Attacker
(A)
x3 V
x4 V
Victim
(V)
Slowing Down a DoS Attack
DoS-Filter (A)
2
1
Client
(C)
id C
t S
3
x A
Server (S)
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)
R1
S1
ids1 idG
id1 idR
idG id1
ids2 idG
S2
idR1 R1
1
id1 idR2
idR2 R2
R2
id1 idR3
idR3 R3
R3
Senders
Security Problems in I3
send(id,data)
send(R, data)
Receiver
(R)
id R
Sender
id E
Attacker (A)
send(id,data)
id1 id2
id2 id3
id4 id1
id3 id4
Attacker
Eavesdropping
Loop
id2 id3
Attacker
id1 id2
id2 id3
id2 id3
Confluence
id3 V
Victim Attacker id1 id2
(V)
id2 id3 id3 id4
Dead-end
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
y.key = hr(x)
must match
prefix
64
key
128
suffix
64
x
y
(a)
(b)
x.key = hl(y)
x
y
(c)
x.key = hl(y.key)
x
y
(d)
end-host address
If you really want security…
• If you have determined (and wellfunded) 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!