Papers covered● K. Lakshminarayanan, D. Adkins, A. Perrig, I. Stoica,

“Taming IP Packet Flooding Attacks”, HotNets-II.● M. Handley, A. Greenhalgh, “Steps Towards a DoS-

resistant 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 (content-

addressable 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

– IP addresses hidden and identifiers of public triggers are the only information exposed

● 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

– 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

– Port forward only those on white-list (i.e. firewall)● 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

– 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 DoS-

resistant 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– Must go from client to server to client to server

● Prevents reflector attacks on servers– 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