1. 1 CSE 524: Lecture 16 Application layer (Part 3)

2. 2 Administrative Programming assignment –Due Monday, 12/1 –Send to Kiran Thanksgiving holiday –Lecture on Wednesday 11/26 optional Security issues not covered in CSE 506 DoS, Traceback, Intrusion detection, etc.

3. 3 Application Layer So far –Application layer functions –Specific applications HTTP DNS SMTP/POP Today –More applications FTP P2P –Internet challenges

4. 4 AL: ftp: the file transfer protocol transfer file to/from remote host client/server model –client: side that initiates transfer (either to/from remote) –server: remote host ftp: RFC 959 ftp server: port 21 file transfer FTP server FTP user interface FTP client local file system remote file system user at host

5. 5 AL: ftp: separate control, data connections ftp client contacts ftp server at port 21, specifying TCP as transport protocol two parallel TCP connections opened: –control: exchange commands, responses between client, server. “out of band control” –data: file data to/from server ftp server maintains “state”: current directory, earlier authentication –Note the difference to HTTP authentication Protocol allows one ftp client to initiate a transfer between two ftp servers FTP client FTP server TCP control connection port 21 TCP data connection port 20

6. 6 AL: ftp commands, responses Sample commands: sent as ASCII text over control channel USER username PASS password LIST return list of file in current directory RETR filename retrieves (gets) file STOR filename stores (puts) file onto remote host Sample return codes status code and phrase (as in http) 331 Username OK, password required 125 data connection already open; transfer starting 425 Can’t open data connection 452 Error writing file

7. 7 AL: ftp, NAT and the PORT command Normal FTP mode –Server has port 20, 21 reserved –Client initiates control connection by connecting to port 21 on server –Client allocates port X for data connection –Client passes the data connection port (X) and its IP address in a PORT command to server –Server parses PORT command and initiates connection from its own port 20 to the client on port Y –What if client is behind a NAT device? NAT must capture outgoing connections destined for port 21 What if NAT doesn’t parse PORT command correctly? What if ftp server is running on a different port than 21? http://www.practicallynetworked.com/support/linksys_ftp_port. htmhttp://www.practicallynetworked.com/support/linksys_ftp_port. htm

8. 8 AL: ftp, NAT, and the PORT command Passive (PASV) mode –Client initiates control connection by connecting to port 21 on server –Client enables “Passive” mode –Server responds with PORT command giving client the IP address and port to use for subsequent data connection (usually port 20, but can be bypassed) –Client initiates data connection by connecting to specified port on server –Most web browsers do PASV-mode ftp –What if server is behind a NAT device? See client issues –What if both client and server are behind NAT devices? Problem Similar to P2P xfers

9. 9 AL: P2P file sharing Example Alice runs P2P client application on her notebook computer Intermittently connects to Internet; gets new IP address for each connection Asks for “Hey Jude” Application displays other peers that have copy of Hey Jude. Alice chooses one of the peers, Bob. File is copied from Bob’s PC to Alice’s notebook: HTTP While Alice downloads, other users uploading from Alice. Alice’s peer is both a Web client and a transient Web server. All peers are servers = highly scalable!

10. 10 AL: P2P: 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 centralized directory server peers Alice Bob 1 1 1 1 2 3

11. 11 AL: P2P: problems with centralized directory Single point of failure Performance bottleneck Copyright infringement file transfer is decentralized, but locating content is highly centralized

12. 12 AL: P2P: decentralized directory Each peer is either a group leader or assigned to a group leader. Group leader tracks the content in all its children. Peer queries group leader; group leader may query other group leaders.

13. 13 AL: More about decentralized directory overlay network peers are nodes edges between peers and their group leaders edges between some pairs of group leaders virtual neighbors bootstrap node connecting peer is either assigned to a group leader or designated as leader advantages of approach no centralized directory server –location service distributed over peers –more difficult to shut down disadvantages of approach bootstrap node needed group leaders can get overloaded

14. 14 AL: P2P: Decentralized, flat search via flooding Gnutella no hierarchy use bootstrap node to learn about others join message Send query to neighbors Neighbors forward query If queried peer has object, it sends message back to querying peer join

15. 15 AL: P2P: more on query flooding Pros peers have similar responsibilities no central registry, no group leaders, entirely flat highly decentralized no peer maintains directory info Cons excessive query traffic query radius: may not have content when present bootstrap node maintenance of overlay network

16. 16 AL: P2P: BitTorrent Previous systems –Sources/servers Have entire copy of content Keep content available for others to download –Clients Connect to sources/servers with full copy –Problems Must force clients to become sources/servers for P2P application to work Can’t redistribute data blocks of a file until it is received in its entirety (large files problematic) No control of content (must rely on naming and popularity to infer integrity) –“URL-based P2P?” Slides courtesy of Karthik Tamilmani

17. 17 AL: Philosophy Author: Bram Cohen Based on Tit-for-tat –Incentive - Uploading while downloading –Get preference in downloading if you supply good upload Pieces of files Components –Ordinary web server to serve up metainfo file (.torrent) –Client web browser –BitTorrent tracker (location of which is specified as a URL in.torrent) –Original downloader (the first “seed”) –Client downloader

18. 18 AL: Overall Architecture Web page with link to.torrent A B C Peer [Leech] Downloader “US” Peer [Leech] Tracker Web Server.torrent Origin Downloader [Seed] Peer [Seed]

19. 19 AL: Overall Architecture Web page with link to.torrent A B C Peer [Leech] Downloader “US” Peer [Seed] Peer [Leech] Tracker Get-announce Web Server Origin Downloader [Seed]

20. 20 AL: Overall Architecture Web page with link to.torrent A B C Peer [Leech] Downloader “US” Peer [Seed] Peer [Leech] Tracker Response-peer list Web Server Origin Downloader [Seed]

21. 21 AL: Overall Architecture Web page with link to.torrent A B C Peer [Leech] Downloader “US” Peer [Seed] Peer [Leech] Tracker Shake-hand Web Server Shake-hand Origin Downloader [Seed] Shake-hand

22. 22 AL: Overall Architecture Web page with link to.torrent A B C Peer [Leech] Downloader “US” Peer [Seed] Peer [Leech] Tracker pieces Web Server Origin Downloader [Seed] pieces

23. 23 AL: Overall Architecture Web page with link to.torrent A B C Peer [Leech] Downloader “US” Peer [Seed] Peer [Leech] Tracker pieces Web Server Origin Downloader [Seed] pieces

24. 24 AL: Overall Architecture Web page with link to.torrent A B C Peer [Leech] Downloader “US” Peer [Leech] Tracker Get-announce Response-peer list pieces Web Server Origin Downloader [Seed] pieces Peer [Seed]

25. 25 AL: Messages Peer – Peer messages –TCP Sockets Peer – Tracker messages –HTTP Request/Response B-encoding http://bitconjurer.org/BitTorrent/protocol.html

26. 26 AL:.torrent URL of the tracker Dictionary keys for B-encoding scheme Pieces Piece length Name Length Files –Path –length

27. 27 AL: Tracker Peer cache –IP, port, peer id State information –Completed –Downloading Returns random list

28. 28

29. 29 AL: Peer Operation File space allocated Connect to peers Bitfield –have(1) and not have(0) Have –Advertise pieces Interest /Not_interested –Expressing interest in the pieces published by the peer Requesting for a chunk –Request

30. 30 AL: Peer Operation Choking algorithm –Choke/Unchoke Avoid large numbers of TCP connections Optimistic unchoke for a peer, rotates every 30 sec. Preferred peers do not get choked –Snubbing behavior Prevented by Anti-snubbing. Upload to interested peers who are not choking.

31. 31 AL: Peer Operation Verify on receiving complete piece Endgame Behavior –Cancel –To fix the “waiting” on the last slow peer

32. 32 AL: Experimental Client

33. 33

34. 34 AL: Strengths Better bandwidth utilization –Never before speeds. Up to 7 MB/s from the Internet. Limit free riding – tit-for-tat Limit leech attack – coupling upload & download Ability to resume a download

35. 35 AL: Drawbacks Small files – latency, overhead Random list of peers - naive Scalability –Millions of peers – Tracker behavior (uses 1/1000 of bandwidth) –Single point of failure Robustness –System progress dependent on altruistic nature of seeds (and peers) –Malicious attacks and leeches.

36. 36 AL: Interesting links Official site: http://bitconjurer.org/BitTorrenthttp://bitconjurer.org/BitTorrent BitTorrent FAQ: http://btfaq.comhttp://btfaq.com Torrent sites –http://f.scarywater.nethttp://f.scarywater.net –http://www.suprnova.orghttp://www.suprnova.org –http://tvtorrents.comhttp://tvtorrents.com Remember –leave your download windows open –Big brother is watching!

37. 37 End of application layer and all layers What’s next? –Internet challenges Doing this one out-of-order because of holiday –Lecture on security issues –Putting it all together lecture (saving this until Monday)

38. 38 Internet challenges Not a complete list –Address depletion (IPv4, IPv6) –NAT and the loss of transparency –Routing infrastructure –Quality of service –Security –DNS scaling –Dealing with privatization –Interplanetary Internet

39. 39 Address depletion IPv4: 32-bit address (4.3 billion identifiers) –25% in use 960 million addresses (advertised in BGP tables) –http://www.caida.org/outreach/resources/learn/ipv4space/http://www.caida.org/outreach/resources/learn/ipv4space/ –Inactive IP addresses advertised as well –Estimated 86 million active (July 2000) –http://www.netsizer.com/http://www.netsizer.com/ –Do we need more addresses? IPv6: 128-bit address NAT: extend current space via hack

40. 40 Current IP address allocation

41. 41 NAT Network address translation Source and destination IP addresses and (sometimes) ports rewritten by device Rewritten without knowledge of end-hosts Translation typically performed only on IP address portion of packet not on addresses within data Envelope analogy –Return address on outside changed –Return address on inside unchanged –Application data must be rewritten to maintain consistency

42. 42 NAT What’s bad about NAT? –Breaks transparency of IP –Breaks hourglass and end-to-end principles (network must be changed for new applications to be deployed) –FTP, servers, P2P services and NAT –SIP, conferencing applications –Breaks IPsec –Man-in-the-middle attacks What’s good about NAT? –Renumbering easy

43. 43 NAT Application writing before NAT –New applications require no changes to be deployed on the Internet –New applications require no changes in the Internet to be deployed Application writing after NAT –All new applications must be written with explicit knowledge of intermediate devices which rewrite network and application information

44. 44 Routing infrastructure http://www.telstra.net/ops/bgptable.html Backbone routers must keep table of all routes (75000 entries) Growth of table size –Alleviated with CIDR aggregation and NAT –Potentially exacerbated if portable addressing and multi-homing used Routing instability –Frequency of updates increases with size –Update damping occurring already –Did not respond well under Code Red BGP sessions broke Update floods exacerbating load Potential for breakdown in connectivity

45. 45 Routing infrastructure

46. 46 Routing infrastructure Reducing state in the network –Global state at every backbone router –Other non-global approaches? Ambulance routing Airplane routing Landmark routing Chess games Limited-distance look-ahead Better scaling properties

47. 47 Routing infrastructure Non-adaptive routing on backbone –Early-exit (hot-potato) routing Tier 1 ISPs route traffic solely on whether destination is within network Limited alternative paths Limited robustness and poor performance

48. 48 Routing infrastructure Scaling routing performance –Lambda switching, MPLS DWDM requires extremely fast forwarding At edges, map traffic based on IP address to wavelength or other non-IP label Wavelength or label switch across multiple hops to other edge Eliminate intermediate IP route lookups –Faster IP lookups Data structures and algorithms for fast lookups

49. 49 Routing Infrastructure Other challenges –Policy-based routing, packet classification –Non-destination-based routing –Route-pinning for QoS

50. 50 Quality of service Predictable performance “Weak-link” phenomenon Requires –ISP agreements –Global support for QoS Applications OS All devices in the network (routing failures, updates, queuing) –Problem Unpredictable media: Ethernet, 802.11, etc….

51. 51 Security Anonymity of IP –Sender fills in its address –Connectivity over security Spoofing and DDoS IP traceback –http://www.acm.org/sigs/sigcomm/sigcomm2001/p1.htmlhttp://www.acm.org/sigs/sigcomm/sigcomm2001/p1.html Ingress filtering –http://www.ietf.org/rfc/rfc2827.txthttp://www.ietf.org/rfc/rfc2827.txt

52. 52 Security DNS is weak because it is centralized –13 root name servers –Limited due to packet size constraints Routing is weak because it is decentralized –Rogue source sending updates (anecdotal evidence) What if I advertise all possible routes through my modem? S-BGP –Convergence problems L0pht –May 1998: 30min to shut down Internet

53. 53 DNS scaling Relatively flat structure 13 centralized TLD name servers.com servers overloaded DNS used as a directory service Internet directory service? –RealNames –AOL Keywords –Google

54. 54 Dealing with Privatization Improving routing instability, traffic characterization, security, etc. difficult Finding sources of disruption (software, hardware, users) difficult Problems are hidden not shared Open standards in the face of commercial interests –Patents on protocols –Closed protocols ICQ, AIM, Hotmail –Potential for closed networks Cable network consolidation, ISP consolidation D. Clark, J. Wroclawski, K. Sollins, R. Braden, “Tussle in Cyberspace: Defining Tomorrow’s Internet”

55. 55 Interplanetary Internet, Sensor networks Interplanetary: –Extremely long round-trip times, large feedback delays –Protocols designed with terrestrial timeout parameters –See Vint Cerf’s web page Sensor networks –Extremely lossy links –Disconnected operation –See SenSys 2003 program –K. Fall, “A Delay Tolerant Networking Architecture for Challenged Internets”, SIGCOMM 2003