1. Securing Real-time Communication Services in Large Scale Networks Dong Xuan Dept. of Computer and Information Science Ohio-state University www.cis.ohio-state.edu/~xuan

2. Outline r Motivation r Background r Challenges r Related work r What we have done r What we will do r Final remarks

3. Motivation r Providing secure and scalable QoS guarantees to real-time applications

4. Real-time (RT) Communication Services Multimedia applications: network audio and video network provides applications with delay guarantees  soft guarantees  Hard guarantees oStatistic oDeterministic Real-Time

5. Mechanisms to support RT r Two planes m Control-Plane Call management (setup, signaling (RSVP) and tear-down) Admission control (delay computation etc) and resource provisioning (off-line), path determination (shortest-path routing, MPLS) etc. m Data-Plane: Packet forwarding (controlled by schedulers, such as rate- based schedulers, e.g. WFQ and priority-based schedulers, e.g. Static Priority) r Two models m Integrated Service (IntServ) m Differentiated Service (DiffServ)

6. Security threats and security services r Security threats: traffic analysis, IP spoofing, denial of service, routing attacks, remote arbitrary code execution, and viruses etc. r Security services: privacy, confidentiality, authentication, non-repudiation, availability, and integrity etc.

7. The large scale network r A large number of nodes distributed in a large scope r Distributed and not centralized r An open system and not secure

8. Challenge 1: Providing scalable RT service is not easy r Solutions demonstrated “in the small” may not work “in the large” m per-call signaling and management at per-element: too complex? do-able in “small” networks modest backbone router sees 250K flows/min Rate-based Priority-based Not Scalable Data Plane Not Scalable Scalable Control Plane Upon a new request, the delay of all existing flows need re-computing

9. Challenge 2: RT service itself is extremely vulnerable r RT service is easy to be targeted due to its importance. r RT service itself is vulnerable due to its semantics. m If the deadline is violated, the packet may be useless, and dropped by the receiver.

10. Challenge 3: RT supporting mechanisms are vulnerable r Signaling: RSVP r Routing: MPLS r Scheduling: WFQ and SP r Marking, shaping, and policing r etc

11. Challenge 4: Securing RT is expensive r Security will introduce extra-delay. The delay should be very small. r More resources are needed.

12. Related work r A lot of work has been done on real-time communications, but we still have a long way to go. r People are busy in working on protecting non-real- time service. r Very few work on this topic: m protecting Network QoS under denial of services NCSU and UC Davis

13. What we have done? r Providing scalable RT services r Preventing real-time traffic analysis r Defending Distributed Denial of Service (DDoS) attack

14. Providing scalable RT service r Objective m Providing QoS guarantees to real-time applications in a scalable fashion

15. Our solution r Utilization-based Admission Control (UBAC) m Static priority scheduler m Efficient admission control m Resource verification at configuration time

16. Our solution Upon a new request, the delay of all existing flows need re-computing Rate-based Priority-based Not Scalable Data Plane Not Scalable Scalable UBAC approach Control Plane

17. Workflow Utilization bound verification Verification of Safe Utilization Delay Computation for Path Delay d α is safeα is not safe Yes No d<D Network parameters, traffic pattern (α: the utilization bound, D = Deadline) At Configuration Time Admission request (D = Deadline, Resource Requirements) U := U + U new yes no U < α ? admitted rejected Admission Control Procedure At Run Time Packet Forwarding with Static Priority Scheduler Utilization-based Admission Control

18. The delay formula the worst case delay of link server k the max number of input links to a router input traffic under min{C*I,  +ρ*I} the ratio of link capacity to higher priority traffic  2 Priorities, Links with the same capacity, 2 classes traffic, …... Observation: it does not depend on dynamic status information!

19. Following up r Implementation m Voice over IP m Video r Extended to soft and statistic guarantees, particularly in wireless networks, where BW keeps changing

20. Preventing RT traffic analysis r Objectives m Keep RT communication anonymous and unobservable It is often thought that communication may be secured by encrypting the traffic, but this has rarely been adequate in practice. Traffic analysis can still be used to trace the user’s on- line/off-line periods, uncover the location of military command center, determine operation mode or alertness state of military units, and analyze the intentions of communications.

21. Our solution r Leverage our research results on RT  Use traffic padding and rerouting approaches to camouflage the real traffic

22. Basic model  Features of IP-based network m Header of the packet are readable by an observer.  Stable mode

23. Example Existing Traffic Pattern Matrix Stable Traffic Pattern Matrix The existing traffic pattern among the hosts are: Host1 Host2 Host3 Host4 Host 1003MB/sec3MB/sec Host 23MB/sec03MB/sec3MB/sec Host 32MB/sec0MB/sec02MB/sec Host 43MB/sec3MB/sec3MB/sec0 The stable traffic pattern among the hosts are: Host1 Host2 Host3 Host4 Host 103MB/sec3MB/sec3MB/sec Host 23MB/sec03MB/sec3MB/sec Host 33MB/sec3MB/sec03MB/sec Host 43MB/sec3MB/sec3MB/sec0

24. Traffic padding  Flooding the network at right place and right time to make it appear to be a constant-rate network  Challenge: How much? For link j,  i F i,j ( I ) + S j ( I ) = C(I) ? ? ?

25. Traffic rerouting  Indirect delivery of packets  Challenge: How to reroute the traffic? H1 H2 H4 H3 3MB/sec 1MB/sec Real Traffic: 5MB/sec from H3 to H2

26. Traffic planning  Link Capacity Constraints  Stabilization Constraints

27. Traffic planning (cont.)  Conservation Constraints  Delay Constraints

28. Following up r How to extend to conduct traffic planning in a distributed fashion? r Redefine stable mode

29. Gateway-based distributed denial of service (DDoS) defense system r Objective m Contain DDoS flooding attack in high-speed networks. Maximize friendly traffic throughput while reducing attack traffic as much as possible. Minimize the disturbance of the defense system on the performance (e.g. delay) of friendly traffic. Achieve high compatibility to the existing systems.

30. DDoS Flooding Attack Model  Network resource consumption behavior – individual flows aggressively consume resources – individual flows behave similar to normal TCP or UDP  Self-marking – TCP – UDP  Source identity – Spoofed source – non-spoofed source  Location – outside the domain – inside and outside the domain

31. Difficulties  TCP traffic makes it hard to apply packet dropping strategies.  DDoS flooding attacks are inherently difficult to detect.  The limited system resources are easily exhausted in attack detection.

32. Our solution  We adopt a gateway based approach.  We apply a strategy to distribute the defense load among gateways.  We aim at protecting TCP friendly traffic based on TCP semantics.

33. A big picture 21222324 13 1617 687 34 2 1 15 9 2526 1920 11 5 18 1210 Gateway k link node 14

34. Gateway architecture Traffic Sampling Checking Traffic Sampling Signaling Module Attack Detection Module Access Control Module The Friendly TCP Traffic List The Sampling Rules Filtering

35.  The basic idea: keep track the TCP friendly flows rather than the attack flows  How to identify the friendly traffic flows? TCP-ACK based attack detection TCP-ACK based attack detection

36. Gateway cooperation  Reducing duplication of processing the on-going traffic among gateways m the sampling rules  Selecting the proper portion of the on-going traffic to process  the distance-based traffic selection

37. Following up r Trace-back r Implementation r More RT service oriented

38. What we will do? r Providing secure real-time in peer-to-peer (p2p) networks m What are p2p networks? m What we did recently? Analyzing and enhancing the resilience of the current structured p2p systems to routing attacks r Providing secure real-time in sensor networks m Real-time in sensor networks m Denial of service

39. Final remarks r Providing RT service in a scalable fashion is hard, and providing secure RT service is even harder. r It is good to seriously consider security issues in RT before its mechanisms are fully deployed. r What else? m real-time security service: conduct security services in real-time

40. Distributed Real-Time Communication Lab r Members: Dong Xuan (faculty), Sriram Chellappan, Xun Wang (RA) and some other non-supported students r Research Interests: broadly in the areas of distributed systems and networking: o Scalable QoS guarantees: We seek to build up an architecture to provide scalable QoS (deterministic and statistical) guarantees to real-time applications such as voice and video o Network Security: We attempt to design and implement an advanced gateway-based defense system which can contain Distributed Denial of Services attacks. Also, we are interested in analyzing and improving the resilience of peer-to-peer systems to different types of attacks

41. Distributed Real-Time Communication Lab r Research Interests (cont.): o Application Layer Networking: We are working on a peer-to-peer system which can provide service differentiation to different queries. We are also investigating the ways to provide scalable multicast and anycast service at the application layer r Our Web Site: m www.cis.ohio-state.edu/~xuan

42. CIS 788x08: Spring 2003 – Dong Xuan Advanced Topics in Network Architecture, QoS & Security r Description: This course discusses some advanced topics in network architecture, Quality of Services, and security. Particularly, it covers: o Traffic monitoring, measurement and analysis o Peer-to-peer and Application-level networking o Deterministic and statistical QoS guarantees o Attack detection and prevention etc.