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. August 2, 2001 -- FTN PI Meeting2 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 Douglas Reeves, Peter WurmanN.C. State University {reeves,wurman}@csc.ncsu.edu (919) 515-2044 S. Felix WuU.C. Davis wu@cs.ucdavis.edu (530) 754-7070 Dan Stephenson,Xiaoyong WuMCNC {stevenso,xwu}@mcnc.org

3. NC State / UC Davis / MCNC August 2, 2001 -- FTN PI Meeting3 Scope of the Project CategoryControl FlowData FlowPrevention from Misuse ProtectDetect Attacks ProtectDetect Attacks IntservRSVP authenticat ion Pricing Trust-based allocation Reliable multicast DiffServ 1.Intrusion detection Pricing Queue Management Reliable multicast Packet dropping analysis Security Policy 2.IPSec Policy generation, correctness Application level Traceback Watermar king, Traffic correlation

4. NC State / UC Davis / MCNC August 2, 2001 -- FTN PI Meeting4 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. NC State / UC Davis / MCNC August 2, 2001 -- FTN PI Meeting5 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. NC State / UC Davis / MCNC August 2, 2001 -- FTN PI Meeting6 1. DiffServ Intrusion Detection Work by Xiaoyong Wu of MCNC

7. NC State / UC Davis / MCNC August 2, 2001 -- FTN PI Meeting7 DiffServ Components H H H H H H C E E E E C C C C Vulnerabilities -Packet dropping -Packet remarking -Packet delaying

8. NC State / UC Davis / MCNC August 2, 2001 -- FTN PI Meeting8 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 DSMonTrafMon StatRule Linux Kernel DiffServ Implementation LibPCAP Fast Packet Capturing Local & Remote Correlation

9. NC State / UC Davis / MCNC August 2, 2001 -- FTN PI Meeting9 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. NC State / UC Davis / MCNC August 2, 2001 -- FTN PI Meeting10 Goodness of Fit Test –H 0 : The data follows a "given" distribution –H 1 : The data does not follow the specified distribution Obtain the Chi-Squared Value –O = Observed value –E = Expected value –  2 =  (((O-E) 2 )/E) Notes –The range of   is from 0 to infinity NIDES/JiNao Statistical Analysis (Anomaly-based detection)

11. NC State / UC Davis / MCNC August 2, 2001 -- FTN PI Meeting11 Similarity “Score” Counting Measures –Byte count and packet count Score Value - "Normalized" Q Value –S =  -1 (1-(TP/2)) –TP = P m + P m+1 +... + P max  is the cumulative distribution function of a N(0,1) variable –P m is the relative frequency with which  2 belongs to the m th interval –M and max are manually selected at present

12. NC State / UC Davis / MCNC August 2, 2001 -- FTN PI Meeting12 Long Term Q Distribution Examples Background Traffic (Poisson) –4Mbps –Byte counts Audio Traffic (Periodic) –64Kbps –Byte counts

13. NC State / UC Davis / MCNC August 2, 2001 -- FTN PI Meeting13 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. NC State / UC Davis / MCNC August 2, 2001 -- FTN PI Meeting14 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. NC State / UC Davis / MCNC August 2, 2001 -- FTN PI Meeting15 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. NC State / UC Davis / MCNC August 2, 2001 -- FTN PI Meeting16 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 R1 R2 BE EF

17. NC State / UC Davis / MCNC August 2, 2001 -- FTN PI Meeting17 Detection Results

18. NC State / UC Davis / MCNC August 2, 2001 -- FTN PI Meeting18 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. NC State / UC Davis / MCNC August 2, 2001 -- FTN PI Meeting19 2. IPSec Policy Generation and Correctness “Policy conflicts” for IPSec/VPN: –what will possibly go wrong? Requirement versus Policy –what are their relationship?

20. NC State / UC Davis / MCNC August 2, 2001 -- FTN PI Meeting20 IPSec Policy: Implementation Policy Policy: –if then 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) BARcRbRd Rb,Rd, ESPA, B

21. NC State / UC Davis / MCNC August 2, 2001 -- FTN PI Meeting21 ASG-1SG-2B XY Example Conflict #1: Privacy and Content Examination

22. NC State / UC Davis / MCNC August 2, 2001 -- FTN PI Meeting22 ASG-1SG-2B XY Example Conflict #2: Selector Confusion

23. NC State / UC Davis / MCNC August 2, 2001 -- FTN PI Meeting23 SG-1.1, SG-2A, B B SG-2 SG-1SG-2.1 SG-1,SG-2.1SG-1.1, SG-2A, B SG-1.1 SG-1.1, SG-2A, B A Example Conflict #3: Tunnel Overlapping

24. NC State / UC Davis / MCNC August 2, 2001 -- FTN PI Meeting24 Policy Conflict IPSec/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. NC State / UC Davis / MCNC August 2, 2001 -- FTN PI Meeting25 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. NC State / UC Davis / MCNC August 2, 2001 -- FTN PI Meeting26 Policy versus Requirement a requirement a set of policy or a requirement a set of policy

27. NC State / UC Davis / MCNC August 2, 2001 -- FTN PI Meeting27 Policy Analysis a set of policy a requirement ????

28. NC State / UC Davis / MCNC August 2, 2001 -- FTN PI Meeting28 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? H2H1RbRd Encryption or Authentication trusted

29. NC State / UC Davis / MCNC August 2, 2001 -- FTN PI Meeting29 IPSec Security Requirement (2) Content Access Requirement (CAR) –Specify the needs to access content of certain traffic 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 CMR: modify CER : examine

30. NC State / UC Davis / MCNC August 2, 2001 -- FTN PI Meeting30 Security Requirement Satisfaction (1) H2H1RcRbRd H2H1RcRbRd 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! Yes! Encryption

31. NC State / UC Davis / MCNC August 2, 2001 -- FTN PI Meeting31 Security Requirement Satisfaction (2) H2H1RcRbRd Content Access Requirement –Certain node needs to access the content, Rb? Rc? Rb: No! Rc: Yes! Security Association Requirement –Some nodes are not allowed to set up SA

32. NC State / UC Davis / MCNC August 2, 2001 -- FTN PI Meeting32 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. NC State / UC Davis / MCNC August 2, 2001 -- FTN PI Meeting33 Example (per flow): 1 2 3 4 5 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:

34. NC State / UC Davis / MCNC August 2, 2001 -- FTN PI Meeting34 Solution: 1 2 3 4 5 ENC AUTH 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:

35. NC State / UC Davis / MCNC August 2, 2001 -- FTN PI Meeting35 Policy Generation CPU Time

36. NC State / UC Davis / MCNC August 2, 2001 -- FTN PI Meeting36 Number of Policy Rules Generated

37. NC State / UC Davis / MCNC August 2, 2001 -- FTN PI Meeting37 Results Collaboration with Nortel Networks For more information: –Policy’2001: requirement specification language –DSOM’2001: automatic policy generation algorithms.