Project 3a is out! Goal: implement a basic network firewall. Due: Nov noon. l We give you the VM & framework. l You implement the firewall logic.

Transcription

1 Project 3a is out! Goal: implement a basic network firewall l We give you the VM & framework. l You implement the firewall logic. Due: Nov noon 1

2 What Is Firewall? Blocks malicious traffic Blocks unauthorized traffic 2

3 VM Linux TCP/IP network stack ext firewall int

4 VM Linux TCP/IP network stack ext firewall int 1. Decode the packet 2. Check the firewall rules 3. Pass or drop the packet

5 Packets on wire look like this 5 and your firewall should decode this.

6 Firewall rules Type 1: a combination of l Protocol (TCP/UDP/ICMP) l IP address or country (e.g., Canada) l Port number Type 2: domain names l E.g., block DNS queries for *.facebook.com 6

7 NO CHEATING WE RUN COPY CHECKER 7

8 Questions? l General questions l Ask your favorite GSI l Project-specific questions l Chang Lan (main) l Shoumik Palkar l Sangjin Han l Start Early! 8

9 Today l Router- assisted Conges0on Control (wrap up) l Applica0on layer: DNS

10 Router- Assisted Conges3on Control l Recall: Three tasks for CC: l Fairness l Rate adjustment l Detec0ng conges0on

11 Router- Assisted Conges3on Control l Recall: Three tasks for CC: l Fairness à e.g., Fair Queuing l Rate adjustment à e.g., Rate Control Protocol l Detec0ng conges0on à e.g., ECN

12 Fairness: General Approach l Routers classify packets into flows l Assume for now flows ~ TCP connections l Each flow has its own FIFO queue in router l Router services flows in a fair fashion

13 Max-Min Fairness l Given set of bandwidth demands r i and total bandwidth C, max-min bandwidth allocations are: a i = min(f, r i ) where f is the unique value such that Sum(a i ) = C r 1 r 2? C bits/s?? r 3 l This is what round-robin service gives if all packets are the same size

14 Fair Queuing is how we deal with packets of different sizes l Mental model: Bit-by-bit round robin l For each packet, compute its deadline l deadline à the time at which the last bit of a packet would have left the router if flows are served bit-by-bit l Transmit packets in increasing order of deadlines

15 Example Flow 1 (arrival traffic) time Flow 2 (arrival traffic) time Bit-wise round-robin time FQ time

16 Exercise Flow A (arrival traffic) Flow B (arrival traffic) A1 A2 A3 A4 B1 B2 time time Flow C (arrival traffic) C1 C2 time What s the packet order at the output for four scheduling disciplines? FIFO Round-Robin Fair Queuing Priority Assume Flow A > B > C in priority and for breaking ties

17 Router- Assisted Conges3on Control l Recall: Three tasks for CC: l Fairness à e.g., Fair Queuing l Rate adjustment à e.g., Rate Control Protocol l Detec0ng conges0on à e.g., ECN

18 Idea: Let routers tell endhosts what rate they should use l Packets carry rate field l Routers insert fair share f in packet header l End-hosts set sending rate (or window size) to f l Note: still assumes end-hosts play by the rules l This is the basic idea behind the Rate Control Protocol (RCP) from Dukkipati&McKeown in 2007

19 Flow Completion Time: TCP vs. RCP (Ignore XCP) Flow Duration (secs) vs. Flow Size RCP 19

20 Why the improvement?

21 Why is RCP important? l Congestion control had long focused on safety (primary) and fairness (secondary) l TCP does a good enough job at both l RCP highlighted CC s impact on performance l performance matters a lot in today s environment l RCP shows we can do better but is still fairly complex and not incrementally deployable

22 RC3 Mittal et al., 2014 l RC3: Recursively Cautious Congestion Control l Senders transmit at max rate from the get-go l But packets are marked with priorities l CWND packets are sent at priority#1 l The remaining at low priority l Routers implement priority scheduling (exists today) l If no congestion, all packets get through (high performance) l else, low priority packets dropped (safety and fairness)

23 Router- Assisted Conges3on Control l Recall: Three tasks for CC: l Fairness à e.g., Fair Queuing l Rate adjustment à e.g., Rate Control Protocol l Detec0ng conges0on à e.g., ECN

24 Explicit Congestion Notification (ECN) l Single bit in packet header; set by congested routers l l Many options for when routers set the bit Tradeoff between (link) utilization and (packet) delay l Receiver relays ECN bit in its ACK to the sender l l Congestion semantics can be exactly like that of drop e.g., endhost reacts as though it saw a drop l Advantages: l l l l Don t confuse corruption with congestion Serves as an early indicator of congestion to avoid delays Easy (easier) to incrementally deploy Today: defined in RFC 3168 using ToS/DSCP bits in the IP header

25 A final proposal: Charge people for congestion! l Use ECN as congestion markers l Whenever I get an ECN bit set, I have to pay $$ l Now, there s no debate over what a flow is, or what fair is l Idea started by Frank Kelly at Cambridge l l l optimal solution, backed by much math Great idea: simple, elegant, effective Unclear that it will impact practice

26 Recap! l TCP l allows apps to assume reliable bytestream delivery l with (mostly) fair and safe sharing of network resources l Congestion control 1. avoid overloading the network to the point of collapse 2. while sharing resources fairly 3. and maximizing performance l TCP does a good enough job at the first two but the last is more iffy

27 Taking Stock l Course so far l Concepts (links, delays, switches) l Overall architecture (layers, protocols, principles) l Network layer (how we interconnect hosts and networks) l Transport layer (how we make best-effort usable to apps) l What s left? l Application layer (DNS, HTTP) ß this week l Lower layers (Ethernet, Wireless) ß next l Advanced topics (datacenters, SDN, IPv6) ß last ~2 weeks

28 Some very special guest lectures l Nov 10: Yahel Ben-David (Wireless) l Nov 19: Stephen Strowes (IPv6) l Nov 24: Scott Shenker (SDN) l Dec 1: Panel: Careers in networking (tentative)

29 Application Layer l Domain Name System (DNS) l What s behind (e.g.) instr.eecs.berkeley.edu? l HTTP and the Web l What happens when you click on a link?

30 Host Names & Addresses l Host addresses: e.g., l a number used by protocols l conforms to network structure (the where ) l Host names: e.g., instr.eecs.berkeley.edu l mnemonic name usable by humans l conforms to organizational structure (the who ) l The Domain Name System (DNS) is how we map from one to the other l a directory service for hosts on the Internet

31 Why bother? l Convenience l Easier to remember than l Provides a level of indirection! l Decoupled names from addresses l Many uses beyond just naming a specific host

32 DNS: Early days l Mappings stored in a hosts.txt file (in /etc/hosts) l l maintained by the Stanford Research Institute (SRI) new versions periodically copied from SRI (via FTP) l As the Internet grew this system broke down l l l SRI couldn t handle the load conflicts in selecting names hosts had inaccurate copies of hosts.txt l The Domain Name System (DNS) was invented to fix this l First name server implementation done by 4 UCB students!

33 Goals? l Scalable l many names l many updates l many users creating names l many users looking up names l Highly available l Correct l no naming conflicts (uniqueness) l consistency l Lookups are fast

34 How? l Partition the namespace l Distribute administration of each partition l Autonomy to update my own (machines ) names l Don t have to track everybody s updates l Distribute name resolution for each partition l How should we partition things?

35 Key idea: hierarchical distribution Three intertwined hierarchies l Hierarchical namespace l As opposed to original flat namespace l Hierarchically administered l As opposed to centralized administrator l Hierarchy of servers l As opposed to centralized storage

36 Hierarchical Namespace root edu com gov mil org net uk fr berkeley eecs sims instr ucla l Top Level Domains are at the top l Domains are subtrees l E.g:.edu, berkeley.edu, eecs.berkeley.edu l Name is leaf-to-root path l instr.eecs.berkeley.edu l Name collisions trivially avoided! l each domain s responsibility

37 Hierarchical Administration ICANN/IANA root edu com gov mil org net uk fr berkeley ucla eecs sims instr A zone corresponds to an administrative authority responsible for a contiguous portion of the hierarchy E.g.: UCB controls *.berkeley.edu and *.sims.berkeley.edu while EECS controls *.eecs.berkeley.edu

38 Server Hierarchy l Top of hierarchy: Root servers l Location hardwired into other servers l Next Level: Top-level domain (TLD) servers l.com,.edu, etc. l Managed professionally l Bottom Level: Authoritative DNS servers l Actually store the name-to-address mapping l Maintained by the corresponding administrative authority

39 Server Hierarchy l Every server knows the address of the root name server l Root servers know the address of all TLD servers l l An authoritative DNS server stores name-to-address mappings ( resource records ) for all DNS names in the domain that it has authority for à Each server stores a subset of the total DNS database à Each server can discover the server(s) responsible for any portion of the hierarchy

40 DNS Root l Located in Virginia, USA Verisign, Dulles, VA

41 DNS Root Servers l 13 root servers (labeled A-M; see A Verisign, Dulles, VA C Cogent, Herndon, VA D U Maryland College Park, MD G US DoD Vienna, VA H ARL Aberdeen, MD J Verisign K RIPE London I Autonomica, Stockholm E NASA Mt View, CA F Internet Software Consortium Palo Alto, CA M WIDE Tokyo B USC-ISI Marina del Rey, CA L ICANN Los Angeles, CA

42 DNS Root Servers l 13 root servers (labeled A-M; see l Replicated via any-casting E NASA Mt View, CA F Internet Software Consortium, Palo Alto, CA (and 37 other locations) A Verisign, Dulles, VA C Cogent, Herndon, VA (also Los Angeles, NY, Chicago) D U Maryland College Park, MD G US DoD Vienna, VA H ARL Aberdeen, MD J Verisign (21 locations) K RIPE London (plus 16 other locations) I Autonomica, Stockholm (plus 29 other locations) M WIDE Tokyo plus Seoul, Paris, San Francisco B USC-ISI Marina del Rey, CA L ICANN Los Angeles, CA

43 Anycast in a nutshell l Routing finds shortest paths to destination l What happens if multiple machines advertise the same address? l The network will deliver the packet to the closest machine with that address l This is called anycast l Very robust l Requires no modification to routing algorithms

44 DNS Records l DNS servers store resource records (RRs) l RR is (name, value, type, TTL) l Type = A: (à Address) l name = hostname l value = IP address l Type = NS: (à Name Server) l name = domain l value = name of dns server for domain

45 DNS Records (cont d) l Type = MX: (à Mail exchanger) l name = domain in address l value = name(s) of mail server(s)

46 Inser3ng Resource Records into DNS l Example: you just created company FooBar l You get a block of IP addresses from your ISP l say /25 l Register foobar.com at registrar (e.g., Go Daddy) l Provide registrar with names and IP addresses of your authorita0ve name server(s) l Registrar inserts RR pairs into the.com TLD server: l (foobar.com, dns1.foobar.com, NS) l (dns1.foobar.com, , A) l Store resource records in your server dns1.foobar.com l e.g., type A record for l e.g., type MX record for foobar.com

47 Using DNS (Client/App View) l Two components l Local DNS servers l Resolver sozware on hosts l Local DNS server ( default name server ) l Clients configured with the default server s address or learn it via a host configura0on protocol (e.g., DHCP future lecture) l Client applica0on l Obtain DNS name (e.g., from URL) l Triggers DNS request to its local DNS server

48 local DNS server (mydns.berkeley.edu) root servers.edu servers DNS client (me.cs.berkeley.edu) nyu.edu servers 48

49 local DNS server (mydns.berkeley.edu) root servers.edu servers DNS client (me.cs.berkeley.edu) nyu.edu servers 49

50 root DNS server DNS server (mydns.berkeley.edu).edu servers DNS client (me.cs.berkeley.edu) nyu.edu servers 50

51 root DNS server DNS server (mydns.berkeley.edu).edu servers DNS client (me.cs.berkeley.edu) nyu.edu servers 51

52 recursive DNS query root DNS server DNS server (mydns.berkeley.edu).edu servers DNS client (me.cs.berkeley.edu) nyu.edu servers 52

53 root DNS server DNS server (mydns.berkeley.edu).edu servers DNS client (me.cs.berkeley.edu) nyu.edu servers 53

54 itera0ve DNS query root DNS server DNS server (mydns.berkeley.edu).edu servers DNS client (me.cs.berkeley.edu) nyu.edu servers

55 DNS Protocol l Query and Reply messages; both with the same message format l see text/section for details l Client-Server interaction on UDP Port 53 l Spec supports TCP too, but not always implemented

56 Goals how are we doing? l Scalable l many names l many updates l many users creating names l many users looking up names l Highly available

57 Per-domain availability l DNS servers are replicated l Primary and secondary name servers required l Name service available if at least one replica is up l Queries can be load-balanced between replicas l Try alternate servers on timeout l Exponential backoff when retrying same server

58 Goals how are we doing? l Scalable l many names l many updates l many users creating names l many users looking up names l Highly available l Correct l no naming conflicts (uniqueness) l consistency l Lookups are fast

59 root DNS server local DNS server.edu TLD DNS server DNS client nyu.edu DNS server 59

60 Caching l Caching of DNS responses at all levels l Reduces load at all levels l Reduces delay experienced by DNS client

61 DNS Caching l How DNS caching works l DNS servers cache responses to queries l Responses include a 0me to live (TTL) field l Server deletes cached entry azer TTL expires l Why caching is effec0ve l The top- level servers very rarely change l Popular sites visited ozen à local DNS server ozen has the informa0on cached

62 Nega3ve Caching l Remember things that don t work l Misspellings like and l These can take a long 0me to fail the first 0me l Good to remember that they don t work l so the failure takes less 0me the next 0me around l Nega0ve caching is op0onal

63 How can one amack DNS? 63

64 root DNS server local DNS server.edu TLD DNS server Persa (the impersonator) DNS client nyu.edu DNS server 64

65 How can one amack DNS? l Impersonate the local DNS server give the wrong IP address to the DNS client

66 root DNS server local DNS server.edu TLD DNS server DNS client Denis (the epfl.ch denial- of- service DNS agacker) server 66

67 How can one amack DNS? l Impersonate the local DNS server give the wrong IP address to the DNS client l Denial- of- service the root or TLD servers make them unavailable to the rest of the world

68 root DNS server local DNS server.edu TLD DNS server Casha DNS client nyu.edu DNS server 68

69 How can one amack DNS? l Impersonate the local DNS server give the wrong IP address to the DNS client l Denial- of- service the root or TLD servers make them unavailable to the rest of the world l Poison the cache of a DNS server increase the delay experienced by DNS clients

70 Important Proper3es of DNS Administra0ve delega0on and hierarchy results in: l Easy unique naming l Fate sharing for network failures l Reasonable trust model l Caching lends scalability, performance

71 DNS provides Indirec3on l Addresses can change underneath l l Move to a new IP address Humans/apps are unaffected l Name could map to mul0ple IP addresses l Enables load- balancing l Mul0ple names for the same address l E.g., many services (mail, www, Zp) on same machine l Allowing host names to evolve into service names

72 Next Lecture (ScoM Shenker lecturing) l HTTP and the Web l (Broadcast) Ethernet