Protecting Network Quality of Service Against Denial of Service Attacks

1. Protecting Network Quality of Service Against Denial of Service Attacks Douglas S. Reeves S. Felix Wu  Dan Stephenson DARPA FTN PI Meeting January 17, 2001

2. Timetable and Participants • Start date = August 1999 • Duration = 36 months • Point of contact = Dr. Kevin Kwiat, AFRL, kevin.kwiat@rl.af.mil, (315) 330-1692 • No clearances

3. QoS - A New Vulnerability • Guaranteeing QoS for a “flow” requires providing adequate resources • If you can't get or keep resources, your QoS is denied • Normal users will try to get maximum QoS without regard to others • Malicious users will try to deny quality of service to others

4. The ARQOS Project:Overview / Basic Strategies • Enforceable resource allocation policies, using pricing • Authorization and authentication to protect QoS signaling • Detect QoS attacks (monitor and analyze) • Other 8-)

5. 1.Pricing: Pay as You Go • Resources are priced, users have to “pay” to get what they want • Policies • "fair" allocations, prioritize users, network optimization, ... • Steps • Measure demand • Compute prices • Distribute prices • Adjust demand • “Appropriate" timescale / resource granularity for pricing?

6. (1a. Pricing) Fixed or Variable Prices? • Some users want lowest price (greatest resource amount) • Some users want predictability (fixed resource amount) • Goal: support both types of users

7. Combining the Two Markets • Split each resource into "available" and "reservable" portions • Users specify their preferences for price vs. predictability • Compute prices separately for available and reservable parts

8. User Preferences

9. Reservation Market Example

10. Results • Ability to trade off risk (unpredictability) for reward (low prices) very flexibly • No other system combines reservations and dynamic pricing • Independent of the mechanism for computing reserved prices • We predicted future demand from past demand for demonstration purposes

11. (1b. Pricing) Implementation • Conventional Resource Reservation (no pricing)

12. Implementation with pricing (now)

13. Implementation with pricing and authorization (next)

14. 2. Authorizing Resource Allocation • Setting up connections • Control plane: Authenticate, authorize, and manage requests for services • Bearer plane: Admission control and resource reservation • These have to be coordinated! • Who does what? • Hosts request the services • Session management servers implement the control plane • Policy servers and routers implement the bearer plane

15. Network Relationships

16. The Evolving Network Model • Bearer path (even the first hop) highly changeable • E.g., mobility • No one institution owns the whole network any more • Multiple carriers • Multiple service providers • Businesses will partner, but don't want to share secrets or relinquish control • E.g., reluctant to divulge network topology information

17. Our Solution • Session Manager authorizes resource allocation and issues a "ticket" to the Host • Ticket is propagated to Policy Servers • Policy Server uses ticket to verify request is authorized

18. Solution Example

19. Contents of the Ticket (Example) • Originating party IP address/port # • Terminating party IP address/port # • Session identifier • Media stream characteristics being authorized • Authorization lifetime (no stockpiling of tickets!) • Identity of Session Manager (issuing this ticket) • Signature of Session Manager • Prevents tampering with ticket contents

20. Authentication of Ticket • Must not be possible to forge, modify, or reuse a ticket • Assume Key Exchange Server (KES) exists and is trusted • Signature based on Session Manager's key • Policy Server requests key of Session Manager from Key Exchange Server for decryption • key can be cached to reduce overhead

21. Protocol Impacts • RSVP "Identity Representation" • Existing proposal for inserting authorization objects into RSVP messages • COPS • Already contains authorization “object” • Session Description Protocol (SDP) • a few new fields added to SDP (carried by SIP)

22. Discussion • Compatible with mobile IP networks, appears attractive for 3G wireless • Session Manager oblivious to the topology of the bearer path • Integrate authorization / authentication with allocation • Establish trust before allocating resources • Introduce "credential" methods to ensure trust • Topic #1, BAA01-22!

23. Results • Reeves and Christie (Nortel): patent application, October 2000 • Hamer and Gage (Nortel): IETF submission draft-hamer-sip-session-auth-00.txt, November 2000 • Prototypes being implemented by Nortel and N.C. State

24. 3. Packet Dropping Attacks • Maliciously cause packets to be dropped • All packets? Too obvious • Some random packets • Some important packets, e.g., retransmission packet • Hard to detect • Packet loss might be due to normal network congestion

25. Ways to Implement Dropping Attacks • Compromise intermediate routers • Easy to manipulate the victim's traffic • Hard to detect • Difficult to accomplish • Congest intermediate routers • Hard to accurately control the dropping • Easier to detect • Easy to accomplish, e.g., Tribe Flood Network

26. Internet Experiment Setting • 4 FTP Servers across the Internet • FTP client runs Linux 2.0.36 in SHANG lab • Size of downloaded file is 5.5MB • Attack Agent • runs on the same host as FTP client • act as a compromised router FTP Client on Linux FTP FTP Server xyz.zip 5.5M Attack Agent Data Packets Divert Socket

27. Experiments over the Internet FTP Client NCSU FTP Servers Heidelberg NCU SingNet UIUC

28. Results: Impact on Average Pkt. Delay 7 packets are dropped among more than 4000 packets in a connection

29. Q-Test Detection Mechanism • Based on ideas from NIDES-STAT (SRI) • Collect data on “normal” behavior • Compare expected distribution vs observed distribution • Is the deviation significant? • Implementation: TDSAM

30. Q-Distribution for Position of Dropped Packets

31. Results • Performance • False alarm rate: 1.1% ~ 5.8% • Detection rate: high on most cases except for those causing very minor damage • Best results: use combined metrics

32. Results: Position Measure

33. Results: Delay Measure

34. Results: Packet Loss Rate Measure

35. 4. Policy Consistency Checking • IPSec policies are created by administrators to establish VPNs • The set of policies is supposed to implement a set of high-level requirements • Ex. policy 1 + policy 2 + policy 3 = no data transmitted in the clear between site A and site B • How can you tell if set of policies conflicts?

36. Example of a Policy Conflict • Security policies • P1 = all packets from H1 to H2 must be authenticated to SW2 • P2 = all packets from H1 to H2 must be encrypted from FW1 to SW2 • Result • P1 changes src/dest of packets from H1/H2 to H1/SW2 • P2 is not invoked on these packets, which are therefore not encrypted • Security breach! H1 FW1 SW2 H2

37. Status • Define language to specify high-level requirements • Define what consistency checking of policies means • Create polynomial algorithm to check for conflicts • Resolve policy conflicts if they are found • Tech transfer opportunity with Nortel

38. Deliverables • Accomplished • Congestion pricing system papers • Papers: iwqos, icnp (3 times), net2k, policy 2001, ... • Software: packet dropping attack analysis, RSVP authentication • Patents, standards submissions, implementation: tech transfer to Nortel • Future • Software: RSVP / policy server / COPS, Authorization, TCP with pricing, DiffServ attack analysis • Final report