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

2. 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

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

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

5. 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

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

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

8. 03:02:54
TVA Overview

9. 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.

10. 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.

11. 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.

12. 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.

13. 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.

14. 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.

15. 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.

16. 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.

17. 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

18. 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

19. TVA Implementation

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

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

22. 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

23. 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

24. Simulation & Results

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

26. 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

27. 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

28. 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

29. Deployment Compatible with current Internet
Can be deployed incrementally

30. 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

31. 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

33. Thank you 