EE122: Potpourri November 24, 2003 Katz, Stoica F04 EECS 122: Introduction to Computer Networks Various Topics Computer Science Division Department of Electrical Engineering and Computer Sciences University of California, Berkeley Berkeley, CA 94720-1776 Katz, Stoica F04 Outline Address Resolution Protocol (ARP) Dynamic Host Configuration Protocol (DHCP) Internet Control Message Protocol (ICMP) Network measurements End-to-end arguments and layering 6/27/2016 7:55 PM Katz, Stoica F04 3 Address Resolution Protocol (ARP) Question: how do packets actually get to their destination? IP routing tables: based on network addresses Ethernet physical interfaces only understand ethernet addresses So, how do packets actually reach their destination? 6/27/2016 7:55 PM Katz, Stoica F04 4 Address Mappings Each host keeps a mapping table: - IP address <-> physical network address When a machine on a physical network wants to reach another host on the same physical network (either first-hop router, or another host), it consults this table How is this table maintained? 6/27/2016 7:55 PM Katz, Stoica F04 5 ARP When the table doesn’t have the required mapping, the host broadcasts a message (to the physical net) asking: who has this IP address? The appropriate host responds with its physical address (and inserts the requester in its table) All others listening who have either host in their table refresh their entries 6/27/2016 7:55 PM Katz, Stoica F04 6 Assumptions in ARP Assumes that physical network can broadcast Not always true: e.g., ATM Must find methods for these networks - (e.g., ATMARP) 6/27/2016 7:55 PM Katz, Stoica F04 7 Host Configuration How does a host know its IP address? Manually configured: - time consuming - doesn’t work for transient hosts Dynamic Host Configuration Protocol (DHCP) - much easier to administer - allows transient hosts to automatically configure themselves 6/27/2016 7:55 PM Katz, Stoica F04 8 DHCP New host broadcasts DHCPDiscover message - Using IP broadcast If DHCP server is local, it responds If no DHCP server is local, there is a DHCP relay agent which forwards DHCPDiscover messages to DHCP server DHCP server gives IP address (and other info) 6/27/2016 7:55 PM Katz, Stoica F04 9 Methods of Address Assignment Have DHCP database that matches MAC address with IP address Freely assign IP addresses from pool 6/27/2016 7:55 PM Katz, Stoica F04 10 Internet Control Message Protocol ICMP provides for a variety of control messages - host unreachable reassembly process failed TTL reached 0 IP header checksum failed ICMP redirect 6/27/2016 7:55 PM Katz, Stoica F04 11 Network Measurement Internet is huge and complex - O(100M) hosts, O(1M) routers, O(10K) networks - Myriad of interacting protocols - Fast pace of change How can we understand what is really going on? Take measurements! 6/27/2016 7:55 PM Katz, Stoica F04 12 What Can We Measure? Structure: topology, link characteristics, etc. Traffic: traffic characteristics, etc. Users and Applications: use of various apps Failures: prevalence of losses, outages, etc. Nefarious behavior: DoS attacks, scans, etc. 6/27/2016 7:55 PM Katz, Stoica F04 13 How Can We Measure? Passive Measurements Active Measurements 6/27/2016 7:55 PM Katz, Stoica F04 14 Passive Measurements Packet traces - tcpdump, etc. - requires physical access to link - lots(!!) of data Flow statistics - cisco’s Netflow Backscatter analysis Honeypots 6/27/2016 7:55 PM Katz, Stoica F04 15 Backscatter Most Denial-of-Service attacks involved randomly chosen forged source addresses The victim typically replies to these packets - they appear to be normal TCP SYNs Thus, the “backscatter” from DoS attacks results in traffic being sent to random hosts If one monitors the traffic to some unoccupied address range, this backscatter can be measured 6/27/2016 7:55 PM Katz, Stoica F04 16 Honeypots Hosts that have no useful purpose - i.e., there is no reason one would contact them for legitimate reasons They monitor all activity, noting the nature of attacks Provide useful data for prevalence and method of attacks 6/27/2016 7:55 PM Katz, Stoica F04 17 Active Measurements Ping: Traceroute: Pathchar (and others): 6/27/2016 7:55 PM Katz, Stoica F04 18 Ping Uses ICMP “echo” feature PING llama.icir.org (192.150.187.22): 56 64 bytes from 192.150.187.22: icmp_seq=0 64 bytes from 192.150.187.22: icmp_seq=1 64 bytes from 192.150.187.22: icmp_seq=2 64 bytes from 192.150.187.22: icmp_seq=3 64 bytes from 192.150.187.22: icmp_seq=4 64 bytes from 192.150.187.22: icmp_seq=5 64 bytes from 192.150.187.22: icmp_seq=6 64 bytes from 192.150.187.22: icmp_seq=7 64 bytes from 192.150.187.22: icmp_seq=8 64 bytes from 192.150.187.22: icmp_seq=9 data bytes ttl=47 time=53.116 ms ttl=47 time=27.444 ms ttl=47 time=26.758 ms ttl=47 time=26.799 ms ttl=47 time=26.092 ms ttl=47 time=25.97 ms ttl=47 time=26.5 ms ttl=47 time=26.309 ms ttl=47 time=26.875 ms ttl=47 time=26.422 ms --- llama.icir.org ping statistics --10 packets transmitted, 10 packets received, 0% packet loss round-trip min/avg/max = 25.97/29.228/53.116 ms 6/27/2016 7:55 PM Katz, Stoica F04 19 Ping Ping can help measure: - delays - loss - reachability 6/27/2016 7:55 PM Katz, Stoica F04 20 Packet Dispersion Techniques Pathchar, etc., try to measure link bandwidth Send two packets back-to-back Delay between them “should” reflect minimal bandwidth along path 6/27/2016 7:55 PM Katz, Stoica F04 21 Traceroute traceroute to llama.icir.org (192.150.187.22), 30 hops max, 40 byte packets 1 adsl-67-114-184-1.dsl.snfc21.pacbell.net (67.114.184.1) 12.002 ms 9.647 ms 9.638 ms 2 dist2-vlan60.snfc21.pbi.net (216.102.187.131) 10.006 ms 9.665 ms 9.773 ms 3 bb1-g8-1.snfc21.pbi.net (216.102.176.193) 10.783 ms 9.944 ms 10.205 ms 4 bb2-p3-0.snfcca.sbcglobal.net (151.164.190.186) 10.17 ms 10.339 ms 10.49 ms 5 ex1-p12-0.pxpaca.sbcglobal.net (216.102.176.234) 11.006 ms 11.29 ms 11.169 ms 6 as4006-cogent.pxpaca.sbcglobal.net (151.164.89.154) 11.452 ms 11.476 ms 11.588 ms 7 p13-0.core02.sfo01.atlas.cogentco.com (154.54.1.253) 11.593 ms 12.538 ms 12.5 ms 8 cenic.demarc.cogentco.com (38.112.6.226) 12.52 ms 11.859 ms 11.975 ms 9 inet-svl-m10.cenic.net (137.164.22.99) 12.359 ms 12.917 ms 12.968 ms 10 inet-ucb--svl-isp.cenic.net (137.164.24.106) 13.904 ms 13.605 ms 14.16 ms 11 vlan193.inr-201-eva.berkeley.edu (128.32.0.74) 14.769 ms 15.161 ms 15.577 ms 12 fast4-0-0.inr-667-eva.berkeley.edu (128.32.0.99) 26.077 ms 25.322 ms 25.013 ms 13 router2-fast0-0-0.icsi.berkeley.edu (169.229.0.30) 23.844 ms 23.844 ms 23.513 ms 14 llama.icir.org (192.150.187.22) 46.369 ms 25.425 ms 24.849 ms 6/27/2016 7:55 PM Katz, Stoica F04 22 Traceroute Use TTL and ICMP 6/27/2016 7:55 PM Katz, Stoica F04 23 Traceroute Can help determine routing behavior - path stability - topology 6/27/2016 7:55 PM Katz, Stoica F04 24 Measurement Surprises Self-similarity traffic structure Power-law topologies 6/27/2016 7:55 PM Katz, Stoica F04 25 Traffic Characteristics Look at traffic on link as function of time, measured over time intervals of size S As S increases, we would expect traffic variations to smooth out Certainly if traffic was Poisson, this would be true 6/27/2016 7:55 PM Katz, Stoica F04 26 Self-Similarity 6/27/2016 7:55 PM Katz, Stoica F04 27 Explanation Flow arrival: Poisson Flow length: heavy-tailed - most flows are very short - but most bytes are in long flows 6/27/2016 7:55 PM Katz, Stoica F04 28 Network Topology Look at network graph (at AS or router level) Consider the “degree distribution” - number of edges connected to each node This degree distribution is heavy-tailed - most nodes have few connections - but a few have very many connections 6/27/2016 7:55 PM Katz, Stoica F04 29 What You Need to Know ARP DHCP ICMP (ttl=0) Measurement tools - ping, traceroute - backscatter, honeypots Review to follow.... 6/27/2016 7:55 PM Katz, Stoica F04 30 Internet Architecture Revisited Many different network styles and technologies - circuit-switched vs packet-switched, etc. - wireless vs wired vs optical, etc. Many different applications - ftp, email, web, P2P, etc. How do we organize this mess? 6/27/2016 7:55 PM Katz, Stoica F04 31 Software Modularity Break system into modules: Well-defined interfaces gives flexibility - can change implementation of modules - can extend functionality of system by adding new modules Interfaces hide information - allows for flexibility - but can hurt performance 6/27/2016 7:55 PM Katz, Stoica F04 32 Network Modularity Like software modularity, but with a twist: Implementation distributed across routers and hosts Must decide both: - how to break system into modules (layering) - where modules are implemented (E2E argument) 6/27/2016 7:55 PM Katz, Stoica F04 33 Layering Layering is a particular form of modularization The system is broken into a vertical hierarchy of logically distinct entities (layers) The service provided by one layer is based solely on the service provided by layer below Rigid structure: easy reuse, performance suffers 6/27/2016 7:55 PM Katz, Stoica F04 34 Who Does What? Seven layers - Lower three layers are implemented everywhere - Next four layers are implemented only at hosts Host A Application Presentation Session Transport Network Datalink Physical Host B Router Network Datalink Physical Physical medium Application Presentation Session Transport Network Datalink Physical 6/27/2016 7:55 PM Katz, Stoica F04 35 Logical Communication Layers interacts with corresponding layer on peer Host A Application Presentation Session Transport Network Datalink Physical Host B Router Network Datalink Physical Physical medium Application Presentation Session Transport Network Datalink Physical 6/27/2016 7:55 PM Katz, Stoica F04 36 Physical Communication Communication goes down to physical network, then to peer, then up to relevant layer Host A Application Presentation Session Transport Network Datalink Physical Host B Router Network Datalink Physical Physical medium Application Presentation Session Transport Network Datalink Physical 6/27/2016 7:55 PM Katz, Stoica F04 37 Encapsulation A layer can use only the service provided by the layer immediate below it Each layer may change and add a header to data packet data data data data data data data data data data data data data data 6/27/2016 7:55 PM Katz, Stoica F04 38 OSI vs. Internet OSI: conceptually define services, interfaces, protocols Internet: provide a successful implementation Application Presentation Session Transport Network Datalink Physical OSI (formal) Application Transport Internet Net access/ Physical Telnet FTP DNS TCP UDP IP LAN Packet radio Internet (informal) 6/27/2016 7:55 PM Katz, Stoica F04 39 Multiple Instantiations Can have several instantiations for each layer - many applications - many network technologies - transport can be reliable (TCP) or not (UDP) Applications dictate transport - In general, higher layers can dictate lower layer But this is a disaster! - applications that can only run certain networks 6/27/2016 7:55 PM Katz, Stoica F04 40 Multiple Instantiations of Layers 6/27/2016 7:55 PM Katz, Stoica F04 41 Solution A universal Internet layer: Internet has only IP at the Internet layer Many options for modules above IP Many options for modules below IP Application Transport Internet Net access/ Physical Telnet FTP DNS TCP UDP IP LAN Packet radio 6/27/2016 7:55 PM Katz, Stoica F04 42 Hourglass 6/27/2016 7:55 PM Katz, Stoica F04 43 Implications of Hourglass A single Internet layer module: Allows all networks to interoperate - all networks technologies that support IP can exchange packets Allows all applications to function on all networks - all applications that can run on IP can use any network Simultaneous developments above and below IP 6/27/2016 7:55 PM Katz, Stoica F04 44 Network Modularity Two crucial decisions Layers, not just modules - alternatives? Single internetworking layer, not multiple - alternatives? 6/27/2016 7:55 PM Katz, Stoica F04 45 Placing Functionality “End-to-End Arguments in System Design” by Saltzer, Reed, and Clark 6/27/2016 7:55 PM Katz, Stoica F04 46 Basic Observation Some applications have end-to-end performance requirements - reliability, security, etc. Implementing these in the network is very hard: - every step along the way must be fail-proof The hosts: - can satisfy the requirement without the network - can’t depend on the network 6/27/2016 7:55 PM Katz, Stoica F04 47 Conclusion Implementing this functionality in the network: Doesn’t reduce host implementation complexity Does increase network complexity Probably imposes delay and overhead on all applications, even if they don’t need functionality However, implementing in network can enhance performance in some cases - very lossy link 6/27/2016 7:55 PM Katz, Stoica F04 48 Conservative Interpretation “Don’t implement a function at the lower levels of the system unless it can be completely implemented at this level” (Peterson and Davie) Unless you can relieve the burden from hosts, then don’t bother 6/27/2016 7:55 PM Katz, Stoica F04 49 Radical Interpretation Don’t implement anything in the network that can be implemented correctly by the hosts - e.g., multicast Make network layer absolutely minimal - ignore performance issues 6/27/2016 7:55 PM Katz, Stoica F04 50 Moderate Interpretation Think twice before implementing functionality in the network If hosts can implement functionality correctly, implement it a lower layer only as a performance enhancement But do so only if it does not impose burden on applications that do not require that functionality 6/27/2016 7:55 PM Katz, Stoica F04 51 Extended Version of E2E Argument Don’t put application semantics in network - Leads to loss of flexibility - Cannot change old applications easily - Cannot introduce new applications easily Normal E2E argument: performance issue - introducing more functionality imposes more overhead - subtle issue, many tough calls (e.g., multicast) Extended version: - short-term performance vs long-term flexibility 6/27/2016 7:55 PM Katz, Stoica F04 52 Reality Layering and E2E Principle regularly violated: - Firewalls - Transparent caches - Other middleboxes Battle between architectural purity and commercial pressures - extremely important - imagine a world where new apps couldn’t emerge 6/27/2016 7:55 PM Katz, Stoica F04 53 Summary Layering is a good way to organize networks Unified Internet layer decouples apps from networks E2E argument encourages us to keep IP simple Commercial realities threaten to undo all of this... 6/27/2016 7:55 PM Katz, Stoica F04 54