1. W4140 Network Laboratory Lecture 9 Nov 12 - Fall 2006 Shlomo Hershkop Columbia University

2. Announcements  Reminder : phase I project due end of week  Lab 7 this week

3. Outline  Network Address Translation (NAT)  Dynamic Host Configuration Protocol (DHCP)  Firewalls  Typical Application and some news of a recent hacking (very sophisticated) on the cs network Or: what you learned this semester in real life

4.  A hack to fix the IP address depletion problem. NAT is a router function where IP addresses (and possibly port numbers) of IP datagrams are replaced at the boundary of a private network.  Breaks the End-to-End argument. But it became a standard: RFC 1631 - The IP Network Address Translator (NAT)  Provides a form security by acting as a firewall home users. Small companies. Network Address Translation: a hack Is there any other solution to the IP address problem?

5. Basic operation of NAT  NAT device stores the address and port translation tables In the this example we mapped only addresses. Host private address: 10.0.1.2 public address: 128.143.71.21 Public Host Private NetworkInternet 64.236.24.4 NAT Device Private Address Public Address 10.0.1.1128.59.16.21 Source = 10.0.1.2 Destination = 64.236.24.4 Source = 10.0.1.2 Destination = 64.236.24.4 Source = 128.143.71.21 Destination = 64.236.24.4 Source = 128.143.71.21 Destination = 64.236.24.4 Source = 64.236.24.4 Destination= 128.59.16.21 Source = 64.236.24.4 Destination= 10.0.0.2 Source = 64.236.24.4 Destination= 128.59.16.21 Source = 64.236.24.4 Destination= 128.59.16.21 Source = 64.236.24.4 Destination= 128.59.16.21 Source = 64.236.24.4 Destination= 10.0.0.2

6. Private Network  Private IP network is an IP network with Private IP Addresses (Can it be connected directly to the Internet?)  IP addresses in a private network can be assigned arbitrarily but they are usually picked from the reserved pool (can we use any?) Not registered and not guaranteed to be globally unique Question: how is public IP address assigned?  Generally, private networks use addresses from the following experimental address ranges (non-routable addresses): 10.0.0.0 – 10.255.255.255 172.16.0.0 – 172.31.255.255 192.168.0.0 – 192.168.255.255

7. Main uses of NAT  Pooling of IP addresses  Supporting migration between network service providers  IP masquerading and internal firewall  Load balancing of servers

8. Pooling of IP addresses  Scenario: Corporate network has many hosts but only a small number of public IP addresses.  NAT solution: Corporate network is managed with a private address space. NAT device, located at the boundary between the corporate network and the public Internet, manages a pool of public IP addresses. When a host from the corporate network sends an IP datagram to a host in the public Internet, the NAT device picks a public IP address from the address pool, and binds this address to the private address of the host.

9. Pooling of IP addresses Host private address: 10.0.1.2 public address: 128.143.71.21 Private NetworkInternet NAT Device Private Address Public Address 10.0.1.2128.59.16.21 Source = 10.0.1.2 Destination = 64.236.24.4 Source = 10.0.1.2 Destination = 64.236.24.4 Source = 128.143.71.21 Destination = 64.236.24.4 Source = 128.143.71.21 Destination = 64.236.24.4

10. Supporting migration between network service providers  Scenario: In practice (using CIDR), the IP addresses in a corporate network are obtained from the service provider. Changing the service provider requires changing all IP addresses in the network.  NAT solution: Assign private addresses to the hosts of the corporate network NAT device has address translation entries which bind the private address of a host to the public address. Migration to a new network service provider merely requires an update of the NAT device. The migration is not noticeable to the hosts on the network.

11. Supporting migration between network service providers

13. IP masquerading  Also called: Network address and port translation (NAPT), port address translation (PAT).  Scenario: Single public IP address is mapped to multiple hosts in a private network.  NAT solution: Assign private addresses to the hosts of the corporate network NAT device modifies the port numbers for outgoing traffic

14. IP masquerading

15. Load balancing of servers  Scenario: Balance the load on a set of identical servers, which are accessible from a single IP address  NAT solution: Here, the servers are assigned private addresses NAT device acts as a proxy for requests to the server from the public network The NAT device changes the destination IP address of arriving packets to one of the private addresses for a server A sensible strategy for balancing the load of the servers is to assign the addresses of the servers in a round-robin fashion.

16. Load balancing of servers

17. Concerns about NAT  Performance: Modifying the IP header by changing the IP address requires that NAT boxes recalculate the IP header checksum. Modifying port number requires that NAT boxes recalculate TCP checksum.  Fragmentation Care must be taken that a datagram that is fragmented before it reaches the NAT device, is not assigned a different IP address or different port numbers for each of the fragments.

18. Concerns about NAT  End-to-end connectivity: NAT destroys universal end-to-end reachability of hosts on the Internet. A host in the public Internet often cannot initiate communication to a host in a private network. The problem is worse, when two hosts that are in a private network need to communicate with each other. Example: bittorrent, where each client is also a server….

19. NAT and FTP  Normal FTP operation

20. NAT and FTP  NAT device with FTP support

21. NAT and FTP  FTP in passive mode and NAT.

22. Configuring NAT in Linux  Linux uses the Netfilter/iptable Kernel package

23. Configuring NAT with iptable  First example: iptables –t nat –A POSTROUTING –s 10.0.1.2 –j SNAT --to-source 128.16.71.21  Pooling of IP addresses: iptables –t nat –A POSTROUTING –s 10.0.1.0/24 –j SNAT --to-source 128.16.71.0–128.16.71.30  IP masquerading: iptables –t nat –A POSTROUTING –s 10.0.1.0/24 –o eth1 –j MASQUERADE  Load balancing: iptables -t nat -A PREROUTING -i eth1 -j DNAT --to- destination 10.0.1.2-10.0.1.4

24. Dynamic Host Configuration Protocol (DHCP)

25. Dynamic Assignment of IP addresses  Dynamic assignment of IP addresses is desirable for several reasons: IP addresses are assigned on-demand Avoid manual IP configuration Support mobility of laptops Wireless networking and Home NATs  No static IP means that we have to depend on DNS for the packet routing Use of a DDNS (Dynamic DNS entry) Free sites for that service in the internet

26. Dynamic Host Configuration Protocol (DHCP)  Designed in 1993  Requires a server and free IP address space  Supports temporary allocation (“leases”) of IP addresses  DHCP client can acquire all IP configuration parameters  Any potential security risks?  Can we use something that can prevent unauthorized users?

27. DHCP Interaction (simplified)

28. DHCP Message Format (There are >100 different options)

29. DHCP  OpCode: 1 (Request), 2(Reply) Note: DHCP message type is sent in an option  Hardware Type: 1 (for Ethernet)  Hardware address length: 6 (for Ethernet)  Hop count: set to 0 by client  Transaction ID: Integer (used to match reply to response)  Seconds: number of seconds since the client started to boot  Client IP address, Your IP address, server IP address, Gateway IP address, client hardware address, server host name, boot file name: client fills in the information that it has, leaves rest blank

30. DHCP Message Type  Message type is sent as an option. ValueMessage Type 1DHCPDISCOVER 2DHCPOFFER 3DHCPREQUEST 4DHCPDECLINE 5DHCPACK 6DHCPNAK 7DHCPRELEASE 8DHCPINFORM

31. DHCP operations Src: 0.0.0.0, 68 Dest: 255.255.255.255, 67 DHCPDISCOVERY Yiaddr: 0.0.0.0 Transaction ID: 654 Src:128.195.31.1, 67 DHCPOFFER Yiaddr: 128.59.20.147 Transaction ID: 654 Dest: 255.255.255.255, 68 Lifetime: 3600 secs Server ID: 128.59.18.1

32. Src: 0.0.0.0, 68 Dest: 255.255.255.255, 67 DHCPREQUEST Yiaddr: 128.59.20.147 Transaction ID: 655 server ID: 128.195.31.1 Lifetime: 3600 secs Src:128.59.18.1, 67 DHCPACK Yiaddr: 128.59.20.147 Transaction ID: 655 Dest: 255.255.255.255, 68 Lifetime: 3600 secs Server ID: 128.59.18.1 DHCP operations

33. More on DHCP operations  A client may receive DCHP offers from multiple servers  The DHCPREQUEST message accepts offers from one server.  Other servers who receive this message considers it as a decline  A client can use its address after receiving DHCPACK  DHCP replies can be unicast, depending on implementation

34. DHCP relay agent DHCPDISCOVER Giaddr: 0 Src: 0.0.0.0., 68 Dest: 255.255.255.255, 67 128.16.31.1 128.16.41.1 DHCPDISCOVER Giaddr: 128.16.41.1 Src: 0.0.0.0., 68 Dest: 255.255.255.255, 67 DHCPOFFER …… Giaddr: 128.16.41.1 Src: 128.16.31.10, 67 Dest: 128.16.41.1, 67 DHCPOFFER …… Giaddr: 128.16.41.1 Src: 128.16.41.1, 67 Dest: 255.255.255.255, 68 128.16.31.10

35. History of DHCP  Three Protocols: RARP (until 1985, no longer used) BOOTP (1985-1993) DHCP (since 1993) Secure DHCP – not a standard yet…  Only DHCP is widely used today.

36. Solutions for dynamic assignment of IP addresses  Reverse Address Resolution Protocol (RARP) RARP is no longer used Works similar to ARP Broadcast a request for the IP address associated with a given MAC address RARP server responds with an IP address Only assigns IP address (not the default router and subnetmask)

37. BOOTP  BOOTstrap Protocol (BOOTP)  Host can configure its IP parameters at boot time.  3 services.  IP address assignment.  Detection of the IP address for a serving machine.  The name of a file to be loaded and executed by the client machine (boot file name) Not only assigns IP address, but also default router, network mask, etc. Sent as UDP messages (UDP Port 67 (server) and 68 (host)) Use limited broadcast address (255.255.255.255):  These addresses are never forwarded

38. BOOTP Interaction  BOOTP can be used for downloading memory image for diskless workstations  Assignment of IP addresses to hosts is static (a) (b) (c)

39. Lab errata  In Figure 7.1, the private network interface of Router2 should be labeled with IP address "10.0.1.1/24" (instead of 10.0.0.1/24).

40. Firewalls

41.  Security solution to control data connections Some permitted Some denied Some proxy  Hardware based  Software based

42. Simplest version  Software based – personal Windows machine  Zone alarm  Application level control  Network level control  Can configure regards to host-host, group Linux type  iptables  TCP wrappers  Specific application level control

43. Next level  Dedicated hard based firewall At network gateway Between control zones

44. State of connection  Stateful firewall Keep track of where the connection is, and knowing the underlying protocol will allow/deny connection  Very expensive  Stateless firewall Each packet is treated in isolation of every other Very cheap  Example ftp opens up random port connections to pass information, which will drop the packets ?

45. Interesting application firewall  Anyone hear of port knocking ??  This isn’t a trick or treat thing

46. Rules of firewalls  Most firewalls work on hard coded rules Interface (sometimes) presents choices to users/admins File keeps track of the rules  Probabilistic Approaches: Anomaly detection firewalls learn from normal traffic what should be allowed and what should be blocked

47. This course  So what is the advantage of this course Hands on networking Get to break things (and not get fired) Get to play with some theoretical tools (educational only) Understand the problem with the following stories:

48. CS network 1  Problem: Guest: Dhcp machines on the cs network were mysteriously failing to establish network connection Any ideas ??

49. CS network 2  Really bad hacking success  Throw out hacker  Arp attack in revenge

50.  Back to BGP

51. BGP = RFC 1771 + “optional” extensions RFC 1997 (communities) RFC 2439 (damping) RFC 2796 (reflection) RFC3065 (confederation) … + routing policy configuration languages (vendor-specific) + Current Best Practices in management of Interdomain Routing BGP was not DESIGNED. It EVOLVED. The Border Gateway Protocol (BGP)

52. BGP Route Processing Best Route Selection Apply Import Policies Best Route Table Apply Export Policies Install forwarding Entries for best Routes. Receive BGP Updates Best Routes Transmit BGP Updates Apply Policy = filter routes & tweak attributes Based on Attribute Values IP Forwarding Table Apply Policy = filter routes & tweak attributes Open ended programming. Constrained only by vendor configuration language

53. AS7018 135.207.0.0/16 AS Path = 6341 AS 1239 Sprint AS 1755 Ebon e AT&T AS 3549 Global Crossing 135.207.0.0/16 AS Path = 7018 6341 135.207.0.0/16 AS Path = 3549 7018 6341 AS 6341 135.207.0.0/16 AT&T Research Prefix Originated AS 12654 RIPE NCC RIS project AS 1129 Global Access 135.207.0.0/16 AS Path = 7018 6341 135.207.0.0/16 AS Path = 1239 7018 6341 135.207.0.0/16 AS Path = 1755 1239 7018 6341 135.207.0.0/16 AS Path = 1129 1755 1239 7018 6341 ASPATH Attribute

54. In fairness: could you do this “right” and still scale? Exporting internal state would dramatically increase global instability and amount of routing state AS 4 AS 3 AS 2 AS 1 Mr. BGP says that path 4 1 is better than path 3 2 1 Duh! Shorter Doesn’t Always Mean Shorter

55. Thanks to Han Zheng Routing Example 1

56. Thanks to Han Zheng Routing Example 2

57. Tweak Tweak Tweak (TE)  For inbound traffic Filter outbound routes Tweak attributes on outbound routes in the hope of influencing your neighbor’s best route selection  For outbound traffic Filter inbound routes Tweak attributes on inbound routes to influence best route selection outbound routes inbound routes inbound traffic outbound traffic In general, an AS has more control over outbound traffic

58. Forces outbound traffic to take primary link, unless link is down. AS 1 primary link backup link Set Local Pref = 100 for all routes from AS 1 AS 65000 Set Local Pref = 50 for all routes from AS 1 Backup Links with Local Preference (Outbound Traffic)

59. Forces outbound traffic to take primary link, unless link is down. AS 1 primary link backup link Set Local Pref = 100 for all routes from AS 1 AS 2 Set Local Pref = 50 for all routes from AS 3 AS 3 provider Multihomed Backups (Outbound Traffic)

60. Prepending will (usually) force inbound traffic from AS 1 to take primary link AS 1 192.0.2.0/24 ASPATH = 2 2 2 customer AS 2 provider 192.0.2.0/24 backupprimary 192.0.2.0/24 ASPATH = 2 Yes, this is a Glorious Hack … Shedding Inbound Traffic with ASPATH Prepending

61. AS 1 192.0.2.0/24 ASPATH = 2 2 2 2 2 2 2 2 2 2 2 2 2 customer AS 2 provider 192.0.2.0/24 ASPATH = 2 AS 3 provider AS 3 will send traffic on “backup” link because it prefers customer routes and local preference is considered before ASPATH length! Padding in this way is often used as a form of load balancing backupprimary … But Padding Does Not Always Work

62. AS 1 customer AS 2 provider 192.0.2.0/24 ASPATH = 2 AS 3 provider backupprimary 192.0.2.0/24 ASPATH = 2 COMMUNITY = 3:70 Customer import policy at AS 3: If 3:90 in COMMUNITY then set local preference to 90 If 3:80 in COMMUNITY then set local preference to 80 If 3:70 in COMMUNITY then set local preference to 70 AS 3: normal customer local pref is 100, peer local pref is 90 COMMUNITY Attribute to the Rescue!

63. BGP Issues - What is a BGP Wedgie?  BGP policies make sense locally  Interaction of local policies allows multiple stable routings  Some routings are consistent with intended policies, and some are not If an unintended routing is installed (BGP is “wedged”), then manual intervention is needed to change to an intended routing  When an unintended routing is installed, no single group of network operators has enough knowledge to debug the problem ¾ wedgie Full wedgie

64. ¾ Wedgie Example  AS 1 implements backup link by sending AS 2 a “depref me” community.  AS 2 implements this community so that the resulting local pref is below that of routes from it’s upstream provider (AS 3 routes) AS 1 AS 2 AS 3AS 4 customer provider peer provider customer provider backup link primary link

65. And the Routings are… AS 1 AS 2 AS 3AS 4 Intended Routing AS 1 AS 2 AS 3AS 4 Unintended Routing Note: This is easy to reach from the intended routing just by “bouncing” the BGP session on the primary link. Note: this would be the ONLY routing if AS2 translated its “depref me” community to a “depref me” community of AS 3

66. Recovery AS 1 AS 2 AS 3AS 4 AS 1 AS 2 AS 3AS 4 AS 1 AS 2 AS 3AS 4 Bring down AS 1-2 sessionBring it back up!  Requires manual intervention  Can be done in AS 1 or AS 2

67. Load Balancing Example primary link for prefix P1 backup link for prefix P2 AS 1 AS 2 AS 3AS 4 provider peer provider customer AS 5 customer primary link for prefix P2 backup link for prefix P1  Recovery for prefix P1 may cause a BGP wedgie for prefix P2 …

68. AS 1 AS 2 AS 3AS 4 customer provider peer provider customer provider primary link Full Wedgie Example AS 5 backup links  AS 1 implements backup links by sending AS 2 and AS 3 a “depref me” communities.  AS 2 implements its community so that the resulting local pref is below that of its upstream providers and it’s peers (AS 3 and AS 5 routes)  AS 5 implements its community so that the resulting local pref is below its peers (AS 2) but above that of its providers (AS 3) customer peer

69. And the Routings are… AS 1 AS 2 AS 3AS 4 AS 5 AS 1 AS 2 AS 3AS 4 AS 5 Intended Routing Unintended Routing

70. Recovery?? AS 1 AS 2 AS 3AS 4 AS 5 AS 1 AS 2 AS 3AS 4 AS 5 Bring down AS 1-2 session Bring up AS 1-2 session

71. Recovery AS 1 AS 2 AS 3AS 4 AS 5 AS 1 AS 2 AS 3AS 4 AS 5 Bring down AS 1-2 session AND AS 1-5 session AS 1 AS 2 AS 3AS 4 AS 5 Try telling AS 5 that it has to reset a BGP session that is not associated with a BEST route! Bring up AS 1-2 session AND AS 1-5 session

72. A Global ISP (or Corporate Intranet) Implemented with 5 ASes AU++ AP EMEA LA NA

73. AU EMEA NAAP Full Wedgie Example, in a new Guise LA Intended Routing for some prefixes in AU Message: Same problems can arise with “traffic engineering” across domains.

74. Recommendations  Be aware of BGP Wedgies  Interdomain communities that can tweak a route’s preference should be defined with care and consistently implemented  Tools to enumerate all stable routings would be useful inherently exponential in theory, but may not be that bad in practice (on instances much smaller than global Internet!) I’m currently attempting an implementation on top of http://nms.lcs.mit.edu/bgp/rcc/

75. Dynamic Routing Protocols: Summary  Dynamic routing protocols: RIP, OSPF, BGP  RIP uses distance vector algorithm, and converges slow (the count-to-infinity problem)  OSPF uses link state algorithm, and converges fast. But it is more complicated than RIP.  Both RIP and OSPF finds lowest-cost path.  BGP uses path vector algorithm, and its path selection algorithm is complicated, and is influenced by policies.  BGP has its own problems see WIDGI by Tim GriffinWIDGI by Tim Griffin

76. More Readings (Optional)  BGP Wedgies: Bad Routing Policy Interactions that Cannot be Debugged BGP Wedgies  JI’s Intro to interdomain routing.Intro to interdomain routing  "Interdomain Setting of PlanetLab Nodes." PlanetLab Meeting, May 14, 2004. "Interdomain Setting of PlanetLab Nodes."  Understanding the Border Gateway Protocol (BGP) Understanding the Border Gateway Protocol (BGP) ICNP 2002 Tutorial Session

77. References  [VGE1996, VGE2000] Persistent Route Oscillations in Inter-Domain Routing. Kannan Varadhan, Ramesh Govindan, and Deborah Estrin. Computer Networks, Jan. 2000. (Also USC Tech Report, Feb. 1996)  [GW1999] An Analysis of BGP Convergence Properties. Timothy G. Griffin, Gordon Wilfong. SIGCOMM 1999  [GSW1999] Policy Disputes in Path Vector Protocols. Timothy G. Griffin, F. Bruce Shepherd, Gordon Wilfong. ICNP 1999  [GW2001] A Safe Path Vector Protocol. Timothy G. Griffin, Gordon Wilfong. INFOCOM 2001  [GR2000] Stable Internet Routing without Global Coordination. Lixin Gao, Jennifer Rexford. SIGMETRICS 2000  [GGR2001] Inherently safe backup routing with BGP. Lixin Gao, Timothy G. Griffin, Jennifer Rexford. INFOCOM 2001 – [GW2002a] On the Correctness of IBGP Configurations. Griffin and Wilfong.SIGCOMM 2002. – [GW2002b] An Analysis of the MED oscillation Problem. Griffin and Wilfong. ICNP 2002.

78.  Lab 6 this week  Goal: