Securing Real-time Communication Services in Large Scale Networks

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 • Motivation • Background • Challenges • Related work • What we have done • What we will do • Final remarks

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

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

5. Mechanisms to support RT • Two planes • 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. • Data-Plane: • Packet forwarding (controlled by schedulers, such as rate-based schedulers, e.g. WFQ and priority-based schedulers, e.g. Static Priority) • Two models • Integrated Service (IntServ) • Differentiated Service (DiffServ)

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

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

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

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

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

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

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

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

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

15. Our solution • Utilization-based Admission Control (UBAC) • Static priority scheduler • Efficientadmission control • Resource verification at configuration time

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

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

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

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

20. Preventing RT traffic analysis • Objectives • 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 • 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 • Header of the packet are readable by an observer. • Stable mode

23. Stable Traffic Pattern Matrix Example The existing traffic pattern among the hosts are: Host1 Host2 Host3 Host4 Host 1 0 0 3MB/sec 3MB/sec Host 2 3MB/sec 0 3MB/sec 3MB/sec Host 3 2MB/sec 0MB/sec 0 2MB/sec Host 4 3MB/sec 3MB/sec 3MB/sec 0 Existing Traffic Pattern Matrix The stable traffic pattern among the hosts are: Host1 Host2 Host3 Host4 Host 1 0 3MB/sec 3MB/sec 3MB/sec Host 2 3MB/sec 0 3MB/sec 3MB/sec Host 3 3MB/sec 3MB/sec 0 3MB/sec Host 4 3MB/sec 3MB/sec 3MB/sec 0

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, Si Fi,j( I ) + Sj( I ) = C(I)

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

26. Traffic planning Stabilization Constraints Link Capacity Constraints

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

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

29. Gateway-based distributed denial of service (DDoS) defense system • Objective • 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 21 22 23 24 25 26 13 15 16 17 18 19 20 14 13 6 7 8 9 10 11 12 3 4 5 2 k node link Gateway 1

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

35. TCP-ACK based attack detection • 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

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

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

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

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

40. Distributed Real-Time Communication Lab • Members: Dong Xuan (faculty), Sriram Chellappan, Xun Wang (RA) and some other non-supported students • Research Interests: broadly in the areas of distributed systems and networking: • 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 • 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 • Research Interests (cont.): • 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 • Our Web Site: • www.cis.ohio-state.edu/~xuan

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