GoConqr hat ein neues Design! Sag uns, wie es dir gefällt.

Kostenlos registrieren

Karteikarten

Chapter 9-10

Julian Rottenberg Deutsch 200 Karten

Chapter 9-10

Karten in diesem Stapel (200)

  1. 11. Process Model (Disadvantage)- Slow (fork is expensive, context switching overhead)
    - Difficult to perform optimizations that rely on global information (e.g. cache URLs)
  2. 21. Process Model (Bild)1. Process Model (Bild)
  3. 32. Thread Model (Use threads instead of processes) (Motivation)- Thread creation and destruction cheaper
    - Sharing data between threads easier than between processes, but synchronization required for shared data
  4. 42. Thread Model (Use threads instead of processes) (Problem)- OS support required (otherwise one blocked thread blocks whole address space)
    => Examples: JAWS, IIS, Apache (Windows)
  5. 52. Thread Model (Advantages)- Faster than processes
    - Sharing enabled by default
  6. 62. Thread Model (Disadvantages)- Requires OS support
    - Can exhaust per-process limits (e.g. max. number of open file descriptors)
    - Limited control over scheduling decisions
  7. 73. In-kernel Model3. In-kernel Model
  8. 83. In-kernel Model (One option)- whole server in the kernel
  9. 93. In-kernel Model (Most often)- Only static files served from kernel, other requests go to regular user-space server (khttpd, AFPA)
    - Dedicated kernel thread of HTTP requests
  10. 103. In-kernel Model (Advantages)- Avoids copies to/from user space
    - Very fast, if tightly integrated with kernel (khttpd is not)
  11. 113. In-kernel Model (Disadvantages)- Bugs can crash whole machine
    - Harder to debug and extend
    - Inherently OS-specific
  12. 123. In-kernel Model (Examples)3. In-kernel Model (Examples)
  13. 134. Event-driven Model (1)4. Event-driven Model (1)
  14. 144. Event-driven Model (2)4. Event-driven Model (2)
  15. 154. Event-driven Model (Advantages)- Very fast, no context switches
    - Sharing inherent (only one process), no locks needed
    - Complete control over scheduling decisions
    - No complex OS support needed
  16. 164. Event-driven Model (Disadvantages)- Per-process resource limits
    - Not every OS has full asynchronous I/O, so can still block on read. Flash uses helper processes to avoid this.
  17. 17Performance ComparisonPerformance Comparison
  18. 18Web Server Cluster (Two ways of increasing capacity)- Single larger machine
    - Cluster of cheap standard machines, e.g. PCs
  19. 19Web Server Clusters (Latter approach currently dominating)- Scalability
    - High availability
    - Cost
  20. 20Web Server Clusters (Typical architecture)Web Server Clusters (Typical architecture)
  21. 21Web Server ClustersWeb Server Clusters
  22. 22FTP: The File Transfer ProtocolFTP: The File Transfer Protocol
  23. 23FTP: Separate Control & Data ConnectionsFTP: Separate Control & Data Connections
  24. 24FTP Commands, Responses (Sample commands)FTP Commands, Responses (Sample commands)
  25. 25FTP Commands, Responses (Sample return codes)FTP Commands, Responses (Sample return codes)
  26. 26Electronic Mail (Three major components)- User agents
    - Mail servers
    - Simple mail transfer protocol: SMTP
  27. 27Electronic Mail (User Agent)- A.k.a. "mail reader"
    - Composing, editing, reading mail messages
    - E.g., Outlook, Mozilla Thunderbird, mail client on mobile phone etc.
    - Outgoing, incoming messages stores on server
  28. 28Electronic Mail (Bild)Electronic Mail (Bild)
  29. 29Electronic Mail: Mail Servers (Mailservers) (Mailbox)- Mailbox contains incoming messages for user
  30. 30Electronic Mail: Mail Servers (Mailservers) (Message queue)- Message queue of outgoing (to be sent) mail messages
  31. 31Electronic Mail: Mail Servers (Mailservers) (SMTP protocol)- SMTP protocol between mail servers to send email messages
    -> Client: sending mail server
    -> "server": receiving mail server
  32. 32Electronic Mail: Mail Servers (Bild)Electronic Mail: Mail Servers (Bild)
  33. 33Electronic Mail: SMTP [RFC 2821]Electronic Mail: SMTP [RFC 2821]
  34. 34Scenario: Alice Sends Message to BobScenario: Alice Sends Message to Bob
  35. 35Sample SMTP interactionSample SMTP interaction
  36. 36Try SMTP Interaction for YourselfTry SMTP Interaction for Yourself
  37. 37SMTP: Final WordsSMTP: Final Words
  38. 38Mail Message FormatMail Message Format
  39. 39Message Format: Multimedia ExtensionsMessage Format: Multimedia Extensions
  40. 40Mail Access Protocols (SMTP)- Delivery/storage to receiver's server
  41. 41Mail Access Protocols (Mail access protocol)- Retrieval from server
    -> POP: Post Office Protocol [RFC 1939]
    --> Authorization (agent <--> server) and download
    -> IMAP: Internet Mail Access Protocol [RFC 1730]
    --> More features (more complex)
    --> Manipulation of stored msgs on server
    -> HTTP: Hotmail, Yahoo! Mail, etc.
  42. 42Mail Access Protocol (Bild)Mail Access Protocol (Bild)
  43. 43POP3 ProtocolPOP3 Protocol
  44. 44POP3 and IMAP (More about POP3)- Previous example uses "download and deletes" mode
    - Bob cannot re-read e-mail if he changes client
    - "Download-and-keep": enables copies of messages on different clients (requires to organize on each client)
    - POP3 is stateless across sessions
  45. 45POP3 and IMAP (IMAP- Keep all messages in one place: the server
    - Allows user to organize messages in folders
    - IMAP keeps user state across sessions:
    -> names of folders and mapping between message IDs and folder name
  46. 46DNS: Domain Name System (People)- many identifiers:
    -> SSN, name, passport #
  47. 47DNS: Domain Name System (Internet hosts, routers)- IP address (32 bit) - used for addressing datagrams
    - "Name", e.g., www.yahoo.com - used by humans
  48. 48DNS: Domain Name System (Domain Name System) (Distributed database)- implemented in hierarchy of many name servers
  49. 49DNS: Domain Name System (Domain Name System) (Application-layer protocol)- Application-layer protocol for hosts, routers, name server to communicate to resolve names (address/name translation)
    -> Note: core Internet function, implemented as application-layer protocol
    -> Complexity at network's "edge"
  50. 50DNS (DNS services)- Hostname to IP address translation
    - Host aliasing
    -> Canonical and alias names
    - Mail server aliasing
    - Load distribution
    -> Replicated Web servers: set of IP addresses for one canonical name
  51. 51DNS (Why not centralize DNS?)- Single point failure
    - Traffic volume
    - Distant centralized database
    - One central authority for worldwide name resolution undesirable ("who owns the Internet?")
    - Maintenance
    => does not scale!
  52. 52Distributed, Hierarchical DatabaseDistributed, Hierarchical Database
  53. 53DNS: Root Name Servers- Contacted by local name server that cannot resolve nameDNS: Root Name Servers
  54. 54DNS: Root Name Servers (Root name server)- Contacts authoritative name server if name mapping not known
    - Gets mapping
    - Returns mapping to local name server
  55. 55TLD, Authoritative and Local DNS Servers (Top-level domain (TLD) servers)- responsible for com, org, net, edu, etc, and all top-level country domains uk, fr, ca, jp
    - Network solutions maintain servers for com TLD
    - Educause for edu TLD
  56. 56TLD, Authoritative and Local DNS Server (Authoritative DNS servers)- organization's DNS servers, providing authoritative hostname to IP mappings for organization's servers (e.g., Web and mail)
    - Can be maintained by organization or server provider
  57. 57TLD, Authoritative and Local DNS Server (Local DNS servers)- Does not strictly belong to hierarchy
    - Each ISP (residential ISP, company, university) has one
    -> Also called "default name server"
    - When a host makes a DNS query, query is sent to its local DNS server
    -> Acts as a proxy, forwards query into hierarchy
  58. 58Iterative Queries: Example (Bild)Iterative Queries: Example (Bild)
  59. 59Iterative Queries: Example (Iterated query)- Contacted server replies with name of server to contact
    - "I don't know this name, but ask this server"
  60. 60Recursive Queries: Example (Bild)Recursive Queries: Example (Bild)
  61. 61Recursive Queries: Example (Recursive query)- Puts burden of name resolution on contacted name server
    - Heavy load?
    => Not done by root or TLD name servers
  62. 62DNS: Caching and Updating RecordsDNS: Caching and Updating Records
  63. 63DNS RecordsDNS Records
  64. 64DNS Protocol, Messages (DNS protocol)- query and reply messages, both with same message format
  65. 65DNS Protocol, Messages (Bild - 1)DNS Protocol, Messages (Bild - 1)
  66. 66DNS Protocol, Messages (Bild - 2)DNS Protocol, Messages (Bild - 2)
  67. 67Inserting Records Into DNSInserting Records Into DNS
  68. 68P2P File SharingP2P File Sharing
  69. 69P2P: Centralized Directory- Original "Napster" design
    -> 1) When peer connects, it informs central server:
    --> IP address
    --> Content
    -> 2) Alice queries for "Hey Jude"
    -> 3) Alice requests file from Bob
  70. 70P2P: Centralized Directory (Bild)P2P: Centralized Directory (Bild)
  71. 71P2P: Problems With Centralized Directory- Single point of failure
    - Performance bottleneck
    - Copyright infringement
    => File transfer is decentralized, but locating content is highly centralized
  72. 72Query Flooding: Gnutella (General Properties)- Full distributed
    -> No central server
    - Public domain protocol
    - Many Gnutella clients implementing protocol
  73. 73Query Flooding: Gnutella (Overlay network: graph)- Edge between peer X and Y if there's a TCP connection
    - All active peers and edges in overlay net
    - Edge is not a physical link
    - Given peer will typically be connected with < 10 overlay neighbours
  74. 74Gnutella: ProtocolGnutella: Protocol
  75. 75Gnutella: Peer JoingfGnutella: Peer Joing
  76. 76Socket Programming (Goal)- Learn how to build client/server application that communicates using sockets
  77. 77Socket Programming (Socket API)- Introduced in BSD4.1 UNIX, 1981
    - Sockets are explicitly created, used, released by applications
    - Client/Server paradigm
    - Two types of transport service via socket API:
    -> Unreliable datagram
    -> Reliable, byte stream-oriented
  78. 78Socket Programming (Socket)- A host-local, application-created, OS-controlled interface (a "door") into which application process can both send and receive messages to/from another application process
  79. 79Socket-Programming Using TCP (Socket)- a door between application process and end-end-transport protocol (UCP or TCP)
  80. 80Socket-Programming Using TCP (TCP service)- reliable transfer of bytes from one process to another
  81. 81Socket-Programming Using TCP (Bild)Socket-Programming Using TCP (Bild)
  82. 82Socket Programming With TCP (Client must contact server)- Server process must first be running
    - Server must have created socket (door) that welcomes client's contact
  83. 83Socket Programming With TCP (Client contacts server by)- Creating client-local TCP socket
    - Specifying IP address, port number of server process
    - When client creates socket:
    -> Client TCP establishes connection to server TCP
  84. 84Socket Programming With TCP- When contacted by client, server TCP creates new socket for server process to communicate with client
    -> Allows server to talk with multiple clients
    -> Source port numbers used to distinguish clients
  85. 85Socket Programming With TCP (application viewpoint)- TCP provides reliable, in-order transfer of bytes ("pipe") between client and server
  86. 86Stream Jargon (Stream)- A stream is a sequence of characters that flow into or out of a process
  87. 87Stream Jargon (Input Stream)- An input stream is attached to some input source for the process, e.g., keyboard or socket
  88. 88Stream Jargon (Output Stream)- An output stream is attached to an output source, e.g., monitor or socket
  89. 89Socket Programming With TCP (Example Client-Server application)- 1) Client reads line from standard input (inFromUser stream), sends to server via socket (outToServer stream)
    - 2) Server reads line from socket
    - 3) Server converts line to uppercase, sends back to client
    - 4) Client reads, prints modified line from socket (inFromServer stream)
  90. 90Socket Programming With TCP (Bild)Socket Programming With TCP (Bild)
  91. 91Client/Server Socket Interaction: TCPClient/Server Socket Interaction: TCP
  92. 92Example: Java Client (TCP) (1)Example: Java Client (TCP) (1)
  93. 93Example: Java Client (TCP) (2)Example: Java Client (TCP) (2)
  94. 94Example: Java Server (TCP) (1)Example: Java Server (TCP) (1)
  95. 95Example: Java Server (TCP) (2)Example: Java Server (TCP) (2)
  96. 96Socket Programming With UDP- UDP: No "connection" between client and server
    - No handshaking
    - Sender explicitly attaches IP address and port of destination to each packet
    - Server must extract IP address, port of sender from received packet
    - UDP: Transmitted data may be received out of order, or lost
  97. 97Socket Programming With UDP (Application viewpoint)- UDP provides unreliable transfer of groups of bytes ("datagrams") between client and server
  98. 98Client/Server Socket Interaction: UDPClient/Server Socket Interaction: UDP
  99. 99Example: Java Client (UDP)Example: Java Client (UDP)
  100. 100Example: Java Client (UDP)Example: Java Client (UDP)
  101. 101Example: Java Client (UDP)Example: Java Client (UDP)
  102. 102Example: Java Sender (UDP) (1)Example: Java Sender (UDP) (1)
  103. 103Example: Java Server (UDP) (2)Example: Java Server (UDP) (2)
  104. 104Building a Simple Web ServerBuilding a Simple Web Server
  105. 105Chapter 1: Summary (1)Chapter 1: Summary (1)
  106. 106Chapter 1: Summary (2)Chapter 1: Summary (2)
  107. 107Appendix: Socket Programming with CAppendix: Socket Programming with C
  108. 108Example: C Client (TCP) (1)Example: C Client (TCP) (1)
  109. 109Example: C Client (TCP) (2)Example: C Client (TCP) (2)
  110. 110Example: C Client (TCP) (1)Example: C Client (TCP) (1)
  111. 111Example: C Server (TCP) (2)Example: C Server (TCP) (2)
  112. 112Example: C Client (UDP) (1)Example: C Client (UDP) (1)
  113. 113Example: C Client (UDP) (2)Example: C Client (UDP) (2)
  114. 114Example: C Server (UDP) (1)Example: C Server (UDP) (1)
  115. 115Example: C Server (UDP) (2)Example: C Server (UDP) (2)
  116. 116What is a Threat in a Communication Network (Abstract Definition)- A threat in a communication network is any possible event or sequence of actions that might lead to a violation of one or more security goal
    - The actual realization of a threat is called an attack
  117. 117What is a Threat in a Communication Network? (Examples)- A hacker breaking into a corporate computer
    - Disclosure of emails in transit
    - Someone changing financial accounting data
    - A hacker temporarily shutting down a website
    - Someone using services or ordering goods in the name of others
  118. 118What is a Threat in a Communication Network? (What are security goals)- Security goals can be defined:
    -> Depending on the on the application environment, or
    -> in a more general, technical way
  119. 119Security goals depending on the application environment 1 (Banking)- Protect against fraudulent or accidental modification of transactions
    - Identify retail transaction customers
    - Protect PINs from disclosure
    - Ensure customers privacy
  120. 120Security goals depending on the application environment 1 (Electronic trading)- Assure source and integrity of transactions
    - Protect corporate privacy
    - Provide legally binding electronic signatures on transactions
  121. 121Security goals depending on the application environment 1 (Government)- Protect against disclosure of sensitive information
    - Provide electronic signatures on government documents
  122. 122Security goals depending on the application environment 2 (Public Telecommunication Providers)- Restrict access to administrative functions to authorized personnel
    - Protect against service interruptions
    - Protect subscribers privacy
  123. 123Security goals depending on the application environment 2 (Corporate / Private Networks)- Protect corporate / individual privacy
    - Ensure message authenticity
  124. 124Security goals depending on the application environment 2 (All Networks)- Prevent outside penetrations (who wants hackers?)
  125. 125Security goal depending on the application environment=> Sometimes security goals are also called security objectives
  126. 126Security Goals Technically Defined (Confidentiality)- Data transmitted or stored should only be revealed to an intended audience
    - Confidentiality of entities is also referred to as anonymity
  127. 127Security Goals Technically Defined (Data Integrity)- It should be possible to detect any modification of data
    - This requires to be able to identify the creator of some data
  128. 128Security Goals Technically Defined (Accountability)- It should be possible to identify the entity responsible for any communication event
  129. 129Security Goals Technically Defined (Controlled Access)- Only authorized entities should be able to access certain services or information
  130. 130Threats Technically Defined (Masquerade)- An entity claims to be another entity
  131. 131Threats Technically Defined (Eavesdropping)- An entity reads information it is not intended to read
  132. 132Threats Technically Defined (Authorization Violation)- An entity uses a service or resources it is not intended to use
  133. 133Threats Technically Defined (Loss or Modification of (transmitted) Information)- Data is being altered or destroyed
  134. 134Threats Technically Defined (Denial of Communication Acts (Repudiation))- An entity falsely denies its participation in a communication act
  135. 135Threats Technically Defined (Forgery of Information)- An entity creates a new information in the name of another entity
  136. 136Threats Technically Defined (Sabotage)- Any action that aims to reduce the availability and/or correct functioning of services or systems
  137. 137Threats and Technical Security GoalsThreats and Technical Security Goals
  138. 138Security Analysis of Layered Protocol Architectures 1Security Analysis of Layered Protocol Architectures 1
  139. 139Security Analysis of Layered Protocol Architectures 2Security Analysis of Layered Protocol Architectures 2
  140. 140Attacking Communications on the Message Level (Passive attacks)- Eavesdropping
  141. 141Attacking Communications on the Message Level (Active attacks)- Delay of PDUs (Protocol Data Units)
    - Replay of PDUs
    - Deletion of PDUs
    - Modification of PDUs
    - Insertion of PDUs
  142. 142Attacking Communications on the Message Level (Successful launch of one of the above attacks requires)- There are no detectable side effects to other communications (connections/connectionless transmissions)
    - There are no side effects to other PDUs of the same connection/connectionless data transmission between the same entities
  143. 143Attacking Communications on the Message Level- A security analysis of a protocol architecture has to analyse these attacks according to the architecture's layers
  144. 144Safeguards Against Information Security Threats 1 (Physical Security)- Locks or other physical access control
    - Tamper-proofing of sensitive equipment
    - Environmental controls
  145. 145Safeguards Against Information Security Threats 1 (Personnel Security)- Identification of position sensitivity
    - Employee screening processes
    - Security training and awareness
  146. 146Safeguards Against Information Security Threats 1 (Administrative Security)- Controlling import of foreign software
    - Procedures for investigating security breaches
    - Reviewing audit trails
    - REviewing accountability controls
  147. 147Safeguards Against Information Security Threats 1 (Emanations Security)- Radio Frequency and other electromagnetic emanations controls
  148. 148Safeguards Against Information Security Threats 2 (Media Security)- Safeguarding storage of information
    - Controlling marking, reproduction and destruction of information
    - Ensuring that media containing information are destroyed securely
    - Scanning media for viruses
  149. 149Safeguards Against Information Security Threats 2 (Lifecycle Controls)- Trusted system design, implementation, evaluation and endorsement
    - Programming standards and controls
    - Documentation controls
  150. 150Safeguards Against Information Security Threats 2 (Computer Security)- Protection of information while stored/processed in a computer system
    - Protection of the computing devices itself
  151. 151Safeguards Against Information Security Threats 2 (Communications Security)- Protection of information during transport from one system to another
    - Protection of the communication infrastructure itself
  152. 152Communications Security: Some Terminology (Security Service)Communications Security: Some Terminology (Security Service)
  153. 153Communications Security: Some Terminology (Cryptographic Algorithm)- A mathematical transformation of input data (e.g. data key) to output data
    - Cryptographic algorithms are used in cryptographic protocols
  154. 154Communications Security: Some Terminology (Cryptographic Protocol)- A series of steps and message exchanges between multiple entities in order to achieve a specific security object
  155. 155Security Services - Overview (Authentication)- The most fundamental security service which ensures, that an entity has in fact the identity it claims to have
  156. 156Security Services - Overview (Integrity)- In some kind, the "small brother" of the authentication service, as it ensures, that data created by specific entities may not be modified without detection
  157. 157Security Services - Overview (Confidentiality)- The most popular security service, ensuring secrecy of protected data
  158. 158Security Services - Overview (Access Control)- Controls that each identity accesses only those services and information it is entitled to
  159. 159Security Services - Overview (Non-Repudiation)- Protects against that entities participating in a communication exchange can later falsely deny that the exchange occurred
  160. 160Cryptology - Definition and Terminology (Cryptology)- Science concerned with communications in secure and usually secret form
    - The term is derived from the Greek kryptos (hidden) and logos (word)
  161. 161Cryptology - Definition and Terminology (Cryptology) (Cryptology encompasses) (Cryptography (graphein = to write))- The study of the principles and techniques by which information can be concealed in ciphertext an later revealed by legitimate user employing a secret key
  162. 162Cryptology - Definition and Terminology (Cryptology) (Cryptology encompasses) (Cryptoanalysis (analyein = to loosen, to untie))- The science (and art) of recovering information from ciphers without knowledge of the key
  163. 163Cryptology - Definition and Terminology (Cipher)- Method of transforming a message (plaintext) to conceal its meaning
    - Also used as synonym for the concealed ciphertext
    - Ciphers are one class of cryptographic algorithms
    - The transformation usually takes the message and a (secret) key as input
  164. 164Cryptographic Algorithms (Encryption of data)- transforms plaintext data into ciphertext in order to conceal its' meaning
  165. 165Cryptographic Algorithms (Signing of data)- computes a check value or digital signature to a given plain- or ciphertext, that can be verified by some or all entities being able to access the signed data
  166. 166Cryptographic Algorithms- Some cryptographic algorithms can be used for both purposes, some are only secure and/or efficient for one of them
  167. 167Cryptographic Algorithms (Symmetric cryptography)- Symmetric cryptography using 1 key for en-/decryption or signing/checking
  168. 168Cryptographic Algorithms (Asymmetric cryptography)- Asymmetric cryptography using 2 different keys for en-/decryption or signing/checking
  169. 169Cryptographic Algorithms (Cryptographic hash functions)- Cryptographic hash functions using 0 keys (the "key" is not a separate input but "appended" to or "mixed" with the data)
  170. 170Important Properties of Encryption AlgorithmsImportant Properties of Encryption Algorithms
  171. 171Symmetric EncryptionSymmetric Encryption
  172. 172Asymmetric Cryptography (General idea)-Asymmetric Cryptography (General idea)
  173. 173Asymmetric Cryptography (Applications) (Encryption)Asymmetric Cryptography (Applications) (Encryption)
  174. 174Asymmetric Cryptography (Applications) (Signing)Asymmetric Cryptography (Applications) (Signing)
  175. 175Asymmetric Cryptography (Applications) (Attention)- It is crucial, that everyone can verify that he really knows A's public key and not the key of an adversary!
  176. 176Asymmetric Cryptography (Practical considerations)- Asymmetric cryptographic operations are about magnitudes slower than symmetric ones
    - Therefore, they are often not used for encrypting/signing bulk data
    - Symmetric techniques are used to encrypt/compute a cryptographic hash value and asymmetric cryptography is just used to encrypt a key/hash value
  177. 177Detection of Message Modifications (Motivation)- An error detection code over a message enables the receiver to check if a message was altered during transmission
    -> Examples: Parity, Bit-Interleaved Parity, Cyclic Redundancy Check (CRC)
    - This leads to the wish of having a similar value called modification check value that allows to check, if a message has been modified during transmission
  178. 178Detection of Message Modifications (Realization of modification check values) (Cryptographic Hash Functions)- These are either combined with asymmetric cryptography to obtain a signed modification detection code (MDC) or already include a shared secret mixed with the message
  179. 179Detection of Message Modifications (Realization of modification check values) (Message Authentication Codes)- Common message authentication codes (MAC) are constructed from a symmetric block cipher
  180. 180Cryptographic Protocols (Definition)- A cryptographic protocol is defined as a series of steps and message exchanges between multiple entities in order to achieve a specific security objective
  181. 181Cryptographic Protocols (Applications of cryptographic protocols)- Key exchange
    - Combined authentication and key exchange
  182. 182Cryptographic Protocols (Applications of cryptographic protocols) (Authentication) (Data origin authentication)- The security service, that enables a receiver to verify by whom a message was created and that it has not been modified
  183. 183Cryptographic Protocols (Applications of cryptographic protocols) (Authentication) (Entity authentication)- The security service, that enables communication partners to verify the identity of their peer entities
  184. 184Security in Networks: What to do where?- Analogous to the methodology of security analysis, there are two dimensions guiding the integration of security services into communication architectures
  185. 185Security in Networks: What to do where? (Bild)Security in Networks: What to do where? (Bild)
  186. 186A Pragmatic Model for Secured & Networked ComputingA Pragmatic Model for Secured &amp; Networked Computing
  187. 187A Pragmatic Model for Secured & Networked Computing (Application)- A piece of software that accomplishes some specific task, e.g. electronic email, web service, word processing, data storage, etc.
  188. 188A Pragmatic Model for Secured & Networked Computing (End System)- One piece of equipment, anywhere in the range from personal computer to server to mainframe computer
    - For security purposes one end system usually has one policy authority
  189. 189A Pragmatic Model for Secured & Networked Computing (Subnetwork)- A collection of communication facilities being under the control of one administrative organization, e.g. a LAN, campus network, WAN, etc.
    - For security purposes one subnetwork usually has one policy authority
  190. 190A Pragmatic Model for Secured & Networked Computing (Inter-Network)- A collection of inter-connected subnetworks
    - In general, the subnets connected in an inter-network have different policy authorities
  191. 191A Pragmatic Model for Secured & Networked Computing- There are four levels at which distinct requirements for security protocol elements arise:
    -> Application level
    -> End system level
    -> Subnetwork level
    -> Link level
  192. 192A Pragmatic Model for Secured & Networked Computing (Application level)- Security protocol elements that are application dependent
  193. 193A Pragmatic Model for Secured & Networked Computing (End system level)- Provision of protection on an end system to end system basis
  194. 194A Pragmatic Model for Secured & Networked Computing (Subnetwork level)- Provision of protection over a subnetwork on an inter-network which is considered less secure than other parts of the network environment
  195. 195A Pragmatic Model for Secured & Networked Computing (Link level)- Provision of protection internal to a subnetwork, e.g. over a link which is considered less trusted than other parts of the subnetwork environment
  196. 196Relationships Between Layers & Requirements LevelsRelationships Between Layers &amp; Requirements Levels
  197. 197Relationships Between Layers & Requirements Levels (Bild)Relationships Between Layers &amp; Requirements Levels (Bild)
  198. 198Security Problems of the Internet Protocol (When an entity receives an IP packet, it has no assurance of) (Data origin authentication/data integrity)- The packet has actually been send by the entity which is referenced by the source address of the packet
    - The packet contains the original content the sender placed into it, so that it has not been modified during transport
    - The receiving entity is in fact the entity to which the sender wanted to send the packet
  199. 199Security Problems of the Internet Protocol (When an entity receives an IP packet, it has no assurance of) (Confidentiality)Security Problems of the Internet Protocol (When an entity receives an IP packet, it has no assurance of) (Confidentiality)
  200. 200Security Objectives of IPSec (IPSec aims to ensure the following security objectives) (Data origin authentication/connectionless data integrity)- It is not possible to send an IP datagram with neither a masqueraded IP source nor destination address without the receiver being able to detect this
    - It is not possible to modify an IP datagram in transit, without the receiver being able to detect the modification

Informationen

Beschreibung
Karteikarten am Chapter 9-10, erstellt von Julian Rottenberg am 24/06/2018.
Erstellt von
Julian Rottenberg · Jun 2018
Aktualisiert
25 Jun 2018
Aufrufe
3
Bewertung

Feedback

Worum geht es?

Wie gefällt dir das neue Design?

Dein Eindruck