CSC 401 Data and Computer Communications Networks

Transcription

1 CSC 401 Data and Computer Communications Networks Application Layer DNS and P2P Sec Prof. Lina Battestilli Fall 2017

2 Outline Application Layer (ch 2) 2.1 principles of network applications 2.2 Web and HTTP 2.3 electronic mail 2.4 DNS 2.5 P2P applications 2.6 Video Streaming and CDNs 2.7 Socket programming with UDP and TCP NCSU CSC401 Lina Battestilli 9

3 Parsing a URL Application Protocol and Port Host File HOSTS.TXT Originally, all hosts were in a file HOSTS.TXT, maintained by Network Information Center Hosts periodically used a file transfer protocol to download new version -- does not scale well NCSU CSC401 Lina Battestilli 10

4 Names & Addresses of Hosts people: many identifiers: SSN, name, passport # Internet hosts, routers: name, e.g., - used by humans IP address (32 bit) - used for addressing datagrams Jane Doe 1000 Some Street City, State ZIP Country Q: Why do we need IP addresses? Q: How to map between IP address and name, and vice versa? NCSU CSC401 Lina Battestilli 11

5 DNS: Domain Name System distributed database implemented in hierarchy of many name servers application-layer protocol: hosts, name servers communicate to resolve names (address/name translation) runs over UDP and uses port 53 DNS client Web Browser Webserver 1. Browser extracts and gives it to the DNS client 2. DNS client sends a query and finds out the IP address 3. Browser can then initiate a TCP connection to port 80 at that IP address. Core Internet function, implemented as application-layer protocol Complexity at network s edge 12

6 DNS: Services DNS services hostname to IP address translation host aliasing canonical, alias names mail server aliasing load distribution replicated Web servers: many IP addresses correspond to one name DNS Rotation Why not centralize DNS? single point of failure traffic volume distant centralized database maintenance A: Doesn't scale! NCSU CSC401 Lina Battestilli 13

7 DNS: Design Considerations Requirements Map names to addresses Must be able to handle huge number of records Must have distributed control: organizations can control their own names Must be robust to individual node failures Properties that make DNS feasible Read-only or Read-mostly database: hosts look up names much more often than update them Loose consistency: changes can take a little while to propagate Extensive Caching: look up a name, keep result for a long time 14

8 DNS: A Distributed, Hierarchical database Root DNS Servers ROOT com DNS servers org DNS servers edu DNS servers yahoo.com DNS servers amazon.com DNS servers pbs.org DNS servers ncsu.edu DNS servers TLD csc mae Local Authoritative umass.edu DNS servers Client wants IP for Query root server to find.com DNS server Query.com DNS server to find amazon.com DNS server Query amazon.com DNS server to get IP address for

9 DNS: root name servers c. Cogent, Herndon, VA (5 other sites) d. U Maryland College Park, MD h. ARL Aberdeen, MD j. Verisign, Dulles VA (69 other sites ) k. RIPE London (17 other sites) i. Netnod, Stockholm (37 other sites) e. NASA Mt View, CA f. Internet Software C. Palo Alto, CA (and 48 other sites) m. WIDE Tokyo (5 other sites) a. Verisign, Los Angeles CA (5 other sites) b. USC-ISI Marina del Rey, CA l. ICANN Los Angeles, CA (41 other sites) g. US DoD Columbus, OH (5 other sites) 13 organizations manage the root servers worldwide Highly replicated through anycast NCSU CSC401 Lina Battestilli 16

10 DNS: root name servers 13 root name servers worldwide j.root-servers.net server, VeriSign, is represented by 74 (as of October 2014) individual server systems located around the world, which can be queried using anycast addressing. As of October 2014, there were 504 root servers worldwide

11 -18 TLD & Authoritative Servers Top-Level Domain (TLD) servers: responsible for com, org, net, edu, aero, jobs, museums, and all top-level country domains, e.g.: uk, fr, ca, jp VeriSign maintains servers for.com TLD Educause for.edu TLD Authoritative DNS servers: Organization s own DNS server(s), providing authoritative hostname to IP mappings for organization s named hosts can be maintained by organization or service provider

12 Local DNS Name Server does NOT strictly belong to hierarchy each ISP (residential ISP, company, university) has one also called default name server when host makes DNS query, query is sent to its local DNS server has local cache of recent name-to-address translation pairs (but may be out of date!) acts as proxy, forwards query into hierarchy See Local DNS Servers ipconfig /all See local browser DNS Cache: chrome://net-internals/#dns

13 DNS name resolution example host at cis.poly.edu wants IP address for gaia.cs.umass.edu root DNS server iterated query: contacted server replies with name of server to contact I don t know this name, but ask this server Local DNS server dns.poly.edu TLD DNS server.edu 6 requesting host cis.poly.edu Authoritative DNS server dns.cs.umass.edu gaia.cs.umass.edu NCSU CSC401 Lina Battestilli 20

14 DNS name resolution example root DNS server recursive query: puts burden of name resolution on contacted name server heavy load at upper levels of hierarchy? Local DNS server dns.poly.edu TLD DNS server requesting host cis.poly.edu Authoritative DNS server dns.cs.umass.edu gaia.cs.umass.edu NCSU CSC401 Lina Battestilli 21

15 DNS: caching, updating records once (any) name server learns mapping, it caches mapping cache entries timeout (disappear) after some time (TTL) TLD servers typically cached in Local Name Servers thus root name servers not often visited cached entries may be out-of-date (best effort nameto-address translation!) if name host changes IP address, may not be known Internetwide until all TTLs expire update/notify mechanisms proposed IETF standard RFC 2136 NCSU CSC401 Lina Battestilli 22

16 DNS Resource Records (RR) DNS: distributed db storing resource records (RR) RR format: (name, value, type, ttl) type=a name is hostname value is IP address type=ns name is domain (e.g., foo.com) value is hostname of Authoritative Name Server for this domain type=cname name is alias name for some canonical (real) name value is canonical name (foo.com, relay1.bar.foo.com, CNAME) type=mx value is name of mailserver associated with name (foo.com, mail.bar.foo.com, MX) NCSU CSC401 Lina Battestilli 23

17 DNS protocol, messages query and reply messages, both with same message format 16 bit # for query, reply to query uses same # name, type fields for a query RRs in response to query records for authoritative servers additional helpful info that may be used 2 bytes 2 bytes identification flags # questions # answer RRs # authority RRs # additional RRs questions (variable # of questions) answers (variable # of RRs) authority (variable # of RRs) additional info (variable # of RRs) query or reply recursion desired recursion available reply is authoritative Empty in queries

18 Using dig to look at DNS NCSU CSC401 Lina Battestilli 25

19 Inserting records into DNS Example: new startup Network Utopia register name networkuptopia.com at DNS registrar (e.g., Network Solutions, Go Daddy) provide names, IP addresses of Authoritative Name Server (primary and secondary) registrar inserts two RRs into.com TLD server: (networkutopia.com, dns1.networkutopia.com, NS) (dns1.networkutopia.com, , A) In the Authoritative Name Server you also enter a type A record for type MX record for mail.networkutopia.com NCSU CSC401 Lina Battestilli 26

20 Attacking DNS DDoS attacks Bombard root servers with traffic Not successful to date Traffic Filtering Local DNS servers cache IPs of TLD servers, allowing root server bypass Bombard TLD servers Potentially more dangerous Redirect attacks Man-in-middle Intercept queries DNS poisoning Send bogus replies to DNS server, which caches Exploit DNS for DDoS Send queries with spoofed source address: target IP Requires amplification DNSSec RFC 4035, March, 2005 NCSU CSC401 Lina Battestilli 27

21 Outline Application Layer (ch 2) 2.1 principles of network applications 2.2 Web and HTTP 2.3 electronic mail 2.4 DNS 2.5 P2P applications 2.6 Video Streaming and CDNs 2.7 Socket programming with UDP and TCP NCSU CSC401 Lina Battestilli 31

22 Pure P2P architecture NO always-on server (minimal) arbitrary end systems directly communicate peers are intermittently connected and change IP addresses examples: file distribution (BitTorrent) Streaming(KanKan) VoIP (Skype s original design) Scalable! NCSU CSC401 Lina Battestilli

23 File distribution: client-server vs P2P Question: how much time to distribute file (size F) from one server to N peers? peer upload/download capacity is limited resource Everyone wants the file at the same time u s : server upload capacity file, size F server u s u 1 d 1 u 2 d 2 d i : peer i download capacity u N d N network (with abundant bandwidth) d i u i u i : peer i upload capacity NCSU CSC401 Lina Battestilli

24 File distribution time: client-server server transmission: must sequentially send (upload) N file copies: F u s time to send one copy: F/u s time to send N copies: NF/u s client: each client must download file copy network d i u i d min = min client download rate download time: F/d min time to distribute F to N clients using client-server approach D c-s > max{nf/u s,,f/d min } increases linearly in N NCSU CSC401 Lina Battestilli 34

25 File distribution time: P2P server transmission: must upload at least one copy time to send one copy: F/u s client: each client must download file copy min client download time: F/d min clients: as aggregate must download NF bits max upload rate (limiting max download rate) is u s + Su i F u s network d i u i time to distribute F to N clients using P2P approach D P2P > max{f/u s,,f/d min,,nf/(u s + Su i )} increases linearly in N but so does this, as each peer brings service capacity NCSU CSC401 Lina Battestilli 35

26 Client-Server vs. P2P: example client upload rate = u, F/u = 1 hour, u s = 10u, d min u s Minimum Distribution Time P2P Client-Server N NCSU CSC401 Lina Battestilli 36

27 P2P: BitTorrent and Precursors Napster hybrid P2P (1999) Gnutella (2000) Kazaa (2001) How do you ensure that people contribute? BitTorrent came with some ideas Bram Cohen, a former University at Buffalo graduate student in Computer Science first version in April 2001 NCSU CSC401 Lina Battestilli 37

28 P2P file distribution: BitTorrent file divided into 256Kb-1Mb chunks for good throughput peers in swarm send/receive file chunks Hashes of chunks provide end-to-end integrity (e.g. HBO Rome 2006) tracker: tracks peers participating in torrent swarm: group of peers exchanging chunks of a file Alice arrives obtains list of peers from tracker and begins exchanging file chunks with peers in torrent Possible to blacklist peers NCSU CSC401 Lina Battestilli 38

29 P2P file distribution: BitTorrent Torrent file (joining the swarm) By download torrent file Names tracker File length, pieces length, Shi hashes of pieces Metadata (who created torrent) has no chunks, but will accumulate them over time from other peers registers with tracker to get list of peers, connects to subset of peers ( neighbors ) Trackerless torrents use Distributed Hash Tables (DHTs) Info on swarm stored across many peers A distributed coordination mechanism while downloading, peer uploads chunks to other peers peer may change peers with whom it exchanges chunks churn: peers may come and go once peer has entire file, it may (selfishly) leave or (altruistically) remain in torrent Q: What would be a good strategy? NCSU CSC401 Lina Battestilli 39

30 BitTorrent: requesting file chunks Rarest first At any given time, different peers have different subsets of file chunks Periodically, Alice asks each peer for list of chunks that they have Alice requests missing chunks from peers, rarest first When down to the last few chunks, then ask from multiple peers. NCSU CSC401 Lina Battestilli 40

31 BitTorrent: sending file chunks Tit-for-Tat Most of Alice s peers are choked (do NOT receive chunks from her) Alice orders the peers by download rate and picks P best (usually 4) and unchokes them re-evaluate top 4 every 10 secs every 30 secs: randomly Alice selects another peer, starts sending chunks optimistically unchoke this peer newly chosen peer may join her top 4 NCSU CSC401 Lina Battestilli 41

32 BitTyrent Can you game the BitTorrent Tit-for-Tat system? Many peers give more than they take Give a peer just enough that it unchokes you and keeps you in their top 4 Convince as many peers as possible to unchoke you Share capacity across more peers rather than give each peer more Leads to a 70% median performance gain NCSU CSC401 Lina Battestilli 42

33 References Some of the slides are identical or derived from 1. Slides for the 7 th edition of the book Kurose & Ross, Computer Networking: A Top-Down Approach, 2. Computer Networking, Nick McKeown and Philip Levis, 2014 Stanford University