Transcript Papers covered

Papers covered
●
●
K. Lakshminarayanan, D. Adkins, A. Perrig, I. Stoica,
“Taming IP Packet Flooding Attacks”, HotNets-II.
M. Handley, A. Greenhalgh, “Steps Towards a DoSresistant Internet Architecture”, FDNA 2004.
Goals
●
Host-based control over packets received
–
Avoid receiving packets at arbitrary ports
–
Contain traffic of an application under a flooding attack to
protect other traffic (isolation)
–
Protect traffic of established connections
–
Throttle rate of opening new connections
Two main approaches
●
More radical, more elegant
–
●
Use indirection layer (i3-based)
Less radical, less elegant
–
Use special filters at edge ISP (IP-based)
i3
●
●
Rendezvous primitive built on top of a DHT (contentaddressable network)
Key lookup done in a distributed p2p manner
i3-based approach
●
●
Sources send packets to logical identifier <id,data>
–
Receivers express interest in packets by inserting triggers
<id,addr>
–
Given a packet <id,data>, i3 looks to see if there is an
associated trigger <id,addr> to forward packet to
–
Receiver removes trigger if not interested in packet
Example use
–
Servers have well-known public triggers
–
Clients contact servers via public triggers to establish dynamic
private triggers
–
Subsequent communication via private triggers
i3-based goals achieved
●
Avoid receiving packets at arbitrary ports
–
●
Contain traffic of an application under a flooding attack to
protect other traffic (isolation)
–
●
Differential dropping/prioritization of public triggers under
attack (similar to WFQ or CBQ)
Protect traffic of established connections
–
●
IP addresses hidden and identifiers of public triggers are the
only information exposed
Differential dropping/prioritization of private vs public triggers
Throttle rate of opening new connections
–
Redirect public trigger to a gatekeeper that issues puzzles
(approach in paper is weak => see last week's IP puzzle paper)
IP-based approach
●
●
Provide configurable white lists of allowed
communication at edge ISP (akin to NAT traversal)
–
Edge routers maintain per-flow state for destinations
–
Effectively placing a customer “firewall” upstream
Assumptions
–
Edge ISP with enough bandwidth to support arbitrary volumes
of attack traffic
–
Edge ISP willing to allow dynamic customer filters
IP-based goals achieved
●
Avoid receiving packets at arbitrary ports
–
●
Contain traffic of an application under a flooding attack
to protect other traffic (isolation)
–
●
Differential dropping/prioritization of flows (similar to WFQ
or CBQ)
Protect traffic of established connections
–
●
Port forward only those on white-list (i.e. firewall)
Differential dropping/prioritization of established vs. new
traffic (via per-flow state kept in router)
Throttle rate of opening new connections
–
Redirect via DNS to send traffic to a puzzle-issuing gatekeeper
i3 vs IP
●
●
i3 good
–
Filtering done at arbitrary points in network versus at access
link
–
Does not require help from ISP
i3 bad
–
Need support for i3
–
Can i3 itself be flooded? May not be efficient enough
Papers covered
●
●
K. Lakshminarayanan, D. Adkins, A. Perrig, I. Stoica,
“Taming IP Packet Flooding Attacks”, HotNets-II.
M. Handley, A. Greenhalgh, “Steps Towards a DoSresistant Internet Architecture”, FDNA 2004.
Defenses
●
Increase end-system software security
●
Reduce ability for worms/viruses to spread
●
Prevent source-address spoofing
●
Prevent reflection attacks
●
Router-based push-back (need previous two defenses)
●
Wide-area service distribution
●
Receiver control of incoming connection attempts
●
Traffic isolation of critical communication (i.e. route
updates)
Model
●
●
Should be a separation between route advertisement and
service advertisement
Routers should have a model that routes only valid
service requests (not just valid IP addresses) and nothing
else
–
Removes client-to-client worms since clients should not
advertise any services
–
Prevents reflector attacks since routers can throw out invalid
service requests
Step 1
●
Separate client and server addresses
–
Only allow client to server communication (no client-client or
server-server)
–
Formalize asymmetry and enforce in the network
–
Impact
●
Slows worm propagation
–
●
Prevents reflector attacks on servers
–
–
–
Must go from client to server to client to server
Must have server=>client=>server
But, client can throw out requests from bogus servers since it knows all valid
requests it has
Some benefits lost when hosts need both client and server
addresses (p2p, VoIP)
Step 2
●
Non-global client addresses
–
Prevents clients from giving up their location and becoming
targets themselves
–
Construct address domain-to-domain as packets travel to
server (easy traceback)
–
Impact
●
●
●
●
●
Source-address spoofing impossible for clients (packet always reveals
path making traceback/pushback easy)
Makes paths symmetric at the domain level
Allows ISP to determine attacks via asymmetry in requests and
responses (?)
Reflection attacks prevented (since no spoofing)
Changeable client addresses require some stable ID above IP (i.e.
HIP)
Step 3
●
RPF checking of server addresses
–
Path-based client addresses do not prevent servers from
spoofing servers
–
Server-to-client communication must follow reverse of
domains from client-to-server
●
●
–
Allows boundary routers to perform a reverse-path forwarding check
on source address of server-to-client packets
Prevents one server from spoofing a response of another server
Impact
●
Makes it hard to launch blind DoS attacks on on-going
communications even if connection ID can be inferred (i.e. TCP RST)
Step 4
●
State setup bit
–
Separate out traffic that requires state to be set up (i.e. TCP
SYNs)
–
Provides generic protocol-independent indication of special
packets
–
Stateful firewalls can validate packets before instantiating state
–
Packets without this bit set can be dropped if no state found
–
Impact
●
●
●
Server addresses can not send packets with state-setup bit set
(mechanism to enforce separation of clients and servers)
Sites might rate-limit outgoing packets with bit set (?)
Problem: Who is setting this bit? Can they be trusted?
Step 5
●
Nonce exchange and puzzles
–
Nonce echoing
–
IP puzzles based on state-setup bit
–
See last week's slides
Step 6
●
Middlewalls
–
Firewalls are too close to systems being protected
–
Use pushback to put filters into the core
–
Have it also issue puzzles
–
Path symmetry enables middlewalls to validate that filtering
requests are authentic (i.e. not spoofed)
–
Problems
●
●
●
●
Lots of network state to keep track of bad flows
Problems with multiple firewalls in a path interacting
Multiple round-trips per request
Same problems with IP puzzles and multiple issuers
Step 7
●
Source-specific multicast+
–
Traditional IP multicast impossible to protect
●
●
–
Senders with ability to instantiate forwarding state
Senders sending to existing mcast group without consent of receivers
Use source-specific multicast groups
●
●
Receivers join to specific source (no way for sender to be malicious
without participation from many receivers)
Problem
–
–
●
Receivers joining a lot of non-existent groups
Receivers joining a bunch of high-bandwidth sources
Solutions
–
–
–
Cryptographically generated addresses
Two-pass join mechanism (validate group liveness before instantiating state)
Threshold for number of SSM groups one can join
Collateral damage
●
●
Loss of symmetry
–
Clients vs. servers (P2P, VoIP)
–
Require client-client communication
●
Ugly workaround using brokers and borrowed server addresses
●
Reintroduces some of the DoS vlunerabilities that were removed
Tranisition
–
Evolve to explicit separation (start with client, server, unrestricted)
–
DNS
–
●
Distribute top level entries via multicast
●
Minimize relaying
SMTP, NNTP, SIP
●
Same as with DNS