1 / 75

Internet in a Nutshell: Protocols in Practice

A comprehensive introduction to the protocols used in the Internet, including IP, DNS, ARP, TCP, and HTTP, with a focus on packet-level traces and a day in the life of an Internet host.

rhamlett
Download Presentation

Internet in a Nutshell: Protocols in Practice

An Image/Link below is provided (as is) to download presentation Download Policy: Content on the Website is provided to you AS IS for your information and personal use and may not be sold / licensed / shared on other websites without getting consent from its author. Content is provided to you AS IS for your information and personal use only. Download presentation by click this link. While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server. During download, if you can't get a presentation, the file might be deleted by the publisher.

E N D

Presentation Transcript

  1. Internet in a nutshell (protocols in practice)‏ Introduction 1-1

  2. The gory details first • The Internet from your computer’s view • Packet-level traces of what happens when you access a web page Introduction 1-2

  3. What you need to assume • Every host has a network card with a globally unique, 48-bit hardware address typically expressed as 12 hex digits. • ipconfig /all OR ifconfig –a • This network card = 00-0E-9B-90-1C-50 • Hop-by-hop link layer communication is done via these hardware addresses. • Payload may have an IP packet • You must know the hardware address of the next hop in order to send a packet there • Special hardware broadcast address for discovery Introduction 1-3

  4. What you need to assume • Every host has a unique 32-bit IP address typically expressed as 4 numbers from 0-255 • Portland State = 131.252.x.x • This machine = • Completely decoupled from hardware addresses • Structured like postal addresses. • Every network packet has a source and a destination IP address • Routers collaborate to deliver packets based on their destination IP address • DNS servers collaborate to map names (i.e. www.google.com) to IP addresses (72.14.213.103)‏ Introduction 1-4

  5. A day in the life of an Internet host… • Booting • Dynamically configure network settings • DHCP request (Dynamic Host Configuration Protocol)‏ • UDP (unreliable datagrams)‏ • IP and data-link broadcast • DHCP response from listening server • IP address for host to use • Netmask (i.e. 255.255.255.0) to determine who is directly connected • Default router • Local DNS server Introduction 1-5

  6. A day in the life of an Internet host… • Web request http://www.yahoo.com/index.html • Step #1: Locate DNS server if (DNS server is directly connected) { DNS server on local network ARP for hardware address of IPDNS } else { DNS server on remote network ARP for hardware address of IPDefaultRouter } • ARP (Address Resolution Protocol)‏ • IP address to hardware address mapping • Request broadcast for all hosts on network to see • Reply broadcast for all hosts to cache Introduction 1-6

  7. A day in the life of an Internet host… • Step #2: ARP request and reply Introduction 1-7

  8. A day in the life of an Internet host… • Step #3: DNS request/reply • UDP, IP, data-link header • DNS request to local DNS server from host • DNS reply from local DNS server to host Introduction 1-8

  9. A day in the life of an Internet host… • Step #4: TCP connection establishment • TCP 3-way handshake (SYN, SYN-ACK, ACK)‏ • Session establishment to support reliable byte stream Introduction 1-9

  10. A day in the life of an Internet host… • Step #5: HTTP request and reply • HTTP (application data), TCP, IP, data-link header • HTTP request • HTTP reply Introduction 1-10

  11. Internet applications Introduction 1-11

  12. Application protocols • Language spoken between a client application (i.e. web browser) and a server application (i.e. a web server)‏ • Describes how clients and servers communicate with each other • Defines types of messages exchanged, e.g., request & response messages • Syntax of message types: what fields in messages & how fields are delineated • Semantics of the fields, i.e., meaning of information in fields • Rules for when and how processes send & respond to messages Introduction 1-12

  13. Must choose which transport layer UDP service: • unreliable data transfer between sending and receiving process • does not provide: connection setup, reliability, flow control, congestion control, timing, or bandwidth guarantee TCP service: • connection-oriented: setup required between client and server processes • reliable transport between sending and receiving process • flow control: sender won’t overwhelm receiver • congestion control: throttle sender when network overloaded • does not provide: timing, minimum bandwidth guarantees Introduction 1-13

  14. Internet apps: application, transport protocols Application layer protocol SMTP [RFC 2821] Telnet [RFC 854] HTTP [RFC 2616] FTP [RFC 959] proprietary (e.g. RealNetworks)‏ proprietary (e.g., Vonage,Dialpad)‏ Underlying transport protocol TCP TCP TCP TCP TCP or UDP typically UDP Application e-mail remote terminal access Web file transfer streaming multimedia Internet telephony Introduction 1-14

  15. Web/HTTP Introduction 1-15

  16. Why? Cookies, cross-site scripting, session hijacking, password stealing, etc.

  17. HTTP overview • HTTP: hypertext transfer protocol • Web’s application layer protocol • client/server model • HTTP 1.0: RFC 1945 • http://www.rfc-editor.org/rfc/rfc1945.txt • HTTP 1.1: RFC 2068 • http://www.rfc-editor.org/rfc/rfc2068.txt HTTP request PC running Explorer HTTP response HTTP request Server running Apache Web server HTTP response Mac running Navigator Introduction 1-17

  18. HTTP overview (continued)‏ Uses TCP: • client initiates bi-directional TCP connection (via 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)‏ • Messages encoded in text • TCP connection closed Introduction 1-18

  19. HTTP request message • two types of HTTP messages: request, response • HTTP request message: • ASCII (human-readable format)‏ request line (GET, POST, HEAD commands)‏ 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) header lines Carriage return, line feed indicates end of message http://www.someschool.edu/somedir/page.html Introduction 1-19

  20. HTTP response message status line (protocol status code status phrase)‏ 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 ... header lines data, e.g., requested HTML file Introduction 1-20

  21. User-server state: cookies HTTP initially “stateless” • Didn’t remember users or prior requests Many major Web sites need state • Yahoo mail • Amazon shopping cart HTTP state management (cookies): RFC 2109 • http://www.rfc-editor.org/rfc/rfc2109.txt Introduction 1-21

  22. User-server state: cookies Four components: 1) cookie header line of HTTP response message Set-cookie: 2) cookie header line in HTTP request messageCookie: 3) cookie file kept on user’s host, managed by user’s browser 4) back-end database at Web site Introduction 1-22

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

  24. Cookies (continued)‏ aside Cookies and privacy: • cookies permit sites to learn a lot about you • you may supply name and e-mail to sites • search engines use redirection & cookies to learn yet more • advertising companies obtain info across sites What cookies can bring: • authorization • shopping carts • Site preferences • recommendations • user session state (Web e-mail)‏ Introduction 1-24

  25. DNS Introduction 1-25

  26. Why? DNS-based C&C for botnets, DNS poisoning

  27. Domain Name System (DNS)‏ • Internet hosts, routers like to use fixed-length addresses (numbers)‏ • IP address (32 bit) - used for addressing datagrams • Humans like to use variable-length names • www.cs.pdx.edu • keywords • DNS, keywords, naming protocols • Map names to numbers (IP addresses)‏ Introduction 1-27

  28. Original Name to Address Mapping • Flat namespace • /etc/hosts.txt • SRI kept main copy • Downloaded regularly • Problems • Count of hosts was increasing • From machine per domain to machine per user • Many more downloads of hosts.txt • Many more updates of hosts.txt Introduction 1-28

  29. DNS: Domain Name System (1984)‏ • Distributed database implemented as a hierarchy of many name servers • Goals • Scalability • Decentralized maintenance • Fault-tolerance • Global scope • Names mean the same thing everywhere • Why not centralize DNS? • Not scalable, hard to maintain, single point of failure • http://www.rfc-editor.org/rfc/rfc1034.txt • http://www.rfc-editor.org/rfc/rfc1035.txt Introduction 1-29

  30. DNS: Domain Name System (1984)‏ • Application-layer protocol used by hosts and name servers • communicate to resolve names (address/name translation)‏ • core Internet function, implemented as application-layer protocol • complexity at network’s “edge” • compare to phone network • naming (none supported)‏ • addressing (complex mechanism within network)‏ Introduction 1-30

  31. DNS hierarchical canonical name space root edu com uk net org ca pdx bu mit ucb gwu cs ece www Introduction 1-31

  32. Root DNS Servers org DNS servers edu DNS servers com DNS servers poly.edu DNS servers umass.edu DNS servers pbs.org DNS servers yahoo.com DNS servers amazon.com DNS servers Namespace maps closely to name servers Introduction 1-32

  33. RR format: (name, value, type, ttl)‏ What is stored at these servers? DNS: distributed db storing resource records (RR)‏ • Type=A • name is hostname • value is IP address • Type=CNAME • name is alias name for some “canonical” (the real) name www.ibm.com is really servereast.backup2.ibm.com • value is canonical name • Type=NS • name is domain (e.g. foo.com)‏ • value is hostname of authoritative name server for this domain • Type=MX • value is name of mailserver associated with name Introduction 1-33

  34. Main parts of DNS • Client resolver • Local DNS servers • Root servers • TLD servers • Authoritative servers Introduction 1-34

  35. Client resolver • Code on client to query DNS hierarchy • gethostbyname()‏ • Resolver configuration /etc/nsswitch.conf • Local DNS name servers /etc/resolv.conf • Hand-configured or automatically configured (DHCP)‏ • Host queries local name server for unknown names Introduction 1-35

  36. Local Name Server • Does not strictly belong to hierarchy • Each ISP (residential ISP, company, university) has one. • Also called “default name server” • Specified in /etc/resolv.conf or given by DHCP • When a host makes a DNS query, query is sent to its local DNS server • Acts as a proxy, forwards query into hierarchy. • Typically answer queries about local zone directly • Do a lookup of distant host names for local hosts • Each local DNS server has pointers to root servers • Hard-coded IP addresses in all name server distributions • Currently {a-m}.root-servers.net Introduction 1-36

  37. Root name servers • contacted by local name server that can not resolve name • root name servers • contacts authoritative name server or intermediate name server if name mapping not known • gets mapping and returns it to local name server • 13 root name servers worldwide for fault-tolerance • http://www.root-servers.org a Verisign, Dulles, VA c Cogent, Herndon, VA (also Los Angeles)‏ d U Maryland College Park, MD g US DoD Vienna, VA h ARL Aberdeen, MD j Verisign, ( 11 locations)‏ k RIPE London (also Amsterdam, Frankfurt)‏ i Autonomica, Stockholm (plus 3 other locations)‏ m WIDE Tokyo e NASA Mt View, CA f Internet Software C. Palo Alto, CA (and 17 other locations)‏ b USC-ISI Marina del Rey, CA l ICANN Los Angeles, CA Introduction 1-37

  38. TLD Servers • Top-level domain (TLD) servers: responsible for com, org, net, edu, etc, and all top-level country domains uk, fr, ca, jp. • Network Solutions maintains servers for com TLD • Educause for edu TLD Introduction 1-38

  39. Authoritative Servers • Provides authoritative hostname to IP mappings • Typically, one per organization • Hand mappings out for organization’s servers (Web & mail). • Store parts of the database • Responds to all queries for name it is the authority • Can be maintained by organization or service provider • Example • Authority for .edu is a root server • Authority for pdx.edu is the “.edu” TLD server • Authority for www.pdx.edu is dns0.pdx.edu (131.252.120.128)‏ Introduction 1-39

  40. 2 3 4 5 local DNS server dns.poly.edu 6 7 1 8 DNS query example root DNS server • Host at cis.poly.edu wants IP address for gaia.cs.umass.edu TLD DNS server authoritative DNS server dns.cs.umass.edu requesting host cis.poly.edu gaia.cs.umass.edu Introduction 1-40

  41. Creating your own site • Example: just created startup “Network Utopia” • Register name networkuptopia.com at a registrar (e.g., Network Solutions)‏ • Give registrar names and IP addresses of your authoritative name server • Registrar inserts two RRs into the com TLD server: (networkutopia.com, dns1.networkutopia.com, NS)‏ (dns1.networkutopia.com, 212.212.212.1, A)‏ • Set up authoritative server (212.212.212.1)‏ • Install DNS server (BIND)‏ • Enter A record for www.networkuptopia.com • Enter MX record for networkutopia.com Introduction 1-41

  42. DNS issues • UDP used for queries • Need reliability -> Why not TCP? • No rate control • Centralized caching per site not required • Vulnerability of 13 static root servers • Attacks on root servers have occurred • Jon Postel and his mobility “experiment” • Spoofing identity • Adversary on the same network returning a bogus answer Introduction 1-42

  43. Transport protocols Introduction 1-43

  44. Why? High-speed worm propagation via UDP, TCP session hijacking, TCP spoofed reset, Blind connection spoofing

  45. Transport vs. network layer • network layer: logical communication between hosts • transport layer: logical communication between processes on hosts Introduction 1-45

  46. UDP’s implementation of transport layer functions • Demux to upper layer • UDP port field • Connection setup • none • Delivery semantics • Unordered, mostly unicast (multicast no longer supported)‏ • Unreliable, but data integrity provided by checksum • Security • none • Flow control • none • Congestion control • none Introduction 1-46

  47. UDP: User Datagram Protocol [RFC 768] • “no frills,” “bare bones” Internet transport protocol • “best effort” service, UDP segments may be: • lost • delivered out of order to app • connectionless: • no handshaking between UDP sender, receiver • each UDP segment handled independently of others Why is there a UDP? • no connection establishment (which can add delay)‏ • simple: no connection state at sender, receiver • small segment header • no congestion control: UDP can blast away as fast as desired Introduction 1-47

  48. UDP: more • often used for streaming multimedia apps • loss tolerant • rate sensitive • other UDP uses • DNS • SNMP 32 bits source port # dest port # Length, in bytes of UDP segment, including header checksum length Application data (message)‏ UDP segment format Introduction 1-48

  49. TCP’s implementation of transport layer functions • Demux to upper layer • TCP port field • Connection setup • 3-way handshake • Delivery semantics • In-order byte-stream, unicast • Data integrity provided via 32-bit checksum • Security • None, added later via SSL and TLS • Flow control • Receiver advertised window • Congestion control • Window-based Introduction 1-49

  50. TCP: OverviewRFCs: 793, 1122, 1323, 2018, 2581 • full duplex: • bi-directional data flow in same connection • MSS: maximum segment size • pipelined: • Support high bandwidth • H&H Bagels example • flow and congestion controlled: • control the size of pipe • sender will not overwhelm receiver or network • point-to-point: • one sender, one receiver • connection-oriented: • handshaking to initialize sender/receiver • connection integrity • reliable, in-order byte steam: • Error detection, correction • Duplicate detection • Retransmission Introduction 1-50

More Related