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 DARPA FTN PI Meeting August 2, 2001 NC State / UC Davis / MCNC

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

3. Scope of the Project

4. Results • Accomplished • Approximately 15 published papers to date • 5 students graduated, 7 more in progress • Software: packet dropping attack analysis, RSVP authentication, RSVP pricing, trust-based allocation (and more to come) • Patent and standards submissions • Collaborations with Nortel

5. Disappointments (Failures) • Failure of QoS to be deployed on a widespread basis in the Internet • lack of security / fault tolerance a major reason? • Pricing • requirements for adoption • TCP Packet Dropping attacks • limitations of neural nets

6. 1. DiffServ Intrusion Detection • Work by Xiaoyong Wu of MCNC

7. DiffServ Components H H C C E H E C C C E E H H H • Vulnerabilities • Packet dropping • Packet remarking • Packet delaying

8. Intrusion Detection Architecture • Network monitoring • DiffServ aggregated flow monitor • Micro-flow traffic monitor • Anomaly (statistical analysis) detection • Rule based detection • Detection and analysis result correlation Local & Remote Correlation Stat Rule DSMon TrafMon Linux Kernel LibPCAP DiffServ Fast Packet Implementation Capturing

9. Network Monitors • Communicate with Statistical Analysis and Rule-based Detection Modules • Monitor Both Aggregated Flows and Microflows • DiffServ aggregated flow monitor • Periodically extract statistical values from Linux kernel using Traffic Controller Library (libtc) • Bytes and packets delivered • Over-limit and dropped packets • Micro-flow traffic monitor • Micro-flow is defined by a traffic filter • Uses Fast Packet Capturing (libpcap)

10. NIDES/JiNao Statistical Analysis (Anomaly-based detection) • Goodness of Fit Test • H0: The data follows a "given" distribution • H1: The data does not follow the specified distribution • Obtain the Chi-Squared Value • O = Observed value • E = Expected value • c2 = S (((O-E)2)/E) • Notes • The range of c2 is from 0 to infinity

11. Similarity “Score” • Counting Measures • Byte count and packet count • Score Value - "Normalized" Q Value • S = F-1(1-(TP/2)) • TP = Pm + Pm+1 + ... + Pmax • F is the cumulative distribution function of a N(0,1) variable • Pm is the relative frequency with which c2 belongs to the mth interval • M and max are manually selected at present

12. Long Term Q Distribution Examples • Background Traffic (Poisson) • 4Mbps • Byte counts • Audio Traffic (Periodic) • 64Kbps • Byte counts

13. Rule Based Detection • Meant to Detect Known Attacks and Vulnerabilities • Rules from RFC's and Real Deployments • Expedited Forwarding • No-Dropping Rule of inlimit traffic • No-Overlimit Rule, within diffserv network • Static Traffic Markings (DSCP's) • Mark Mapping Rule for a microflow

14. Attack Implementation • Linux Kernel Module • Runs in kernel space • Uses proc file system to configure • Emulated Scenarios • Planned: tunable packet delay distributions • congestion and background loss – aggregated flow • bandwidth limitation -- microflow • Planned: packet reordering / duplication

15. Traffic Generation Tools • tcpTalk • Audio Traffic • TCP • MGEN • Background Traffic and Attack Traffic • UDP • CBR or Poisson • Thttp (future) • Background Traffic • TCP (HTTP, FTP, SMTP, NNTP, etc.) • Emulate the traffic at the Internet core • Generate the packets based on the pre-calculated distributions

16. Detection Scenario and Performance • R1, R2 are 2 DiffServ routers with IDS running • R1 and R2 collect long term behaviors for BE traffics and EF traffics • R1 is compromised and starts to mark one BE flow as EF • Rule detection on R2 notices change of marking for BE flow • Accumulated increased EF traffics deviate from the long term EF behavior • Stat analysis on R2 notices the deviation • Performance • With 1% false alarm rate we can get 100% detection rate BE EF R1 R2

17. Detection Results

18. Collaboration and Future Work • Collaboration with Avaya Systems • Network evaluation for Voice over IP solutions • Interested in the impact of intrusions on voice traffic • Interested in monitoring mechanisms • Local and Remote Correlation • Bayesian belief networks

19. 2. IPSec Policy Generation and Correctness • “Policy conflicts” for IPSec/VPN: • what will possibly go wrong? • Requirement versus Policy • what are their relationship?

20. IPSec Policy:Implementation Policy • Policy: • if <condition> then <action> • IPSec policy: • Condition: src,dst,src-port,dst-port, protocol, … • Action: Deny | Allow | ipsec (entry, exit, mode, sec-prot, alg) • Example: • Condition: src=A, dst=B, port=*, prot=TCP • Action: ipsec (Rb, Rd, tun, ESP, 3DES) Rb,Rd, ESP A, B A, B A Rb Rc Rd B

21. Example Conflict #1:Privacy and Content Examination X Y A SG-1 SG-2 B

22. Example Conflict #2:Selector Confusion X Y A SG-1 SG-2 B

23. Example Conflict #3:Tunnel Overlapping SG-1.1, SG-2 A, B A, B SG-2 A B SG-1.1 SG-1 SG-2.1 SG-1,SG-2.1 SG-1.1, SG-2 A, B SG-1.1, SG-2 A, B

24. Policy ConflictIPSec/VPN Policy • A set of (implementation) policies does not quite work well together such that the packets (information bits) are either dropped or revealed/sent unsafely. • Requirement(s): Intention(s) behind the implementation-level policies: • e.g., I want to maintain the privacy of certain flows: • IPSec ESP Tunnels. • Conflicts: • a set of policies together does not support the requirements • requirements conflict among themselves.

25. Policy versus Requirement • Policy: (implementation, low-level) • How should a network entity or a policy domain handle a particular flow of packets functionally? • Currently, the processing is based on the selector (i.e., the packet header information). • Requirement: (intention, high-level) • How should a particular set/flow of packets (information bits) be protected and handled from A to B? • Even if the packet header changes, the information bits in the payload should still be protected in the same way.

26. Policy versus Requirement a set of policy or a requirement a set of policy a set of policy a requirement a set of policy

27. Policy Analysis a requirement a requirement a set of policy a set of policy a set of policy ???? a requirement

28. IPSec Security Requirements (1) • Access Control Requirement (ACR) • Restrict access only to trusted traffic • E.g. Deny all telnet traffic • Security Coverage Requirement (SCR) • Apply security functions to prevent traffic from being compromised during transmission across certain area. +who can be trusted? trusted H1 Rb Rd H2 Encryption or Authentication

29. IPSec Security Requirement (2) • Content Access Requirement (CAR) • Specify the needs to access content of certain traffic CMR: modify CER : examine I will examine the content for intrusion detection • Security Association Requirement (SAR) • Specify trust/distrust relationship in SA setup X Can not set up SA

30. Encryption Encryption Security Requirement Satisfaction (1) • Access Control Requirement - deny or allow • Security Coverage Requirement • All the links and nodes in the area will need to be covered by specified security No! H1 Rb Rc Rd H2 Yes! H1 Rb Rc Rd H2

31. Security Requirement Satisfaction (2) • Content Access Requirement • Certain node needs to access the content, Rb? Rc? Rb: No! Rc: Yes! H1 Rb Rc Rd H2 • Security Association Requirement • Some nodes are not allowed to set up SA

32. IPSec Requirement Spec. • Formal specification: • ACR-SCR-CAR-SAR • Conflict Detection in Requirements: • Requirement Satisfiability Problem (RSP): given a set of requirements, an algorithm to check whether at all possible to find a set of policies to satisfy all the requirements. • Completeness Proof • Policy Determination: • Transformation: if possible, an algorithm to find the “optimal” set of policies. • Correctness and Efficiency

33. SCR#1: ENC 2-4 trusted 3 SCR#2: AUTH 1-4 trusted 3 SCR#3: ENC 3-5 trusted 4 CAR#1: (ENC, AUTH) by 4 SAR#1: not-ENC 2-5 SAR#2: not-ENC 1-5 SAR#3: not-AUTH 1-4 Coverage: Content: SA relation: Example (per flow): 1 2 3 4 5

34. SCR#1: ENC 2-4 trusted 3 SCR#2: AUTH 1-4 trusted 3 SCR#3: ENC 3-5 trusted 4 CAR#1: (ENC, AUTH) by 4 SAR#1: not-ENC 2-5 SAR#2: not-ENC 1-5 SAR#3: not-AUTH 1-4 Coverage: Content: SA relation: Solution: ENC ENC AUTH AUTH 1 2 3 4 5

35. Policy Generation CPU Time

36. Number of Policy Rules Generated

37. Results • Collaboration with Nortel Networks • For more information: • Policy’2001: requirement specification language • DSOM’2001: automatic policy generation algorithms.