Chapter 2: Application layer - SCS | UWcs456/S08/Week11.pdf · 2008-07-15 · 1 Chapter 2: Application layer 2.1 Principles of network applications app architectures app requirements

1

Chapter 2: Application layer

❒ 2.1 Principles of network applications � app architectures

� app requirements

❒ 2.2 Web and HTTP

❒ 2.4 Electronic Mail� SMTP, POP3, IMAP

❒ 2.5 DNS

❒ 2.6 P2P applications

❒ 2.7 Socket programming with TCP

❒ 2.8 Socket programming with UDP

2

Pure P2P architecture

❒ no always-on server

❒ arbitrary end systems directly communicate

❒ peers are intermittently connected and change IP addresses

❒ Three topics:� File distribution

� Searching for information

� Case Study: Skype

peer-peer

3

File Distribution: Server-Client vs P2P

Question : How much time to distribute file from one server to N peers?

us

u2d1 d2u1

uN

dN

Server

Network (with abundant bandwidth)

File, size F

us: server upload bandwidth

ui: peer i upload bandwidth

di: peer i download bandwidth

4

File distribution time: server-client

us

u2d1 d2u1

uN

dN

Server

Network (with abundant bandwidth)

F❒ server sequentially sends N copies:

� NF/us time

❒ client i takes F/di

time to download

increases linearly in N(for large N)

= dcs = max { NF/us, F/min(di) }i

Time to distribute Fto N clients using

client/server approach

5

File distribution time: P2P

us

u2d1 d2u1

uN

dN

Server

Network (with abundant bandwidth)

F❒ server must send one

copy: F/us time

❒ client i takes F/di time to download

❒ NF bits must be downloaded (aggregate)

❒ fastest possible upload rate: us + Σui

dP2P = max { F/us, F/min(di) , NF/(us + Σui) }i

6

0

0.5

1

1.5

2

2.5

3

3.5

0 5 10 15 20 25 30 35

N

Min

imum

Dis

trib

utio

n T

ime P2P

Client-Server

Server-client vs. P2P: example

Client upload rate = u, F/u = 1 hour, us = 10u, dmin ≥ us

7

File distribution: BitTorrent

tracker: tracks peers participating in torrent

torrent: group of peers exchanging chunks of a file

obtain listof peers

trading chunks

peer

❒ P2P file distribution

8

BitTorrent (1)

❒ file divided into 256KB chunks.

❒ peer joining torrent:

� has no chunks, but will accumulate them over time

� registers with tracker to get list of peers, connects to subset of peers (“neighbors”)

❒ while downloading, peer uploads chunks to other peers.

❒ peers may come and go

❒ once peer has entire file, it may (selfishly) leave or (altruistically) remain

9

BitTorrent (2)

Pulling Chunks

❒ at any given time, different peers have different subsets of file chunks

❒ periodically, a peer (Alice) asks each neighbor for list of chunks that they have.

❒ Alice sends requests for her missing chunks

� rarest first

Sending Chunks: tit-for-tat

❒ Alice sends chunks to four neighbors currently sending her chunks at the highest rate

� re-evaluate top 4 every 10 secs

❒ every 30 secs: randomly select another peer, starts sending chunks

� newly chosen peer may join top 4

� “optimistically unchoke”

10

BitTorrent: Tit-for-tat(1) Alice “optimistically unchokes” Bob(2) Alice becomes one of Bob’s top-four providers; Bob reciprocates

(3) Bob becomes one of Alice’s top-four providers

With higher upload rate, can find better trading partners & get file faster!

11

P2P: searching for information

File sharing (eg e-mule)

❒ Index dynamically tracks the locations of files that peers share.

❒ Peers need to tell index what they have.

❒ Peers search index to determine where files can be found

Instant messaging

❒ Index maps user names to locations.

❒ When user starts IM application, it needs to inform index of its location

❒ Peers search index to determine IP address of user.

Index in P2P system: maps information to peer location

(location = IP address & port number)

.

12

P2P: centralized index

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

centralizeddirectory server

peers

Alice

Bob

1

1

1

12

3

13

P2P: problems with centralized directory

❒ single point of failure

❒ performance bottleneck

❒ copyright infringement: “target” of lawsuit is obvious

file transfer is decentralized, but locating content is highly centralized

14

Query flooding

❒ fully distributed� no central server

❒ used by Gnutella

❒ Each peer indexes the files it makes available for sharing (and no other files)

overlay network: graph

❒ edge between peer X and Y if there’s a TCP connection

❒ all active peers and edges form overlay net

❒ edge: virtual (notphysical) link

❒ given peer typically connected with < 10 overlay neighbors

15

Query flooding

Query

QueryHit

Query

Query

QueryHit

Query

Query

QueryHit

File transfer:

HTTP❒ Query messagesent over existing TCPconnections

❒ peers forwardQuery message

❒ QueryHit sent over reversepath

Scalability:

limited scopeflooding

16

Gnutella: Peer joining

1. joining peer Alice must find another peer in Gnutella network: use list of candidate peers

2. Alice sequentially attempts TCP connections with candidate peers until connection setup with Bob

3. Flooding: Alice sends Ping message to Bob; Bob forwards Ping message to his overlay neighbors (who then forward to their neighbors….)

❒ peers receiving Ping message respond to Alice with Pong message

4. Alice receives many Pong messages, and can then setup additional TCP connections

Peer leaving: see homework problem!

17

Hierarchical Overlay

❒ between centralized index, query flooding approaches

❒ each peer is either a super node or assigned to a super node� TCP connection between peer

and its super node.

� TCP connections between some pairs of super nodes.

❒ Super node tracks content in its children

ordinary peer

group-leader peer

neighoring relationshipsin overlay network

18

P2P Case study: Skype

❒ inherently P2P: pairs of users communicate.

❒ proprietary application-layer protocol (inferred via reverse engineering)

❒ hierarchical overlay with SNs

❒ Index maps usernames to IP addresses; distributed over SNs

Skype clients (SC)

Supernode

(SN)

Skype login server

19

Peers as relays

❒ Problem when both Alice and Bob are behind “NATs”. � NAT prevents an outside

peer from initiating a call to insider peer

❒ Solution:� Using Alice’s and Bob’s

SNs, Relay is chosen

� Each peer initiates session with relay.

� Peers can now communicate through NATs via relay

20

Chapter 2: Summary

❒ application architectures� client-server

� P2P

� hybrid

❒ application service requirements:� reliability, bandwidth, delay

❒ Internet transport service model� connection-oriented,

reliable: TCP

� unreliable, datagrams: UDP

our study of network apps now complete!

❒ specific protocols:� HTTP

� FTP

� SMTP, POP, IMAP

� DNS

� P2P: BitTorrent, Skype

❒ socket programming

21

Chapter 2: Summary

❒ typical request/reply message exchange:� client requests info or

service

� server responds with data, status code

❒ message formats:� headers: fields giving info

about data

� data: info being communicated

Most importantly: learned about protocols

Important themes:

❒ control vs. data msgs

� in-band, out-of-band

❒ centralized vs. decentralized

❒ stateless vs. stateful

❒ reliable vs. unreliable msg transfer

❒ “complexity at network edge”

22

Chapter 8Network Security

A note on the use of these ppt slides:We’re making these slides freely available to all (faculty, students, readers). They’re in PowerPoint form so you can add, modify, and delete slides (including this one) and slide content to suit your needs. They obviously represent a lot of work on our part. In return for use, we only ask the following:� If you use these slides (e.g., in a class) in substantially unaltered form, that you mention their source (after all, we’d like people to use our book!)� If you post any slides in substantially unaltered form on a www site, that you note that they are adapted from (or perhaps identical to) our slides, and note our copyright of this material.

Thanks and enjoy! JFK/KWR

All material copyright 1996-2007J.F Kurose and K.W. Ross, All Rights Reserved

Computer Networking: A Top Down Approach ,4th edition. Jim Kurose, Keith RossAddison-Wesley, July 2007.

23

Chapter 8: Network Security

Chapter goals:

❒ understand principles of network security:

� cryptography and its many uses beyond “confidentiality”

� authentication

� message integrity

❒ security in practice:

� firewalls and intrusion detection systems

� security in application, transport, network, link layers

24

Chapter 8 roadmap

8.1 What is network security?

8.2 Principles of cryptography

8.3 Message integrity

8.4 End point authentication

8.5 Securing e-mail

8.6 Securing TCP connections: SSL

8.7 Network layer security: IPsec

8.8 Securing wireless LANs

8.9 Operational security: firewalls and IDS

25

What is network security?

Confidentiality: only sender, intended receiver should “understand” message contents

� sender encrypts message

� receiver decrypts message

Authentication: sender, receiver want to confirm identity of each other

Message integrity: sender, receiver want to ensure message not altered (in transit, or afterwards) without detection

Access and availability: services must be accessible and available to users

26

Friends and enemies: Alice, Bob, Trudy

❒ well-known in network security world

❒ Bob, Alice (lovers!) want to communicate “securely”

❒ Trudy (intruder) may intercept, delete, add messages

securesender

securereceiver

channel data, control messages

data data

Alice Bob

Trudy

27

Who might Bob, Alice be?

❒ … well, real-life Bobs and Alices!

❒ Web browser/server for electronic transactions (e.g., on-line purchases)

❒ on-line banking client/server

❒ DNS servers

❒ routers exchanging routing table updates

❒ other examples?

28

There are bad guys (and girls) out there!

Q: What can a “bad guy” do?

A: a lot!� eavesdrop: intercept messages

� actively insert messages into connection

� impersonation: can fake (spoof) source address in packet (or any field in packet)

� hijacking: “take over” ongoing connection by removing sender or receiver, inserting himself in place

� denial of service: prevent service from being used by others (e.g., by overloading resources)

more on this later ……

29

Chapter 8 roadmap

8.1 What is network security?

8.2 Principles of cryptography

8.3 Message integrity

8.4 End point authentication

8.5 Securing e-mail

8.6 Securing TCP connections: SSL

8.7 Network layer security: IPsec

8.8 Securing wireless LANs

8.9 Operational security: firewalls and IDS

30

The language of cryptography

symmetric key crypto: sender, receiver keys identical

public-key crypto: encryption key public, decryption key secret (private)

plaintext plaintextciphertext

KA

encryptionalgorithm

decryption algorithm

Alice’s encryptionkey

Bob’s decryptionkey

KB

31

Symmetric key cryptography

substitution cipher: substituting one thing for another� monoalphabetic cipher: substitute one letter for another

plaintext: abcdefghijklmnopqrstuvwxyz

ciphertext: mnbvcxzasdfghjklpoiuytrewq

Plaintext: bob. i love you. alice

ciphertext: nkn. s gktc wky. mgsbc

E.g.:

Q: How hard to break this simple cipher?:� brute force (how hard?)� other?

32

Symmetric key cryptography

symmetric key crypto: Bob and Alice share know same (symmetric) key: K

❒ e.g., key is knowing substitution pattern in mono alphabetic substitution cipher

❒ Q: how do Bob and Alice agree on key value?

plaintextciphertext

KA-B

encryptionalgorithm

decryption algorithm

A-B

KA-B

plaintextmessage, m

K (m)A-B

K (m)A-B

m = K ( )A-B

33

Symmetric key crypto: DES

DES: Data Encryption Standard

❒ US encryption standard [NIST 1993]

❒ 56-bit symmetric key, 64-bit plaintext input

❒ How secure is DES?

� DES Challenge: 56-bit-key-encrypted phrase (“Strong cryptography makes the world a safer place”) decrypted (brute force) in 4 months

� no known “backdoor” decryption approach

❒ making DES more secure:

� use three keys sequentially (3-DES) on each datum

� use cipher-block chaining

34

AES: Advanced Encryption Standard

❒ new (Nov. 2001) symmetric-key NIST standard, replacing DES

❒ processes data in 128 bit blocks

❒ 128, 192, or 256 bit keys

❒ brute force decryption (try each key) taking 1 sec on DES, takes 149 trillion years for AES

35

Public key cryptography

symmetric key crypto

❒ requires sender, receiver know shared secret key

❒ Q: how to agree on key in first place (particularly if never “met”)?

public key cryptography

❒ radically different approach [Diffie-Hellman76, RSA78]

❒ sender, receiver do notshare secret key

❒ public encryption key known to all

❒ private decryption key known only to receiver

36

Public key cryptography

plaintextmessage, m

ciphertextencryptionalgorithm

decryption algorithm

Bob’s publickey

plaintextmessageK (m)

B

+

K B

+

Bob’s privatekey

K B

-

m = K (K (m))B

+B

-

37

Public key encryption algorithms

need K ( ) and K ( ) such thatB B

. .

given public key K , it should be impossible to compute private key K B

B

Requirements:

1

2

RSA: Rivest, Shamir, Adleman algorithm

+ -

K (K (m)) = mBB

- +

+

-

38

RSA: Choosing keys

1. Choose two large prime numbers p, q.(e.g., 1024 bits each)

2. Compute n = pq, z = (p-1)(q-1)

3. Choose e (with e<n) that has no common factorswith z. (e, z are “relatively prime”).

4. Choose d such that ed-1 is exactly divisible by z.(in other words: ed mod z = 1 ).

5. Public key is (n,e). Private key is (n,d).

KB+ K

B-

39

RSA: Encryption, decryption

0. Given (n,e) and (n,d) as computed above

1. To encrypt bit pattern, m, compute

c = m mod ne (i.e., remainder when m is divided by n)e

2. To decrypt received bit pattern, c, compute

m = c mod nd (i.e., remainder when c is divided by n)d

m = (m mod n)e mod ndMagichappens!

c

40

RSA example:

Bob chooses p=5, q=7. Then n=35, z=24.

e=5 (so e, z relatively prime).d=29 (so ed-1 exactly divisible by z.

letter m me c = m mod ne

l 12 1524832 17

c m = c mod nd

17 481968572106750915091411825223071697 12cd

letter

l

encrypt:

decrypt: