NC State / UC Davis / MCNC 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

NC State / UC Davis / MCNC January 17, FTN PI Meeting2 Timetable and Participants Start date = August 1999 Duration = 36 months Point of contact = Dr. Kevin Kwiat, AFRL, (315) No clearances Douglas ReevesN.C. State University (919) S. Felix WuU.C. Davis (530) Dan StephensonMCNC

NC State / UC Davis / MCNC January 17, FTN PI Meeting3 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

NC State / UC Davis / MCNC January 17, FTN PI Meeting4 The ARQOS Project: Overview / Basic Strategies 1.Enforceable resource allocation policies, using pricing 2.Authorization and authentication to protect QoS signaling 3.Detect QoS attacks (monitor and analyze) 4.Other 8-)

NC State / UC Davis / MCNC January 17, FTN PI Meeting5 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?

NC State / UC Davis / MCNC January 17, FTN PI Meeting6 (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

NC State / UC Davis / MCNC January 17, FTN PI Meeting7 “Spot” (Variable) Market Timing User demands and resource prices change dynamically, asynchronously Changes in Demand Price Adjustments Time

NC State / UC Davis / MCNC January 17, FTN PI Meeting8 Spot Market Example 160 users, MPEG video traffic, standard benchmark network

NC State / UC Davis / MCNC January 17, FTN PI Meeting9 Spot Market Properties Fully distributed Asynchronous, dynamic Low overhead Provably fair Provably optimal But… unpredictable prices

NC State / UC Davis / MCNC January 17, FTN PI Meeting10 Predictability: The Reservation Market Changes in Demand Price Adjustments Time Pricing Periods

NC State / UC Davis / MCNC January 17, FTN PI Meeting11 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

NC State / UC Davis / MCNC January 17, FTN PI Meeting12 User Preferences

NC State / UC Davis / MCNC January 17, FTN PI Meeting13 Reservation Market Example

NC State / UC Davis / MCNC January 17, FTN PI Meeting14 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

NC State / UC Davis / MCNC January 17, FTN PI Meeting15 (1b. Pricing) Implementation Conventional Resource Reservation (no pricing)

NC State / UC Davis / MCNC January 17, FTN PI Meeting16 Implementation with pricing (now)

NC State / UC Davis / MCNC January 17, FTN PI Meeting17 Implementation with pricing and authorization (next)

NC State / UC Davis / MCNC January 17, FTN PI Meeting18 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

NC State / UC Davis / MCNC January 17, FTN PI Meeting19 Network Relationships

NC State / UC Davis / MCNC January 17, FTN PI Meeting20 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

NC State / UC Davis / MCNC January 17, FTN PI Meeting21 Our Solution 1.Session Manager authorizes resource allocation and issues a "ticket" to the Host 2.Ticket is propagated to Policy Servers 3.Policy Server uses ticket to verify request is authorized

NC State / UC Davis / MCNC January 17, FTN PI Meeting22 Solution Example

NC State / UC Davis / MCNC January 17, FTN PI Meeting23 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

NC State / UC Davis / MCNC January 17, FTN PI Meeting24 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

NC State / UC Davis / MCNC January 17, FTN PI Meeting25 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)

NC State / UC Davis / MCNC January 17, FTN PI Meeting26 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!

NC State / UC Davis / MCNC January 17, FTN PI Meeting27 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

NC State / UC Davis / MCNC January 17, FTN PI Meeting28 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

NC State / UC Davis / MCNC January 17, FTN PI Meeting29 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

NC State / UC Davis / MCNC January 17, FTN PI Meeting30 Experiment Setting 4 FTP Servers across the Internet FTP client runs Linux in SHANG lab Size of downloaded file is 5.5MB Attack Agent 4runs on the same host as FTP client 4act as a compromised router FTP Interne t Divert Socket FTP Client on Linux xyz.zip 5.5M FTP Server Attack Agent Data Packets

NC State / UC Davis / MCNC January 17, FTN PI Meeting31 Experiments over the Internet FTP Client NCSU FTP Servers Heidelberg NCU SingNet UIUC

NC State / UC Davis / MCNC January 17, FTN PI Meeting32 Results: Impact on Average Pkt. Delay 7 packets are dropped among more than 4000 packets in a connection

NC State / UC Davis / MCNC January 17, FTN PI Meeting33 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

NC State / UC Davis / MCNC January 17, FTN PI Meeting34 Example Experiment Long-Term profile –nbin = 5, bin-width =800 –p 1 = , p 2 = , p 3 = , p 4 = , p 5 = PerPD(20,4,5) –drop packets only in the first 85. –p 1 = , p 2 = , p 3 = , p 4 = , p 5 =

NC State / UC Davis / MCNC January 17, FTN PI Meeting35 Q-Distribution for Position of Dropped Packets

NC State / UC Davis / MCNC January 17, FTN PI Meeting36 Q-Distribution for Packet Delay

NC State / UC Davis / MCNC January 17, FTN PI Meeting37 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

NC State / UC Davis / MCNC January 17, FTN PI Meeting38 Results: Position Measure

NC State / UC Davis / MCNC January 17, FTN PI Meeting39 Results: Delay Measure

NC State / UC Davis / MCNC January 17, FTN PI Meeting40 Results: Packet Loss Rate Measure

NC State / UC Davis / MCNC January 17, FTN PI Meeting41 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?

NC State / UC Davis / MCNC January 17, FTN PI Meeting42 H1FW1SW2 H2 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!

NC State / UC Davis / MCNC January 17, FTN PI Meeting43 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

NC State / UC Davis / MCNC January 17, FTN PI Meeting44 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