Transcript document

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
Outline
 Motivation
 Background
 Challenges
 Related work
 What we have done
 What we will do
 Final remarks
Motivation
 Providing secure and scalable QoS guarantees to
real-time applications
Real-time (RT) Communication Services
Multimedia applications:
network audio and video
Real-Time
network provides applications
with delay guarantees
 soft guarantees
 Hard guarantees
oStatistic
oDeterministic
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 ratebased schedulers, e.g. WFQ and priority-based schedulers,
e.g. Static Priority)
 Two models
 Integrated Service (IntServ)
 Differentiated Service (DiffServ)
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.
The large scale network
 A large number of nodes distributed in a large
scope
 Distributed and not centralized
 An open system and not secure
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
Control Plane
Data Plane
Rate-based
Priority-based
Scalable
Not Scalable
Not Scalable
Scalable
Upon a new request, the delay of
all existing flows need re-computing
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.
Challenge 3: RT supporting mechanisms are
vulnerable
 Signaling: RSVP
 Routing: MPLS
 Scheduling: WFQ and SP
 Marking, shaping, and policing
 etc
Challenge 4: Securing RT is expensive
 Security will introduce extra-delay. The delay
should be very small.
 More resources are needed.
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-realtime service.
 Very few work on this topic:

protecting Network QoS under denial of services
• NCSU and UC Davis
What we have done?
 Providing scalable RT services
 Preventing real-time traffic analysis
 Defending Distributed Denial of Service (DDoS)
attack
Providing scalable RT service
 Objective
 Providing QoS guarantees to real-time applications in a
scalable fashion
Our solution
 Utilization-based Admission Control (UBAC)
 Static priority scheduler
 Efficient admission control
 Resource verification at configuration time
Our solution
Rate-based
Priority-based
Control Plane
Not Scalable
Not Scalable
Data Plane
Not Scalable
Scalable
Upon a new request, the delay of
all existing flows need re-computing
UBAC approach
Workflow
At Run Time
At Configuration Time
Network parameters, traffic pattern
(α: the utilization bound, D = Deadline)
Verification Delay Computation
of
for Path Delay d
Safe Utilization
No
α is not safe
d<D
Yes
α is safe
Admission request
(D = Deadline, Resource Requirements)
Admission
U := U + Unew
Control
Procedure
yes
U < α?
admitted
Utilization bound Utilization-based
verification
Admission Control
Packet Forwarding with
Static Priority Scheduler
no
rejected
The delay formula

2 Priorities, Links with the same capacity, 2 classes traffic, …...
dk
L 1


 (  Yk )
L 

Yk  max
the worst case delay
of link server k
PathS k
the max number of
input links to a router
d
jPath
input traffic under
min{C*I,  +ρ*I}
the ratio of link capacity
to higher priority traffic
Observation: it does not depend on dynamic status information!
j
Following up
 Implementation
 Voice over IP
 Video
 Extended to soft and statistic guarantees,
particularly in wireless networks, where BW keeps
changing
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 online/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.
Our solution
 Leverage our research results on RT
 Use traffic padding and rerouting approaches to
camouflage the real traffic
Basic model

Features of IP-based network


Header of the packet are readable by an observer.
Stable mode
Host 1
Host 3
Router A
Router C
Router B
Router D
Host 4
Host 2
Fig. 1 Network Topology
Host 1
Host 3
Host 2
Host 4
Fig. 2 Fully Connected Directed Graph
Example
 0 0 3 3


3
0
3
3


A
2 0 0 2


 3 3 3 0


Existing Traffic Pattern Matrix
The existing traffic pattern among the hosts are:
Host1
Host 1
Host 2
Host 3
Host 4
0
3MB/sec
2MB/sec
3MB/sec
Host2
0
0
0MB/sec
3MB/sec
Host3
Host4
3MB/sec
3MB/sec
3MB/sec
3MB/sec
0
2MB/sec
3MB/sec
0
The stable traffic pattern among the hosts are:
Host 1
Host 2
Host 3
Host 4
0

3
A
2

3

Host1
Host2
Host3
Host4
0
3MB/sec
3MB/sec
3MB/sec
3MB/sec
0
3MB/sec
3MB/sec
3MB/sec
3MB/sec
0
3MB/sec
3MB/sec
3MB/sec
3MB/sec
0
0 3 3

0 3 3
0 0 2

2 3 0 
Manipulation
New Connection (H3 to H2) 5 MB/sec
0

3
2

3

0 3 3  0
 
0 3 3  0

3 0 2  1
 
2 3 0   0
Direct
1 0 0  0
 
0 0 0  0
+
0 0 1  0
 
1 0 0   0
Host-based Rerouting
0

3
B
3

3

3 3 3

0 3 3
3 0 3

3 3 0 
Stable Traffic Pattern Matrix
2 0 0

0 0 0
.
0 0 0

0 0 0 
Padding
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)
?
Traffic rerouting

Indirect delivery of packets

Challenge: How to reroute the traffic?
Real Traffic: 5MB/sec from H3 to H2
H1
H4
1MB/sec
H2
1MB/sec
3MB/sec
H3
Traffic planning
Stabilization
 f ij   c
uv
1 u,v  n
 f ij   b
Or
uv
1 u,v  n
ij
ij
Constraints
 bij ,
(1)
,
(2)
where 0  cij  bij , ,0  f uv ij   bij , bij is an element of the stable traffic matrix B, for
1  i, j  n .

Link Capacity Constraints
n
b
j 1
ij
n
b
i 1
ij
 the capacity of the output link from host i.
(3)
 the capacity of the input link into host j.
(4)
These conditions make sure that no bandwidth capacities are exceeded.
Traffic planning (cont.)

Conservation Constraints
For each node v  i, j,
 f uv    f vu  0
uvE
ij
vuE
ij
(5)
For node v  i , where host i is the source of the traffic,
 f vu  a
vuE
ij
ij
(6)
For node v  j , where host j is the destination of the traffic,
 f uv   a
uvE

ij
ij
(7)
Delay Constraints
d ijW C  DLij
for all the traffic flows in the real demand traffic matrix.
(8)
Following up
 How to extend to conduct traffic planning in a
distributed fashion?
 Redefine stable mode
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.
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

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.
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.
A big picture
21
22
13
13
6
23
15
14
7
24
16
17
8
9
3
k
node
4
2
link
Gateway
1
25
18
19
10
20
11
5
26
12
Gateway architecture
Access Control Module
Traffic Sampling
The Sampling Rules
Signaling
Module
Filtering
The Friendly TCP Traffic List
Attack Detection Module
Checking
Traffic Sampling
The Sampling Rules
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
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
Following up
 Trace-back
 Implementation
 More RT service oriented
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
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
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:
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
Distributed Real-Time Communication
Lab
 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
 Our Web Site:

www.cis.ohio-state.edu/~xuan
CIS 788x08: Spring 2003 – Dong Xuan
Advanced Topics in Network Architecture, QoS
& Security
 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.