1. Network Applications: Overview, EMail Y. Richard Yang http://zoo.cs.yale.edu/classes/cs433/ 1/27/2016

2. 2 Outline  Admin and recap r ISO/OSI Layering and Internet Layering r Application layer overview r Network applications m Email

3. 3 Admin r Questions on Assignment One

4. 4 Recap: Summary of the Taxonomy of Communication Networks circuit-switched network communication network switched network broadcast communication packet-switched network datagram network virtual circuit network

5. 5 Recap: Statistical Multiplexing r no reservation: all arrivals into the single link with rate R, the queueing delay + transmission delay: r reservation: each flow uses its own reserved (sub)link with rate R/n, the queueing delay + transmission delay: A simple model to compare bandwidth efficiency of - reservation/dedication (aka circuit-switching) and - no reservation (aka packet switching) setup - a single bottleneck link with rate R - n flows; each flow has an arrival rate of a/n

6. Recap: Layering r Why layering r reference model r modularization r Concepts r service, interface, and protocol r physical vs logical communication r Key design decision: what functionalities to put in each layer: End-to-end arguements 6

7. 7 Outline r Recap  ISO/OSI Layering and Internet Layering r Application layer overview

8. 8 ISO/OSI Reference Model r Seven layers m lower three layers are hop-by-hop m next four layers are end-to-end (host-to-host) Application Presentation Session Transport Network Datalink Physical Application Presentation Session Transport Network Datalink Physical Network Datalink Physical Physical medium

9. 9 Internet Layering r Lower three layers are hop-by-hop r Next two layers are end-to-end Application Transport Network Datalink Physical Application Transport Network Datalink Physical Network Datalink Physical Physical medium

10. 10 Internet Protocol Layers r Five layers m Application: specific network applications ftp, smtp, http, p2p, IP telephony, … m Transport: host-host data transfer tcp (reliable), udp (not reliable) m Network: routing of datagram from source to destination ipv4, ipv6 m Link: data transfer between neighboring network elements ethernet, 802.11, cable, DSL, … m Physical: bits “on the wire” cable, wireless, optical fiber application transport network link physical

11. 11 The Hourglass Architecture of the Internet network infrastructure end users IP EthernetCable/DSLWireless TCP UDP Telnet Email FTPWWW

12. 12 Link Layer (Ethernet) r Services o multiple access control - arbitrate access to shared medium o multiplexing/demultiplexin g - from/to the network layer o error detection r Interface o send frames to a directly reachable peer IP4/6 Ethernet Cable/DSL Wireless TCP UDP Telnet Email FTPWWW

13. 13 Link Layer: Protocol Header (Ethernet) IP4/6 Ethernet Cable/DSL Wireless TCP UDP Telnet Email FTPWWW IP4/6 Ethernet Cable/DSL Wireless TCP UDP Telnet Email FTPWWW IP4 link IP6 IP4 link IP6

14. 14 Network Layer: IP r Services o routing: best-effort to send packets from source to destination o multiplexing/demultiplexing from/to the transport o fragmentation and reassembling: partition a fragment into smaller packets - removed in IPv6 o error detection o certain QoS/CoS o does not provide reliability or reservation  Interface: o send a packet to a (transport-layer) peer at a specified global destination, with certain QoS/CoS IP EthernetCable/DSLWireless TCP UDP SSL Telnet Email FTPWWW

15. IP EthernetCable/DSLWireless TCP UDP SSL Telnet Email FTPWWW IP EthernetCable/DSLWireless TCP UDP SSL Telnet Email FTPWWW 15 Network Layer: IPv4 Header

16. 16 Services Provided by UDP r A connectionless service r Does not provide: connection setup, reliability, flow control, congestion control, timing, or bandwidth guarantee m why is there a UDP? IP EthernetCable/DSLWireless TCP UDP Telnet Email FTPWWW

17. 17 Transport Layer: UDP Header IP EthernetCable/DSLWireless TCP UDP Telnet Email FTP WWW IP EthernetFDDIWireless UDP TCP Telnet Email FTPWWW

18. 18 Transport Layer: TCP r Services o multiplexing/demultiplexing o reliable transport o between sending and receiving processes o setup required between sender and receiver: a connection- oriented service o flow control: sender won’t overwhelm receiver o congestion control: throttle sender when network overloaded o error detection o does not provide timing, minimum bandwidth guarantees  Interface: o send a packet to a (app-layer) peer IP EthernetFDDIWireless TCP UDP Telnet Email FTPWWW

19. 19 Transport Layer: TCP Header IP EthernetCable/DSLWireless UDP TCP Telnet Email FTP WWW IP EthernetFDDIWireless TCP UDP Telnet Email FTPWWW

20. Secure Socket Layer Architecture HTTP POP3

21. SSL Record-Layer Packet Format 20: change_cipher 21: alert 22: handshake 23: application

22. 22 Summary: The Big Picture of the Internet r Hosts and routers: m ~ 1 bil. hosts (July 2015) m autonomous systems organized roughly hierarchical m backbone links at 100 Gbps r Software: m datagram switching with virtual circuit support at backbone m layered network architecture use end-to-end arguments to determine the services provided by each layer m the hourglass architecture of the Internet IP4/6 EthernetCable/DSLWireless TCP UDP Telnet Email FTPWWW SSL

23. 23 Protocol Formats

24. 24 Outline r Recap r ISO/OSI Layering and Internet Layering  Application layer overview

25. 25 Application Layer: Goals r Conceptual + implementation aspects of network application protocols m client server paradigm m peer to peer paradigm m network app. programming r Learn about applications by examining common applications m smtp/pop m dns m http m content distribution

26. 26 How does an Application Access the Transport Service? API: application programming interface r Defines interface between application and transport layer r Multiple APIs proposed in history m XTI (X/Open Transport Interface), a slight modification of the Transport Layer Interface (TLI) developed by AT&T. r Commonly used: Socket API m sometimes called "Berkeley sockets" acknowledging their heritage from Berkeley Unix m a socket has a network-layer host IP address and a transport- layer local port number e.g., email (SMTP) port number 25, web port number 80 m an application process binds to a socket %netstat or lsof m two processes communicate by sending data into socket, reading data out of socket

27. 27 Socket API buffers, states buffers, states transport protocol

28. 28 App. and Trans.: App. Protocols and their Transport Protocols Application e-mail remote terminal access Web file transfer Internet telephony remote file server streaming multimedia Application layer protocol smtp [RFC 821] telnet [RFC 854] http [RFC 2068] ftp [RFC 959] proprietary (e.g., Vocaltec) NFS proprietary Underlying transport protocol TCP/SSL TCP TCP/SSL TCP typically UDP TCP or UDP typically UDP but moving to http r An application needs to choose the transport protocol

29. 29 Network Applications vs. Application-layer Protocols Network application: communicating, distributed processes m a process is a program that is running within a host a user agent is a process serving as an interface to the user –web: browser –streaming audio/video: media player m processes communicate by an application-layer protocol e.g., email, Web Application-layer protocols m one “piece” of an app m define messages exchanged by apps and actions taken m implementing services by using the service provided by the lower layer, i.e., the transport layer application transport network data link physical application transport network data link physical

30. 30 Client-Server Paradigm Typical network app has two pieces: client and server application transport network data link physical application transport network data link physical Client (C): r initiates contact with server (“speaks first”) r typically requests service from server r for Web, client is implemented in browser; for e-mail, in mail reader Server (S): r provides requested service to client r e.g., Web server sends requested Web page; mail server delivers e-mail request reply

31. 31 Client-Server Paradigm: Key Questions application transport network data link physical application transport network data link physical request reply Key questions to ask about a C-S application - Is the application extensible? - Is the application scalable? - How does the application handle server failures (being robust)? - How does the application provide security?

32. 32 Electronic Mail Three major components: r User agents r Mail servers r Protocols m Outgoing email SMTP m Retrieving email POP3: Post Office Protocol [RFC 1939] IMAP: Internet Mail Access Protocol [RFC 1730] user mailbox outgoing message queue mail server user agent user agent user agent mail server user agent user agent mail server user agent SMTP POP3 or IMAP SMTP r Still active m 80B emails/day m 3.9B active email boxes

33. 33 SMTP: Outgoing Email as a Client- Server Application S: 220 mr1.its.yale.edu C: HELO cyndra.yale.edu S: 250 Hello cyndra.cs.yale.edu, pleased to meet you C: MAIL FROM: S: 250 spoof@cs.yale.edu... Sender ok C: RCPT TO: S: 250 yry@yale.edu... Recipient ok C: DATA S: 354 Enter mail, end with "." on a line by itself C: Date: Wed, 23 Jan 2008 11:20:27 -0500 (EST) C: From: "Y. R. Yang" C: To: "Y. R. Yang" C: Subject: This is subject C: C: This is the message body! C: Please don’t spoof! C: C:. S: 250 Message accepted for delivery C: QUIT S: 221 mr1.its.yale.edu closing connection

34. 34 Email Transport Architecture http://www.maawg.org/sites/maawg/files/news/MAAWG_Email_Authentication_Paper_2008-07.pdf

35. 35 Mail Message Data Format SMTP: protocol for exchanging email msgs RFC 822: standard for text message format: r Header lines, e.g., m To: m From: m Subject: r Body m the “message”, ASCII characters only (any problem?) blank line header body

36. 36 Message Format: Multimedia Extensions r MIME: multimedia mail extension, RFC 2045, 2056 r Additional lines in msg header declare MIME content type From: yry@cs.yale.edu To: cs433@cs.yale.edu Subject: Network map. MIME-Version: 1.0 Content-Type: image/jpeg Content-Transfer-Encoding: base64 base64 encoded data....................................base64 encoded data multimedia data type, subtype, parameter declaration method used to encode data MIME version encoded data

37. 37 Multipart Type: How Attachment Works From: yry@cs.yale.edu To: cs433@cs.yale.edu Subject: Network map. MIME-Version: 1.0 Content-Type: multipart/mixed; boundary=98766789 --98766789 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain Hi, Attached is network topology map. --98766789 Content-Transfer-Encoding: base64 Content-Type: image/jpeg base64 encoded data....................................base64 encoded data --98766789--

38. 38 Design Review S: 220 mr1.its.yale.edu C: HELO cyndra.yale.edu S: 250 Hello cyndra.cs.yale.edu, pleased to meet you C: MAIL FROM: S: 250 spoof@cs.yale.edu... Sender ok C: RCPT TO: S: 250 yry@yale.edu... Recipient ok C: DATA S: 354 Enter mail, end with "." on a line by itself C: From: yry@cs.yale.edu C: To: cs433@cs.yale.edu C: Subject: Network map. C: MIME-Version: 1.0 C: Content-Type: image/jpeg C: Content-Transfer-Encoding: base64 C: C: base64 encoded data..... C:......................... C:......base64 encoded data C: C:. S: 250 Message accepted for delivery C: QUIT S: 221 mr1.its.yale.edu closing connection Why not make the msg headers smtp headers?

39. 39 POP3 Protocol: Mail Retrieval Authorization phase r client commands:  user: declare username  pass: password r server responses m +OK  -ERR Transaction phase, client:  list: list message numbers  retr: retrieve message by number  dele: delete r quit C: list S: 1 498 S: 2 912 S:. C: retr 1 S: S:. C: dele 1 C: retr 2 S: S:. C: dele 2 C: quit S: +OK POP3 server signing off S: +OK POP3 server ready C: user alice S: +OK C: pass hungry S: +OK user successfully logged on %openssl s_client –connect pop.gmail.com:995

40. 40 Evaluation of SMTP/POP/IMAP Key questions to ask about a C-S application - extensible? - scalable? - robust? - security? mail server user agent user agent user agent mail server user agent user agent mail server user agent SMTP POP3 or IMAP SMTP

41. 41 Email: Positive r Some nice design features we can learn from the design of the email m separate protocols for different functions email retrieval (e.g., POP3, IMAP) email transmission (SMTP) m simple/basic requests to implement basic control; fine- grain control through ASCII header and message body make the protocol easy to read/debug/extend (analogy with end-to-end layered design?) m status code in response makes message easy to parse

42. 42 Email: Challenge r Spam (Google) https://mail.google.com/intl/en/mail/help/fightspam/spamexplained.html

43. 43 Email: Challenge r A large percentage of spam/phish Source: http://www.statista.com/statistics/420400/spam-email-traffic-share-annual/

44. 44 Email: Challenge Source: http://www.statista.com/statistics/263086/countries-of-origin-of-spam/

45. 45 Discussion: How May Email Spams Be Detected?

46. 46 Detection Methods Used by GMail r Known phishing scams r Message from unconfirmed sender identity r Message you sent to Spam/similarity to suspicious messages r Administrator-set policies r Empty message content https://support.google.com/mail/answer/1366858?hl=en