Do Not Use Mac OS X's Internet Sharing Feature on the Campus Network

Mac OS X (10.2 and later) includes an "Internet Sharing" feature, software intended to let one computer share its Internet connection with other computers. The software is a a combination NAT (Network Address Translator), DHCP server, and Wireless Access Point. The feature is built into the operating system, but is normally turned off.

The software runs on a Mac OS X computer (the "server") that already has an Internet connection (e.g. Ethernet, dial-up modem, or Wireless). It is intended to provide service to other computers (the "clients") that are able to communicate with the server via an Ethernet or Wireless connection.

OIT testing of the version included with Mac OS X 10.2 shows that the program is inappropriate for use on a computer attached to the campus wired network or wireless network. It is also inappropriate for use on a computer within radio range of any wireless service provided by OIT.

OIT testing of versions included with Mac OS X 10.3 through 10.5 is inappropriate for use on a computer attached to the campus wired or wireless network.

Mac OS X 10.2.x

The following information is based upon version 10.2 (i.e. 10.2.0). We did not re-test in later versions of 10.2.x; lacking additional information, we assume they too exhibit the same bugs.

Even when properly configured to only provide service to a private Ethernet or wireless network, the Internet Sharing software can act as a rogue DHCP server on the campus wired or wireless network.

Additionally, it may continue to do so even after the Internet Sharing software is turned off. It may continue to do so even after the network port (e.g. AirPort or Ethernet) it was serving has been "turned off."

Therefore:

• Do not enable this software on any Mac attached to the campus wired or wireless network.

• Do not enable the software on any Mac within radio range of any wireless service provided by OIT (even if the Mac has been configured to generate a private wireless network, the software can operate as a rogue DHCP server on other wireless networks).

  As the radio range of wireless services provided by OIT include much of campus (and continues to grow), there's essentially no place on campus that should be considered "safe enough" for the buggy version of the "Internet Sharing" software.

Mac OS X 10.3.x

The following information is based upon version 10.3.2. We did not examine the feature in 10.3 and 10.3.1. We have not re-tested this in versions of 10.3.x since version 10.3.2.

The device responds erroneously to certain traffic it receives on the interface attached to the campus network (the "uplink"):

• When the uplink receives an IP broadcast packet, and it decides it is not interested in the packet (or that something is wrong with the packet), the device sends an ICMP error message back to the sender. This is not correct behavior; no device should ever send an ICMP error message in response to broadcast or multicast traffic. That's because if devices do so, it can easily create very large traffic spikes (even broadcast storms) on the network.

• When the uplink sees an UDP/IP unicast or broadcast packet destined to a non-local IP destination other than the uplink's IP address, it attempts to forward the packet. This is not correct behavior; it should not try to route the packet at all. By doing so, it contributes to traffic storms on the campus network.

Mac OS X 10.4.x

The following information is based upon version 10.4.1. (We did not examine the feature in 10.4.0.) We have also verified this is still present in version 10.4.7, and is still present in 10.4.10.

The device responds erroneously to certain traffic it receives on the interface attached to the campus network (the "uplink"):

• When the uplink receives an IP broadcast packet, and it decides it is not interested in the packet (or that something is wrong with the packet), the device sends an ICMP error message back to the sender. This is not correct behavior; no device should ever send an ICMP error message in response to broadcast or multicast traffic. That's because if devices do so, it can easily create very large traffic spikes (even broadcast storms) on the network.

• When the uplink sees an UDP/IP unicast or broadcast packet destined to a non-local IP destination other than the uplink's IP address, it attempts to forward the packet. This is not correct behavior; it should not try to route the packet at all. By doing so, it contributes to traffic storms on the campus network.

Mac OS X 10.5.x

The following information is based upon version 10.5.0.

The device responds erroneously to certain traffic it receives on the interface attached to the campus network (the "uplink"):

• When the uplink sees an UDP/IP unicast or broadcast packet destined to a non-local IP destination other than the uplink's IP address, it attempts to forward the packet. This is not correct behavior; it should not try to route the packet at all. By doing so, it contributes to traffic storms on the campus network.