CompSci 514 Computer Networks Lecture 20: Combating Denial of - PowerPoint PPT Presentation

CompSci 514 Computer Networks Lecture 20: Combating Denial of Service Attacks Xiaowei Yang

How to Attack : Exhausting shared resources L • Flooding traffic to exhaust the bandwidth, memory, or CPU of a victim – Spoof addresses to hide • Passport – Distributed DoS (DDoS) to hide and to maximize damage • Multiple (weak) machines against (strong) victim

Defending against bandwidth attacks is difficult Bottleneck Link L ISP network Victim network • Effective defense requires packets drop before the bottleneck – ISPs must drop flood packets before they reach the victim networks – But only destinations know what packets are desired – Anti-distributed DoS services cost around $12,000 per month from carriers such as AT&T and MCI

Large Scale of Attacks Arbor report, 2017

Frequency of attacks seen by ISPs

Defense paradigm • Capability-based approaches – Ask before a sender can send • TVA • Filter-based approaches – Block unwanted traffic • Pushback, StopIt • Overlay-based filtering – Protect specific servers • Phalanx

TVA: A DoS-limiting Network Architecture

Capabilities are a promising approach • Destination control – The destinations know better. • Network filtering based on explicit and unforgeable packet state, i.e., capabilities – Only the network can shed load before the damage has been made.

Sketch of the capability approach J cap 1. Source requests permission to send. 2. Destination authorizes source for limited transfer, e.g, 32KB in 10 secs • A capability is the proof of a destination’s authorization. 3. Source places capabilities on packets and sends them. 4. Network filters packets based on capabilities.

Capabilities alone do not effectively limit DoS • Goal: minimize the damage of the arbitrary behavior of k attacking hosts. – Non-goal: make DoS impossible • Problems 1. Request or authorized packet floods 2. Added functionality in a router’s forwarding path 3. Authorization policies 4. Deployment • TVA addresses all of the above.

Challenges 1.Counter a broad range of attacks, including request and authorized packet floods 2.Router processing with bounded state and computation 3.Effective authorization policies 4.Incrementally deployable

Request packet floods • Request packets do not carry capabilities.

Counter request packet floods (I) cap cap cap • Rate-limit request packets

Counter request packet floods (II) 1 2 Per path-id queues 1 1 • Rate-limit request packets • Routers insert path identifier tags [Yarr03]. • Hierarchically fair queue requests using the most recent tags.

Authorized packet floods cap cap cap cap cap

Counter authorized packet floods c a p cap cap cap cap p a c • Per-destination queues • TVA bounds the number of queues.

Challenges 1.Counter a broad range of attacks, including request packet floods and authorized packet floods 2.Router processing with bounded state and computation 3.Effective authorization policies

TVA’s implementation of capabilities pre 2 pre 1 J cap 1 cap 2 • Routers stamp pre-capabilities on request packets – (timestamp, hash(src, dst, key, timestamp)) • Destinations return fine-grained capabilities – (N, T, timestamp, hash(pre-cap, N, T)) – send N bytes in the next T seconds, e.g. 32KB in 10 seconds

Validating fine-grained capabilities N, T, timestamp, hash(pre-cap, N, T) cap 1 cap 2 data J 1. A router verifies that the hash value is correct. 2. Checks for expiration: timestamp + T · now 3. Checks for byte bound: sent + pkt_len · N

Bounded computation • The main computation overhead is hash validation. • On a Pentium Xeon 3.2GHz PC – Stamping pre-capabilities takes 460ns – Validating capabilities takes 1486ns

Bounded state N, T, timestamp, hash(pre-cap, N, T) cap 1 cap 2 data J sent + pkt_len · N • Create a slot if a capability sends faster than N/T. • For a link with a fixed capacity C, there are at most C/(N/T) flows • à Number of slots is bounded by C / (N/T)

Worst case byte bound is 2N in T seconds bytes · N TTL average rate · N/T average rate · N/T bytes · N t 5 t 4 t 2 t 1 t 3 t · T T 0 a slot is created a slot is expired • When a packet with a valid capability arrives, a router will create a slot to track the number of bytes. The time-to-live value of the slot is set proportional to the packet length: TTL+ L/(N/T) • If a slot expires, it indicates that a capability sends slower than N/T.

Bounded number of queues Queue on most recent tags requests path-identifier queue regular packets per-destination queue Y Validate capability N legacy packets low priority queue Keeps a queue if a destination receives faster than a threshold rate R • Tag space bounds the number of request queues. • Number of destination queues is bounded by C/R

Challenges 1.Counter a broad range of attacks, including request packet floods and authorized packet floods 2.Router processing with bounded state and computation 3.Effective authorization policies

Simple policies can be effective • Fine-grained capabilities tolerate authorization mistakes. • Client policy – Authorize requests that match outgoing ones • Public server policy – Authorize all initial requests – Stop misbehaving senders – A server has control over its incoming traffic when overload occurs.

Comments on TVA • Assume destinations can reliably differentiate good and bad • A lot of queues – Path identifier queues and per-destination queues • Denial of capability attacks – Unwanted requests can’t be blocked

Portcullis • A puzzle-based approach to protect the request setup channel • A global puzzle seed is distributed to all routers • A sender solves different levels of puzzles to gain priority on the request channel – Solving a L+1 level puzzle requires twice as much time than solving a L level puzzle – High priority requests sending rate exponentially decreases à no congestion for high priority packets

To Filter or to Authorize: Network-Layer DoS Defense against Multimillion-node Botnets

No Consensus on How to Combat DoS • Capability-based approaches were criticized because of the setup channel vulnerability • Two intriguing schools of thought –Filters –Capabilities

Filters or capabilities? To design a DoS-resistant network architecture, should we use filters, capabilities, neither, or both? “…capabilities are neither “We strongly disagree: … a sufficient nor necessary simple and highly efficient to combat DoS.” network-based defense … can prevent DoC attacks.” by K. Argyraki, et al. by A. Perrig, et al.

Filter-based Approach 1. Anyone can send to anyone by default 2. A receiver requests the network to install filters Filter (A,V) V A

StopIt “We believe in: rough consensus and running code.” -- David Clark 1. Design an effective filter-based system – Existing filter systems have several limitations • Loss of control messages • Filter exhaustion attacks • Damage when filters fail to install 2. Compare the effectiveness of filter-based and capability-based systems under various attacks

Design Goals of StopIt • Effective with little collateral damage – Do not block legitimate communications • Resilient to a wide range of strategic attacks – E.g.: impersonation attacks, filter exhaustion attacks • Fail-safe – Limit the damage when filters fail to install • Incentivizing deployment – Early adopters should benefit immediately

Design Premises • Similar to capability-based systems • Simplifying assumptions – End systems can distinguish attack traffic – Both routers and hosts can be upgraded – Securable intra-AS communications • Practical constraints – No special hardware • E.g.: no tamper-proof hardware, no line-speed per- packet public key operations – Both hosts and routers may be compromised

Overview of an Ideal Filter System AS 1 AS 3 k R s c e AS 2 R d n e l t t o b Block (A,V) A V Scalable: no per-flow state in the network core

Secure the Basic Design Problems Solutions Source address Authenticate source addresses with Passport [NSDI’08] spoofing attacks Impersonation Authenticate filter requests with attacks standard authentication techniques Confirm attacks before accepting Closed control Filter exhaustion filter requests; avoid filters against channel attacks compliant sources; catch and punish misbehaving sources Control channel DoS attacks Source-based fair queuing Filters fail to install Incentives to deploy

Closed Control Channel Filter requests are exchanged StopIt Server between known peers AS 1 AS 3 k c e AS 2 n e l t t o b StopIt Server addresses are published in BGP BGP Prefix Announcement 10.1.0.0/16 StopIt Server Address

Steps to Block Attack Traffic AS 1 AS 3 Block (S,V) k R s c e AS 2 R d n e l t t o b V: Block S S V V: Block S ACK: Block (S,V) End-to-end requests before submitting filter requests Attack confirmation on R d to mitigate filter exhaustion attacks Use source address and IP-ASN mapping to locate source AS Request-ACK between S and R s to mitigate filter exhaustion attacks