Securing Real-time Communication Services in Large Scale NetworksDong XuanDept. of Computer and Information ScienceOhio-state Universitywww.cis.ohio-state.edu/~xuan

OutlineMotivationBackgroundChallengesRelated workWhat we have doneWhat we will doFinal remarks

MotivationProviding secure and scalable QoS guarantees to real-time applications

Real-time (RT) Communication ServicesMultimedia applications: network audio and videoReal-Time

Mechanisms to support RT Two planesControl-PlaneCall 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 modelsIntegrated Service (IntServ)Differentiated Service (DiffServ)

Security threats and security servicesSecurity 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 networkA large number of nodes distributed in a large scopeDistributed and not centralizedAn open system and not secure

Challenge 1: Providing scalable RT service is not easy

Solutions demonstrated in the small may not work in the largeper-call signaling and management at per-element: too complex?do-able in small networksmodest backbone router sees 250K flows/min

Rate-based Priority-based Not Scalable Data Plane Not Scalable ScalableScalableControl Plane Upon a new request, the delay ofall existing flows need re-computing

Challenge 2: RT service itself is extremely vulnerableRT 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 vulnerableSignaling: RSVPRouting: MPLSScheduling: WFQ and SPMarking, shaping, and policingetc

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

Related workA 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 servicesNCSU and UC Davis

What we have done? Providing scalable RT servicesPreventing real-time traffic analysisDefending Distributed Denial of Service (DDoS) attack

Providing scalable RT serviceObjectiveProviding QoS guarantees to real-time applications in a scalable fashion

Our solutionUtilization-based Admission Control (UBAC) Static priority schedulerEfficient admission controlResource verification at configuration time

Our solutionUpon a new request, the delay ofall existing flows need re-computing Rate-based Priority-based Not Scalable Data Plane Not Scalable Not ScalableScalable UBAC approachControl Plane

WorkflowUtilization bound verification VerificationofSafe UtilizationDelay Computation for Path Delay d is safe is not safe YesNod

The delay formula 2 Priorities, Links with the same capacity, 2 classes traffic, ...Observation: it does not depend on dynamic status information!

Following upImplementation Voice over IPVideoExtended to soft and statistic guarantees, particularly in wireless networks, where BW keeps changing

Preventing RT traffic analysis

ObjectivesKeep RT communication anonymous and unobservableIt 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.

Our solution

Leverage our research results on RTUse traffic padding and rerouting approaches to camouflage the real traffic

Basic modelFeatures of IP-based networkHeader of the packet are readable by an observer.Stable mode

ExampleExisting Traffic Pattern MatrixThe existing traffic pattern among the hosts are:

Host1 Host2 Host3 Host4Host 1003MB/sec3MB/secHost 23MB/sec03MB/sec3MB/secHost 32MB/sec0MB/sec02MB/secHost 43MB/sec3MB/sec3MB/sec0The stable traffic pattern among the hosts are:

Host1 Host2 Host3 Host4Host 103MB/sec3MB/sec3MB/secHost 23MB/sec03MB/sec3MB/secHost 33MB/sec3MB/sec03MB/secHost 43MB/sec3MB/sec3MB/sec0

+

.

New Connection (H3 to H2) 5 MB/sec

Manipulation

Host-based Rerouting

Padding

Direct

_980196448.unknown

_1020796159.unknown

_980196234.unknown

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

Traffic planning Link Capacity ConstraintsStabilization Constraints

, (1)

Or

, (2)

,

is an element of the stable traffic matrix B, for

.

_979859060.unknown

_979859213.unknown

_979859309.unknown

_979859084.unknown

_979858907.unknown

(3)

(4)

These conditions make sure that no bandwidth capacities are exceeded.

_982414619.unknown

_982414651.unknown

Traffic planning (cont.) Conservation Constraints Delay Constraints

For each node

,

(5)

For node

, where host i is the source of the traffic,

(6)

For node

, where host j is the destination of the traffic,

(7)

_979859844.unknown

_979859966.unknown

_979859995.unknown

_979860019.unknown

_979859921.unknown

_979859699.unknown

(8)

for all the traffic flows in the real demand traffic matrix.

_977147908.unknown

Following upHow to extend to conduct traffic planning in a distributed fashion? Redefine stable mode

Gateway-based distributed denial of service (DDoS) defense systemObjectiveContain 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 picture2122232413131617687342115925261920115181210Gatewayklinknode14

Gateway architectureTraffic SamplingCheckingTraffic SamplingSignalingModuleAttack Detection ModuleAccess Control ModuleThe Friendly TCP Traffic ListThe Sampling RulesThe Sampling RulesFiltering

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

Reducing duplication of processing the on-going traffic among gatewaysthe sampling rules

Selecting the proper portion of the on-going traffic to process the distance-based traffic selection Gateway cooperation

Following upTrace-back ImplementationMore 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 attacksProviding secure real-time in sensor networksReal-time in sensor networksDenial 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 LabMembers: 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

Distributed Real-Time Communication LabResearch 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

CIS 788x08: Spring 2003 Dong XuanAdvanced Topics in Network Architecture, QoS & SecurityDescription: 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 networkingDeterministic and statistical QoS guarantees Attack detection and prevention etc.