Survey
* Your assessment is very important for improving the workof artificial intelligence, which forms the content of this project
* Your assessment is very important for improving the workof artificial intelligence, which forms the content of this project
Wireless security wikipedia , lookup
Distributed operating system wikipedia , lookup
Airborne Networking wikipedia , lookup
Multiprotocol Label Switching wikipedia , lookup
Asynchronous Transfer Mode wikipedia , lookup
Recursive InterNetwork Architecture (RINA) wikipedia , lookup
Network tap wikipedia , lookup
Cracking of wireless networks wikipedia , lookup
Distributed firewall wikipedia , lookup
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 PathS k the max number of input links to a router d jPath 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: 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 Host 1 Host 2 Host 3 Host 4 0 3 A 2 3 0 3 B 3 3 0 0 0 2 3 3 0 3 3 3 2 0 Manipulation New Connection (H3 to H2) 5 MB/sec 0 3 2 3 0 0 3 2 Direct 3 3 0 3 3 0 3 0 2 1 0 0 1 0 0 1 0 0 0 0 3 0 3 3 3 3 0 3 3 3 3 0 Stable Traffic Pattern Matrix 0 0 0 0 + 1 0 0 0 Host-based Rerouting 2 0 0 0 0 0 0 0 Padding 0 0 . 0 0 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 uvE ij vuE ij (5) For node v i , where host i is the source of the traffic, f vu a vuE ij ij (6) For node v j , where host j is the destination of the traffic, f uv a uvE 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.