A DoS-limiting Network Architecture 03:02:54 A DoS-limiting Network Architecture Presented by Miao 9/19/2018

About this presentation 03:02:54 About this presentation Reference: Xiaowei Yang, etc., “A DoS-limiting Network Architecture”. SIGCOMM’05, Philadelphia, PA, USA, 2005 Design and evaluation of a network architecture, called TVA Aims at limiting DoS attacks

Outline Introduction Related work TVA Overview TVA Implementation Simulation & Results Conclusion

What is DoS attack? DoS attacks: make a computer unavailable to its intended users Smurf attack Clogging attack SYN flooding attack

Related work Many research works focus on specific DoS attacks Others Fair queue: Share the bandwidth fairly, but… What if many hosts attack the link? Pushback: Drop unwanted packets, but… How to discriminate attack traffic? SIFF: Traffic should be authorized by receivers, but… Requests are treated with low priority Attackers are granted by accident

Purpose of this paper Design a DoS-limiting network architecture Provide a comprehensive solution to the DoS problem Traffic Validation Architecture (TVA)

Goal of TVA Against broader set of possible DoS attacks Easy to be implemented in practical Easy to be deployed in current running network

03:02:54 TVA Overview

Capabilities Queue management Granted by destination to sender 03:02:54 Capabilities Granted by destination to sender Queue management Different queues according to different types of traffic Tva is based on two concepts: capability and queue management. Capability is a kind of authorization which is granted by the receiver to the sender. Only if the sender gets this authorization, can its packet be treated as regular traffic. In TVA, traffics are divided into 3 types. Different type of traffics is treated separately.

Capabilities Ideas behind capabilities Identify wanted packets 03:02:54 Capabilities Ideas behind capabilities Identify wanted packets Discard unwanted packets How? Each packet carries some info Each router check this info This info is capabilities Now let’s go to the details. First, let’s see what is capability. Right now, I mentioned that capability is an authorization granted by the receivers. The idea behind capability is that the receiver will identify those packets which he wanted. For those unwanted packets, they will be discarded. Then how does capability work? First, each packet carries some info. Then later on, each router check this info. We call this info as capabilities.

Requirements of capabilities 03:02:54 Requirements of capabilities Bootstrap Unforgeable Verification without trusting hosts Expiration Little overhead In order to make capa work perfect, we should think about several questions. 1st, how does a receiver issue capa. 2nd, how can we make sure the capa cannot be forged. 3rd, how does a router verify capa without prior knowledge. Also, we should think about expiration and overhead of capa. We’ll discuss these questions one by one.

Bootstrapping Request/Response Limiting requests Sending reqeust 03:02:54 Bootstrapping Request/Response Sending reqeust Each router adds info Destination adds info Sending back reply Limiting requests Reason: in case of request flooding Based on path-iden. First let’s see how does the receiver issue capabilities. This is implemented by request & response. This figure shows how it works. First a sender send a request to dest for capabilities. When the req goes through routers, each router adds some info to the req. when the req arrives at dest, it check whether this traffic is he wanted. If it is, he will add info to the requ and send it back as a response. Now let’s think about one scenario, if attackers flood requests, then legitimate clients will not be able to get capabilities. Because of this, we must limit requests. This is implemented by queuing management based on path-iden. Each router in a trusted domain will tag the request and this tag act as an identifier. Requests from the same upstream will be sent to the same queue. So if one path is flooded, it will not affect other paths.

Unforgeable Each router adds pre-capability How to check? 03:02:54 Unforgeable Each router adds pre-capability Timestamp and hash value Bound to specific path-iden. How to check? Check hash value with all inputs (src/dst IP, timestamp, and secret) Why unforgeable? Secret only known to himself Now let’s see how can we make sure that capa is not able to be forged. In order to make capa unforgeable, each router will add some info into the packet. The info contains a timestamp & hash value. This info is bound to a path-iden. The 2nd req is capability is unforgeable. In order to achieve this req, each router adds pre-capa. It contains a timestamp and a hash value. This will be bounded to a specific path-iden. To verify whether a capability is forged or not, a router can simply check the hash value. Notice that, the secret is only known to the router itself.

Fine-grained capability 03:02:54 Fine-grained capability Why Fine-grained? Wrong decisions DoS can be initiated even in short time Solution Limit data amount as well as data duration (N & T) How to work? Check integrity Check time Check amount of data sent The next step is to see fine grained capa. The reason why we need fine grained capa is because of wrong decisions. Notice that even in a short time, dos attack can make serious damage. To avoid the flooding made by wrong decisions, the authors also proposed to make fine-grained capability. This is because even in very short time, dos attack can make very serious damage. In order to make fine-grained capability, the dest will add N & T in the capability and hash them with pre-capability. Now when a router receives a packet from the sender, it will perform 3 checks: 1st, check the integrity to see if the capability is forged. 2nd, check time to see if the capability is expired 3rd, check how much data has been sent so far. Regarding the 3rd step, we can see that a router keep track of the amount of data sent by a sender. However, this will increase the storage cost of a router. So the author propose bounded router state.

Bounded router state Router memory exhausting 03:02:54 Bounded router state Router memory exhausting Lots of connections by colluding attackers To avoid memory exhausting: Keep track according to flow rates ttl Achievement Only fixed memory is needed At most 2N bytes can be sent in T seconds In last slides, I mentioned that a router must remember how much data has been sent by a sender. However, this will increase a router’s storage cost. Let’s think about this scenario, To avoid this attack, the router will only keep states for those senders whose flow rate is lager than N/T. it sets ttl for a state. Ttl decreases with time passing and increases when subsequent packet arrives By doing this, only fixed memory is needed for a router and at most 2n bytes can be sent in t seconds.

Capability efficiency 03:02:54 Capability efficiency Tradeoff between security & efficiency Long: secure but not bandwidth efficient Short: efficient but vulnerable to brute-force attack Solution Long capability + cache capability at routers How to work Packets include a flow nonce Routers cache info for the first time Subsequent packets omit long capability Routers use src/dst IP and flow nonce to look up cache now let’s think about trade off between capa security and effi. If the capa is long enough, which means use more bits to hold info, then obviously it will be more secure. However, it will take some extra bandwidth. On the other hand, if the capa is short, then the bandwidth overhead is small but it’s vulnerable to brute-force attack. So the solution is using cache capa as well as long capa.

Requirements of capabilities Bootstrap: Request/response protocol Unforgeable: Hash in capability & Router’s secret Verification without trusting host: Hash in capability Expiration: Fine-grained capability Little overhead: Bounded router state &Cache capability

Other concerns Route changes and failures Balancing authorized traffic Treat as legacy packets Re-acquiring capability Balancing authorized traffic To counter colluding attackers Use fair queue on authorized flows

TVA Implementation

Three elements in TVA protocol Packets that carry capability End hosts Routers that check capability

Packets with capability Three types of packets: Request packets for capability Regular packets Legacy packets

End hosts Sender requests for transmission Destination replies sender Accept: reply with capabilities Refuse: reply with empty capabilities Sender transfers data First with both capability and flow nonce Later on, only flow nonce is needed Sender models router behavior Capability expiration Cache expiration

Routers Different traffic goes to different queue Request: Regular: add pre-capability and path-iden Regular: Check if it is valid Legacy: Put it in a queue with low priority

Simulation & Results

Comparison among the following mechanisms: TVA SIFF Pushback Legacy Internet Simulated on Legacy packet floods Request packet floods Authorized packet floods Simulation topo

Result – legacy packet floods TVA – performs the best Legacy traffic is treated with lower priority than request SIFF – performance drops when attack intensities increase Legacy and request are treated equally with low priority Pushback – performance drops when too many attackers Attack traffic becomes harder to identified Internet is the worst

Result – request packet floods TVA performs the best Because of rate-limit on requests SIFF, pushback and Internet – similar with previous result Treat requests as legacy traffic

Result – authorized packet floods TVA performs the best Fair queue on regular traffic Fine-grained control on bandwidth SIFF – drops sharply when overloaded Request is treated with low priority Pushback & Internet – drops with intense attack No difference among legacy, request, and authorized packets

Deployment Compatible with current Internet Can be deployed incrementally

Conclusion TVA is a framework that can limit many possible DoS attacks TVA uses capability to authorize senders TVA is easy to be implemented and deployed

My concerns No mechanisms to distinguish malicious traffic What if replay attack on capability Need global time synchronization Implemented by piggybacking info in IP packet What if using UDP

Thank you 