1 / 21

Network capabilities and DDoS

Network capabilities and DDoS. Based on the TVA paper from Sigcomm 2005. Enterprise vs wide-area s ecurity. Key differences in communication model Enterprises: Default-off SANE and Ethane make sense Wide-area: Default-on Enterprise solutions don’t work

tymon
Télécharger la présentation

Network capabilities and DDoS

An Image/Link below is provided (as is) to download presentation Download Policy: Content on the Website is provided to you AS IS for your information and personal use and may not be sold / licensed / shared on other websites without getting consent from its author. Content is provided to you AS IS for your information and personal use only. Download presentation by click this link. While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server. During download, if you can't get a presentation, the file might be deleted by the publisher.

E N D

Presentation Transcript

  1. Network capabilities and DDoS Based on the TVA paper from Sigcomm 2005

  2. Enterprise vs wide-area security • Key differences in communication model • Enterprises: Default-off • SANE and Ethane make sense • Wide-area: Default-on • Enterprise solutions don’t work • Vested interest in being globally accessible • Wide-area security: several issues • Server resource management (access link, CPU, memory) • DDoS research • Network resource management (protecting network against attacks) • Server security and break-ins

  3. DoS is not even close to be solved • Address validation is insufficient (botnets) • Traceback is too little too late (detection only) • Pushback lacks discrimination (imprecise) • Secure overlay filtering requires offline authenticators (public servers) 

  4. 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. • Anderson et al. [Anderson03], Yarr et al. [Yarr04]

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

  6. 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 • Request or authorized packet floods • Added functionality in a router’s forwarding path • Authorization policies • Deployment • TVA addresses all of the above.

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

  8. Request packet floods • Request packets do not carry capabilities.

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

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

  11. Authorized packet floods cap cap cap cap cap

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

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

  14. cap2 cap1 TVA’s implementation of capabilities • 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 pre2 pre1 

  15. data cap2 cap1 Validating fine-grained capabilities • A router verifies that the hash value is correct. • Checks for expiration: timestamp + T · now • Checks for byte bound: sent + pkt_len · N N, T, timestamp, hash(pre-cap, N, T) 

  16. data cap2 cap1 Bounded state • 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) N, T, timestamp, hash(pre-cap, N, T)  sent + pkt_len · N

  17. Worst case byte bound is 2N in T seconds • If a slot expires, it indicates that a capability sends slower than N/T. bytes · N TTL average rate · N/T average rate · N/T bytes · N t5 t4 t2 t1 t3 t · T T 0 a slot is expired a slot is created

  18. Bounded number of queues Queue on most recent tags • Tag space bounds the number of request queues. • Number of destination queues is bounded by C/R 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

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

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

  21. Conclusion • Key contribution • a comprehensive and practical capability system for the first time. • We made TVA practical in three aspects • Counter a broad range of attacks • Bounded state and computation • Simple and effective authorization policies • Coming next • Testbed implementation • Request rate limit, queuing scheme • Robust service differentiation • Traffic with different priority

More Related