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
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-call signaling 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
• Efficient admission 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
Workflow
At Configuration Time

Network parameters, traffic
pattern (a the utilization bound, D
Deadline)
Verification of Safe Utilization
Delay Computation for Path Delay d
Yes
No
dltD
a is safe
a is not safe
Utilization bound verification
Utilization-based Admission Control
Packet Forwarding with Static Priority Scheduler
18
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
  users 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
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
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
16
17
15
19
20
18
14
13
6
8
7
9
11
12
10
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.