CMPT 401 Summer 2007 Dr. Alexandra Fedorova Lecture II: Architectural Models.

Slides:



Advertisements
Similar presentations
1 Computer Networks: A Systems Approach, 5e Larry L. Peterson and Bruce S. Davie Chapter 8 Network Security Copyright © 2010, Elsevier Inc. All rights.
Advertisements

1 Computer Security Instructor: Dr. Bo Sun. 2 Course Objectives Understand basic issues, concepts, principles, and mechanisms in computer network security.
Information Security 1 Information Security: Security Tools Jeffy Mwakalinga.
1 Cryptography and Network Security Third Edition by William Stallings Lecturer: Dr. Saleem Al_Zoubi.
Client/Server Computing Model of computing in which very powerful personal computers (clients) are connected in a network with one or more server computers.
CMPT 431 Dr. Alexandra Fedorova Lecture II: Architectural Models.
© Chinese University, CSE Dept. Distributed Systems / Distributed Systems Topic 1: Characterization and Design Goals Dr. Michael R. Lyu Computer.
CMPT Dr. Alexandra Fedorova Distributed Systems.
Lesson 11-Virtual Private Networks. Overview Define Virtual Private Networks (VPNs). Deploy User VPNs. Deploy Site VPNs. Understand standard VPN techniques.
Edition 3, © Addison-Wesley 2001
OCT1 Principles From Chapter One of “Distributed Systems Concepts and Design”
Security Internet Management & Security 06 Learning outcomes At the end of this session, you should be able to: –Describe the reasons for having system.
EEC-681/781 Distributed Computing Systems Lecture 3 Wenbing Zhao Department of Electrical and Computer Engineering Cleveland State University
Securing TCP/IP Chapter 6. Introduction to Transmission Control Protocol/Internet Protocol (TCP/IP) TCP/IP comprises a suite of four protocols The protocols.
OCT Masters of Information Systems Management 1 Organizational Communications and Distributed Object Technologies Week 3: Models and Architectures.
System Models. Architectural model Structure of the system in terms of components Goals:  reliable, manageable, adaptable, cost-effective system design.
Lesson 9-Securing a Network. Overview Identifying threats to the network security. Planning a secure network.
OCT1 Principles From Chapter Two of “Distributed Systems Concepts and Design” Material on Lamport Clocks from “Distributed Systems Principles and Paradigms”
WXES2106 Network Technology Semester /2005 Chapter 8 Intermediate TCP CCNA2: Module 10.
.NET Mobile Application Development Introduction to Mobile and Distributed Applications.
.NET Mobile Application Development Remote Procedure Call.
Chapter 2 Architectural Models. Keywords Middleware Interface vs. implementation Client-server models OOP.
ISNE101 Dr. Ken Cosh Week 14. This Week  Challenges (still) facing Modern IS  Reliability  Security.
IS473 Distributed Systems
1 Chapter 9 E- Security. Main security risks 2 (a) Transaction or credit card details stolen in transit. (b) Customer’s credit card details stolen from.
1 System Models. 2 Outline Introduction Architectural models Fundamental models Guideline.
CH2 System models.
1 MSCS 237 Communication issues. 2 Colouris et al. (2001): Is a system in which hardware or software components located at networked computers communicate.
Exercises for Chapter 2: System models
Source: George Colouris, Jean Dollimore, Tim Kinderberg & Gordon Blair (2012). Distributed Systems: Concepts & Design (5 th Ed.). Essex: Addison-Wesley.
Architectures of distributed systems Fundamental Models
Introduction Architecture Models Fundamental Models Summary Chapter 2: System Model.
Types of Electronic Infection
Lecture 16 Page 1 Advanced Network Security Perimeter Defense in Networks: Virtual Private Networks Advanced Network Security Peter Reiher August, 2014.
DISTRIBUTED SYSTEMS Principles and Paradigms Second Edition ANDREW S. TANENBAUM MAARTEN VAN STEEN Chapter 1 Introduction.
Distributed System Models (Fundamental Model). Architectural Model Goal Reliability Manageability Adaptability Cost-effectiveness Service Layers Platform.
Chapter 2: System Models. Objectives To provide students with conceptual models to support their study of distributed systems. To motivate the study of.
Advanced Computer Networks Topic 2: Characterization of Distributed Systems.
Welcome to Introduction to Computer Security. Why Computer Security The past decade has seen an explosion in the concern for the security of information.
1 MSCS 237 Communication issues. 2 Colouris et al. (2001): Is a system in which hardware or software components located at networked computers communicate.
Architecture Models. Readings r Coulouris, Dollimore and Kindberg Distributed Systems: Concepts and Design Edn. 3 m Note: All figures from this book.
Hwajung Lee.  Interprocess Communication (IPC) is at the heart of distributed computing.  Processes and Threads  Process is the execution of a program.
Prepared By: Md Rezaul Huda Reza
Copyright © George Coulouris, Jean Dollimore, Tim Kindberg This material is made available for private study and for direct.
Chapter 2: System Models  Architectural Models  Fundamental Models.
© Chinese University, CSE Dept. Distributed Systems / Distributed Systems Topic 1: Characterization of Distributed & Mobile Systems Dr. Michael R.
Seminar on Service Oriented Architecture Distributed Systems Architectural Models From Coulouris, 5 th Ed. SOA Seminar Coulouris 5Ed.1.
Security Distributed Systems Lecture # 14. Why care about security? Authentication Use another person’s ID for sending Non-repudiation E-commerce.
Network Security Introduction
Distributed System Models
Exercises for Chapter 2: System models From Coulouris, Dollimore and Kindberg Distributed Systems: Concepts and Design Edition 4, © Pearson Education 2005.
Computer threats, Attacks and Assets upasana pandit T.E comp.
Lect 8 Tahani al jehain. Types of attack Remote code execution: occurs when an attacker exploits a software and runs a program that the user does not.
From Coulouris, Dollimore, Kindberg and Blair Distributed Systems: Concepts and Design Edition 5, © Addison-Wesley 2012 System Models by Dr. Sarmad Sadik.
Distributed Computing & Embedded Systems Chapter 4: Remote Method Invocation Dr. Umair Ali Khan.
Distributed Systems: Concepts and Design Jinghai Rao 13,9,2000.
1 SYSTEM MODEL. 2 Topics  Introduction  Architectural Models  Fundamental Models SYSTEM MODEL.
IST 201 Chapter 11 Lecture 2. Ports Used by TCP & UDP Keep track of different types of transmissions crossing the network simultaneously. Combination.
Distributed Systems System Models Dr. Almetwally Mostafa.
Chapter 2: System Model Introduction Architecture Models
Slides for Chapter 2: Architectural Models
SYSTEM MODEL From Chapter 2 of Distributed Systems Concepts and Design,4th Edition, By G. Coulouris, J. Dollimore and T. Kindberg Published by Addison.
Architectures of distributed systems Fundamental Models
Architectures of distributed systems Fundamental Models
ONLINE SECURE DATA SERVICE
Architectures of distributed systems
Architectures of distributed systems Fundamental Models
Chapter 2: System models
Presentation transcript:

CMPT 401 Summer 2007 Dr. Alexandra Fedorova Lecture II: Architectural Models

2 CMPT 401 Summer 2007 © A. Fedorova Introductions Architectural model is an abstract view of a distributed system Models are constructed to simplify reasoning about the system A model of a DS is expressed in terms of –Components –Placement of components –Interactions among components

3 CMPT 401 Summer 2007 © A. Fedorova Component of a Distributed System Component of a distributed system is a process A process is running program Examples: –Server process – a program executing server code –Client process – a program executing client code Processes interact by sending each other messages

4 CMPT 401 Summer 2007 © A. Fedorova Outline System Architecture Models –Client-Server –Peer-to-Peer –Variations Interaction Models Failure Models Security Models

5 CMPT 401 Summer 2007 © A. Fedorova Client-Server Architecture I ©Pearson Education 2001

6 CMPT 401 Summer 2007 © A. Fedorova Client-Server Architecture II Clients send requests to servers (i.e., invocation) Servers send responses to clients (i.e., result) Servers may be clients of other servers –A web server is often a client of a file server –An Internet service is a client of a DNS server – a server that translates DNS names to IP addresses Potential problem: a single server is a scalability bottleneck and a single point of failure

7 CMPT 401 Summer 2007 © A. Fedorova Peer-to-Peer Architecture I ©Pearson Education 2001

8 CMPT 401 Summer 2007 © A. Fedorova Peer-to-Peer Architecture II All processes play similar roles – i.e., they interact as peers No central component – potentially better scalability and resiliency to failures Use the power of modern desktops to implement a large-scale distributed system Examples: Napster, Kazaa, Skype, Bittorrent

9 CMPT 401 Summer 2007 © A. Fedorova Architectural Variations Services provided by multiple servers Proxy servers and caches Mobile code Mobile agents Network computers Thin clients Mobile devices

10 CMPT 401 Summer 2007 © A. Fedorova Services by multiple servers Multiple servers provide services to clients Servers may partition the service objects or replicate them WWW: partitioned objects Sun NIS: replica of a password file maintained at each server Computing clusters ©Pearson Education 2001

11 CMPT 401 Summer 2007 © A. Fedorova Proxy Servers and Caches A cache is a store of recently used data objects that is closer than the main store A newly accessed object is added to the cache When that object is accessed again, it is fetched from the cache, if there is an up-to-date copy in the cache Proxy servers intercept communication with the real server to provide faster service (e.g., deliver cached data), better security (e.g., a proxy configured as a firewall) ©Pearson Education 2001

12 CMPT 401 Summer 2007 © A. Fedorova Mobile Code Code that is downloaded from a remote machine (e.g., a server) and is run in a local machine (e.g., a client) Example: Java applet Reason: provide better interactive experience ©Pearson Education 2001

13 CMPT 401 Summer 2007 © A. Fedorova Mobile Agents A running program (both code and data) that travels from one computer to another Example: a worm –Used to attack computer systems –Used for system administration –The original work at Xerox PARC: to make use of idle computers for a resource-intensive computation

14 CMPT 401 Summer 2007 © A. Fedorova Network Computers Does not rely (or relies minimally) on locally installed software Downloads operating system and applications from a remote computer Applications are run locally, but files are managed on a remote server Users can migrate from one network computer to another

15 CMPT 401 Summer 2007 © A. Fedorova Thin Clients Similar to a network computer Instead of downloading code to the user computer, it runs it on a compute server Software layer provides a window-based interface to the client (X Windows)

16 CMPT 401 Summer 2007 © A. Fedorova Mobile Devices Cellular phones PDAs Laptops Wearable devices Mobile sensors

17 CMPT 401 Summer 2007 © A. Fedorova Architecture Models: Summary Classified according to roles of components: –Client-server –Peer-to-peer Variations according to modes of interactions –Services provided by multiple servers –Proxy servers and caches –Mobile code –Mobile agents –Network computers –Thin clients –Mobile devices

18 CMPT 401 Summer 2007 © A. Fedorova Outline System Architecture Models Interaction Models Failure Models Security Models

19 CMPT 401 Summer 2007 © A. Fedorova Interaction Models Represent communication and coordination among the processes Must account for: –Performance of communication channels (communication delays determine how well the system works) –Differing notions of time across system components We will look at the following interaction models –Synchronous –Asynchronous

20 CMPT 401 Summer 2007 © A. Fedorova Communication Delays Message transmission delay is comprised of: –Network latency: the time for a bit of information to travel from source network interface to destination network interface –Delay in accessing network: i.e., how long it takes for the network to become available –Operating system delays: the time taken by operating system services at both ends of communication channel

21 CMPT 401 Summer 2007 © A. Fedorova Clocks and Timing Events Each computer has its own clock Reading of a local clock will differ from the real clock, because a clock drifts Clock drift rates differ from one another

22 CMPT 401 Summer 2007 © A. Fedorova Synchronous Interaction Model In a synchronous distributed system there are known bounds on: –Time to execute a step of a process –Message transmission time –Clock drift rate (i.e., the difference between local clock and the real clock) To guarantee bounds, one would need to: –Know resource requirements of each process –Guarantee those resources to the process (including network capacity) –Guarantee bounds on clock drift –Eliminate the possibility of certain failures Synchronous distributed systems are rare, because it is difficult to guarantee such bounds Synchronous system models are relatively easy to reason about

23 CMPT 401 Summer 2007 © A. Fedorova Asynchronous Interaction Model No bounds on delays determining the length of interaction –No bounds on process execution time –No bounds on message transmission delays –No bounds on clock drift rates The Internet is an asynchronous system Despite this uncertainty, many distributed systems are useful

24 CMPT 401 Summer 2007 © A. Fedorova Outline System Architecture Models Interaction Models Failure Models Security Models

25 CMPT 401 Summer 2007 © A. Fedorova Failure Models Types of failures –Omission failures –Byzantine failures –Timing failures Masking failures

26 CMPT 401 Summer 2007 © A. Fedorova Omission Failures An omission failure occurs when a process stops sending/receiving messages. Types of omission failures –Process omission failures: the process has crashed –Communication omission failures: message has not been delivered

27 CMPT 401 Summer 2007 © A. Fedorova Process Omission Failures A process crash is called a fail-stop failure In a synchronous system a fail-stop failure is determined via timeouts In an asynchronous system it is impossible to detect reliably that the process has crashed If the process is not responding it could have crashed or it could be just running slowly

28 CMPT 401 Summer 2007 © A. Fedorova Structure of a Communication Channel ©Pearson Education 2001

29 CMPT 401 Summer 2007 © A. Fedorova Communication Omission Failure Messages can be lost at the sender, at the receiver and in the network: –Receive omission: message is lost on the receiving side –Send omission: message is lost while sending –Channel omission: message is lost between sender and receiver A common cause for message loss: –Message buffer overflow due to system being busy –Systems drop messages deliberately when their buffers fill up –Clever algorithms to decide when to drop messages

30 CMPT 401 Summer 2007 © A. Fedorova Failure Models Types of failures –Omission failures –Byzantine failures –Timing failures Masking failures

31 CMPT 401 Summer 2007 © A. Fedorova Byzantine Failures Arbitrary failures –A process arbitrarily skips processing steps –A process takes unintended processing steps –Corrupted message contents Arbitrary failures can be caused by: –Malicious behaviour (attack) –Software bugs A byzantine failure cannot be reliably detected

32 CMPT 401 Summer 2007 © A. Fedorova Timing Failures Apply to synchronous systems Relevant for multimedia applications Clock failure: a process’s local clock exceeds the bounds on the drift rate from real time Performance failure: –Process exceeds the bounds on the interval between two steps –A message transmission takes longer than the stated bound

33 CMPT 401 Summer 2007 © A. Fedorova Impossibility of Agreement Theorem: In an asynchronous distributed system it is impossible to reach an agreement in the presence of failures.

34 CMPT 401 Summer 2007 © A. Fedorova Impossibility of Agreement: Proof 1.Suppose agreement is achieved via a sequence of messages 2.Suppose agreement could be reached in spite of message loss 3.Then it must be possible to eliminate the last message in the sequence and still reach the agreement 4.Now you have one fewer messages in a sequence 5.If you keep applying the above argument, you will end up with the sequence of zero messages 6.This is a contradiction: there must be at least one message in the sequence

35 CMPT 401 Summer 2007 © A. Fedorova Masking Failures Conversion from one type of failure to another –When a corrupted message is detected, the process acts as if the message has been lost –Byzantine  Omission Handling omission failures via retransmission Handling fail-stop failures via –Replication –Restarting the process, restoring its memory state

36 CMPT 401 Summer 2007 © A. Fedorova Outline System Architecture Models Interaction Models Failure Models Security Models

37 CMPT 401 Summer 2007 © A. Fedorova Security Models Adversary: a process that sends messages that would not be sent by a legitimate process –The goal is to violate integrity or secrecy of data or to disrupt normal functioning of the system Types of security threats: –Threats to processes –Threats to communication channels –Denial of service (DoS) attacks

38 CMPT 401 Summer 2007 © A. Fedorova Threats to Processes Forged identity –The client adversary masquerades as a legitimate user and obtains secret information from the server –The server adversary masquerades as a legitimate server and sends a wrong response to the client Taking over the system (i.e., a hacked system) –An adversary exploits system vulnerability –Sends a packet that causes the server to execute the program belonging to the adversary (viruses or buffer overflow attacks) –The adversary causes the byzantine failure

39 CMPT 401 Summer 2007 © A. Fedorova Threats to Communication Channels Interception of messages: –Watch messages sent over the network, read their contents: violation of privacy and secrecy (i.e., someone reads my ) Injection of messages: –Save a copy of a legitimate message and later “replay” it on the network –E.g., send a message asking to charge the credit card multiple times

40 CMPT 401 Summer 2007 © A. Fedorova Denial of Service Attacks Flood the system with pointless messages to prevent normal operation of the system Causes the system to run very slowly Many systems are not designed to handle performance spikes: CNN server became unresponsive on 9/11

41 CMPT 401 Summer 2007 © A. Fedorova Dealing with Security Failures Encryption –Scramble the message so as to hide its content, i.e., encrypt –Message can be decrypted using a key. A key is usually a large number that is difficult to guess. Authentication –Encrypt a part of the message; in the encrypted part provide enough information to guarantee authenticity –Enabled by use of shared secrets and encryption Secure channels –Built on top of regular channels using encryption –Communicating processes reliably know each others’ identity –Transmitted cannot be tampered with –Each message includes a physical or logical timestamp to prevent reordering or replay –Examples: Virtual Private Network (VPN), Secure Sockets Layer (SSL)

42 CMPT 401 Summer 2007 © A. Fedorova Summary I System architecture models –Client/server –Peer-to-peer –Variations: mobile devices, network computer, thin client etc. Interaction models –Synchronous system: known bounds on clock drifts and message delays –Asynchronous system: no such bounds

43 CMPT 401 Summer 2007 © A. Fedorova Summary II Failure Model –Omission failures Process omission: fail-stop – cannot be reliably detected in an asynchronous system Communication omission: Send/receive omission, channel omission –Byzantine failures Bugs Message corruption Hardest to deal with –Timing failures Apply to synchronous systems In an asynchronous system agreement cannot be reached in presence of failures

44 CMPT 401 Summer 2007 © A. Fedorova Summary III Threat model –Adversary –Threats to processes (spoofing identity, hacking the system) –Threats to communication channels (intercepting messages, replaying messages) –Denial of service attacks: prevent proper functioning of the system by sending useless messages Security threads addressed via encryption, authentication and secure channels