1. DMET 602: Networks and Media Lab Amr El Mougy Yasmeen EssamAlaa Tarek

2. Exp 7: Higher Layer Protocols

3. 2: Application Layer3 Classifying Application Protocols  Method of communication  Stateful or stateless  Type of encoding (binary or text)  In-band or out-of-band

4. Method of Communication 1-4  Communication between devices either involve message passing, or request/response  Request/response is the most prevalent type. Uses client/server model to describe the roles of hosts  Has the advantage of being simple. However, only two machines are involved  Other patterns include spanning tree, broadcast, P2P

5. N-Tier Request/Response 1-5  Layered system. Each tier provides a service for the higher level  Advantages include: information hiding, scalability, better management

6. Stateful Vs. Stateless 1-6  Stateful: server knows which step (state) has been reached – Individual messages need to carry less data – Server does not have to re-establish context every time  Stateless: – Client remembers the state, sends to server each time  simpler architecture – Server processes each request independently  requests have to be more self-describing – More scalable, facilitates load balancing  Can vary with level – Many systems like Web run stateless protocols (e.g. HTTP) over streams…at the packet level, TCP streams are stateful – HTTP itself is mostly stateless, but many HTTP requests (typically POSTs) update persistent state at the server

7. Type of Encoding 1-7  Text: messages are encoded characters  Binary: any bit patterns  Pros and cons quite similar to those for text vs. binary file formats  When sending between compatible machines, binary can be much faster because no conversion needed  Most Internet-scale application protocols (HTTP, SMTP) use text for protocol elements and for all content except photo/audio/video  HTTP 2.0 moving to binary (for msg size and parsing speed)

8. In-Band vs Out-of-Band 1-8  In-band: control data and application data coexist on the same connection (same transport layer port numbers)  HTTP and SMTP are in-band protocols  Out-of-band: control data is on a separate connection  Typically the control connection establishes the data exchange  FTP is an out-of-band protocol

9. 2: Application Layer 9 Web and HTTP  Web page consists of objects  Object can be HTML file, JPEG image, Java applet, audio file,…  Web page consists of base HTML-file which includes several referenced objects  Each object is addressable by a URL  Example URL: www.someschool.edu/someDept/pic.gif host name path name

10. Resource Identification 1-10  Resources are identified by a Uniform Resource Locator (URL), Uniform Resource Identifier (URI), or Uniform Resource Name (URN)  URI can be a URL or URN  URL tells you the name of the resource, and how to retrieve it  has to specify the protocol used to retrieve this resource - [scheme]://[Domain]:[port]/[path]?[QueryString]#[FragmentId] - Https://www.wrox.com/remtitle.cgi?isgn=0470114878  URN is only a name give to a resource - urn:[namespace identifier]:[namespace specific string] - urn:isbn:9780470114872

11. 2: Application Layer11 HTTP overview HTTP: hypertext transfer protocol  Web’s application layer protocol  client/server model  client: browser that requests, receives, “displays” Web objects  server: Web server sends objects in response to requests PC running Explorer Server running Apache Web server Mac running Navigator HTTP request HTTP response

12. 2: Application Layer12 HTTP overview (continued) Uses TCP:  client initiates TCP connection (creates socket) to server, port 80  server accepts TCP connection from client  HTTP messages (application-layer protocol messages) exchanged between browser (HTTP client) and Web server (HTTP server)  TCP connection closed HTTP is “stateless”  server maintains no information about past client requests Protocols that maintain “state” are complex! rpast history (state) must be maintained rif server/client crashes, their views of “state” may be inconsistent, must be reconciled aside

13. 2: Application Layer13 HTTP connections Nonpersistent HTTP  At most one object is sent over a TCP connection Persistent HTTP  Multiple objects can be sent over single TCP connection between client and server

14. 2: Application Layer14 Nonpersistent HTTP Suppose user enters URL www.someSchool.edu/someDepartment/home.index (contains text, references to 10 jpeg images) 1a. HTTP client initiates TCP connection to HTTP server (process) at www.someSchool.edu on port 80 2. HTTP client sends HTTP request message (containing URL) into TCP connection socket. Message indicates that client wants object someDepartment/home.index 1b. HTTP server at host www.someSchool.edu waiting for TCP connection at port 80. “accepts” connection, notifying client 3. HTTP server receives request message, forms response message containing requested object, and sends message into its socket time

15. 2: Application Layer15 Nonpersistent HTTP (cont.) 5. HTTP client receives response message containing html file, displays html. Parsing html file, finds 10 referenced jpeg objects 6. Steps 1-5 repeated for each of 10 jpeg objects 4. HTTP server closes TCP connection time

16. 2: Application Layer 16 Non-Persistent HTTP: Response time Definition of RTT: time for a small packet to travel from client to server and back Response time:  one RTT to initiate TCP connection  one RTT for HTTP request and first few bytes of HTTP response to return  file transmission time total = 2RTT+transmit time time to transmit file initiate TCP connection RTT request file RTT file received time

17. 2: Application Layer17 Persistent HTTP Nonpersistent HTTP issues:  requires 2 RTTs per object  OS overhead for each TCP connection  browsers often open parallel TCP connections to fetch referenced objects Persistent HTTP  server leaves connection open after sending response  subsequent HTTP messages between same client/server sent over open connection  client sends requests as soon as it encounters a referenced object  as little as one RTT per referenced object

18. 2: Application Layer 18 HTTP request message  two types of HTTP messages: request, response  HTTP request message:  ASCII (human-readable format) GET /somedir/page.html HTTP/1.1 Host: www.someschool.edu User-agent: Mozilla/4.0 Connection: close Accept-language:fr (extra carriage return, line feed) request line (GET, POST, HEAD commands) header lines Carriage return, line feed indicates end of message

19. 2: Application Layer 19 HTTP request message: general format

20. 2: Application Layer20 Uploading form input Post method:  Web page often includes form input  Input is uploaded to server in entity body GET (URL) method:  Uses GET method  Input is uploaded in URL field of request line: www.somesite.com/animalsearch?monkeys&banana

21. 2: Application Layer21 Method types HTTP/1.0  GET  POST  HEAD  asks server to leave requested object out of response HTTP/1.1  GET, POST, HEAD  PUT  uploads file in entity body to path specified in URL field  DELETE  deletes file specified in the URL field

22. 2: Application Layer 22 HTTP response message HTTP/1.1 200 OK Connection close Date: Thu, 06 Aug 1998 12:00:15 GMT Server: Apache/1.3.0 (Unix) Last-Modified: Mon, 22 Jun 1998 …... Content-Length: 6821 Content-Type: text/html data data data data data... status line (protocol, status code, status phrase) header lines data, e.g., requested HTML file

23. 2: Application Layer23 HTTP response status codes 200 OK  request succeeded, requested object later in this message 301 Moved Permanently  requested object moved, new location specified later in this message (Location:) 400 Bad Request  request message not understood by server 404 Not Found  requested document not found on this server 505 HTTP Version Not Supported In first line in server->client response message. A few sample codes:

24. 2: Application Layer24 User-server state: cookies Many major Web sites use cookies Four components: 1) cookie header line of HTTP response message 2) cookie header line in HTTP request message 3) cookie file kept on user’s host, managed by user’s browser 4) back-end database at Web site Example:  Susan always access Internet always from PC  visits specific e-commerce site for first time  when initial HTTP requests arrives at site, site creates:  unique ID  entry in backend database for ID

25. 2: Application Layer25 Cookies: keeping “state” (cont.) client server usual http response msg cookie file one week later: usual http request msg cookie: 1678 cookie- specific action access ebay 8734 usual http request msg Amazon server creates ID 1678 for user create entry usual http response Set-cookie: 1678 ebay 8734 amazon 1678 usual http request msg cookie: 1678 cookie- spectific action access ebay 8734 amazon 1678 backend database

26. 2: Application Layer26 Cookies (continued) What cookies can bring:  authorization  shopping carts  recommendations  user session state (Web e- mail) Cookies and privacy: rcookies permit sites to learn a lot about you ryou may supply name and e-mail to sites aside How to keep “state”: rprotocol endpoints: maintain state at sender/receiver over multiple transactions rcookies: http messages carry state

27. 2: Application Layer27 Web caches (proxy server)  user sets browser: Web accesses via cache  browser sends all HTTP requests to cache  object in cache: cache returns object  else cache requests object from origin server, then returns object to client Goal: satisfy client request without involving origin server client Proxy server client HTTP request HTTP response HTTP request origin server origin server HTTP response

28. 2: Application Layer28 More about Web caching  cache acts as both client and server  typically cache is installed by ISP (university, company, residential ISP) Why Web caching?  reduce response time for client request  reduce traffic on an institution’s access link.  Internet dense with caches: enables “poor” content providers to effectively deliver content (but so does P2P file sharing)

29. 2: Application Layer29 Conditional GET  Goal: don’t send object if cache has up-to-date cached version  cache: specify date of cached copy in HTTP request If-modified-since:  server: response contains no object if cached copy is up-to- date: HTTP/1.0 304 Not Modified cache server HTTP request msg If-modified-since: HTTP response HTTP/1.0 304 Not Modified object not modified HTTP request msg If-modified-since: HTTP response HTTP/1.0 200 OK object modified

30. FTP 1-30  Purpose: To Transfer files between two computers  Goals of FTP Service Promote sharing of files (programs and/or data) Encourage indirect/implicit use of remote computers Shield users from variations in file storage among hosts Transfer data reliably and efficiently  Why is it needed, file transfer seems simple?  Answer: Heterogeneous systems use different operating systems, character sets, naming conventions, directory and file structures  FTP addresses this heterogeneity

31. FTP Connection 1-31

32. TCP Connections 1-32 Control Connection Combined Connection

33. FTP Commands 1-33 CommandDescription get filename Retrieve file from server mget filename* Retrieve multiple files from server* put filename Copy local file to server mput filename* Copy multiple local files to server* open server Begin login to server bye / close / exit Logoff server ls / dir List files in current remote dir on server lcd Change local directory cd Change remote directory rhelp / remotehelp Lists commands the server accepts

34. Secure Shell (SSH) 1-34  SSH is a protocol for secure remote login and other secure network services over an insecure network  SSH Transport Layer Protocol provides server authentication, confidentiality, and integrity services runs on top of any reliable transport layer (e.g., TCP)  SSH User Authentication Protocol provides client-side user authentication runs on top of the SSH Transport Layer Protocol  SSH Connection Protocol multiplexes the secure tunnel provided by the SSH Transport Layer and User Authentication Protocols into several logical channels. These logical channels can be used for a wide range of purposes  secure interactive shell sessions  TCP port forwarding  carrying X11 connections

35. SSH Security Features 1-35  Strong algorithms –uses well established strong algorithms for encryption, integrity, key exchange, and public key management  Large key size –requires encryption to be used with at least 128 bit keys –supports larger keys too  Algorithm negotiation –encryption, integrity, key exchange, and public key algorithms are negotiated –it is easy to switch to some other algorithm without modifying the base protocol

36. SSH TLP Protocol 1-36  SSH version string exchange –both side must send a version string of the following form: “SSH-protoversion-softwareversion comments” \CR \LF –used to indicate the capabilities of an implementation –triggers compatibility extensions –all packets that follow the version string exchange is sent using the Binary Packet Protocol –MAC = message authentication code. Used to check message integrity

37. Encryption 1-37  The encryption algorithm is negotiated during the key exchange  Supported algorithms –3des-cbc (required) (168 bit key) –blowfish-cbc (recommended) –twofish256-cbc (opt) / twofish192-cbc (opt) / twofish128-cbc (recomm) –aes256-cbc (opt) / aes192-cbc (opt) / aes128-cbc (recomm) –serpent256-cbc (opt) / serpent192-cbc (opt) / serpent128-cbc (opt) –arcfour (opt) (RC4) –idea-cbc (opt) / cast128-cbc (opt)  Key and IV are also established during the key exchange  All packets sent in one direction is considered a single data stream –IV is passed from the end of one packet to the beginning of the next one  Encryption algorithm can be different in each direction

38. Message Authentication Code (MAC) 1-38  MAC algorithm and key are negotiated during the key exchange  Supported algorithms –hmac-sha1 (required) [MAC length = key length = 160 bits] –hmac-sha1-96 (recomm) [MAC length = 96, key length = 160 bits] –hmac-md5 (opt) [MAC length = key length = 128 bits] –hmac-md5-96 (opt) [MAC length = 96, key length = 128 bits]  MAC algorithms used in each direction can be different  MAC = mac( key, seq. number | clear packet ) –sequence number is implicit, not sent with the packet –sequence number is represented on 4 bytes –sequence number initialized to 0 and incremented after each packet –it is never reset (even if keys and algs are renegotiated later)

39. SSH Authentication Protocol 1-39  The protocol assumes that the underlying transport protocol provides integrity and confidentiality (e.g., SSH Transport Layer Protocol)  The protocol has access to the session ID  The server should have a timeout for authentication and disconnect if the authentication has not been accepted within the timeout period –recommended value is 10 minutes  The server should limit the number of failed authentication attempts a client may perform in a single session –recommended value is 20 attempts  Three authentication methods are supported –Public key –Password: most widely used (user name and password) –Host-based

40. Public Key Method 1-40  All implementations must support this method  Authentication is based on demonstration of the knowledge of the private key (the client signs with the private key)  The server verifies that –the public key really belongs to the user specified in the authentication request –the signature is correct

41. Host-based Method 1-41  Authentication is based on the host where the user is coming from  This method is optional  The client sends a signature that has been generated with the private host key of the client  The server verifies that –the public key really belongs to the host specified in the authentication request –the signature is correct

42. SSH Connection Protocol 1-42  Provides –interactive login sessions –remote execution of commands –forwarded TCP/IP connections –forwarded X11 connections  All these applications are implemented as “channels”  All channels are multiplexed into the single encrypted tunnel provided by the SSH Transport Layer Protocol  Channels are identified by channel numbers at both ends of the connection  Channel numbers for the same channel at the client and server sides may differ