CS204 Fall 2005

Group Project

Due: 11:59pm Friday December 16, 2005

I. Summary

The project will be a non-trivial original piece of work, which is produced by a group of 2 or 3 students working as a team. The project could be structured in any of the following ways: 

The end result should be at the level of a decent workshop paper. I will offer several ideas for projects but you are encouraged to find your own topic. Please let me know ASAP when you have chosen a topic so I can offer suggestions on how to proceed before you (attempt to) do all the work.

II. Some Sample Topics

  1. Preventing the problem of MAC address spoofing. In current networking equipment, "flat" MAC addresses are arbitrarily assigned by the manufacturer, without any particular meaning other than to provide a unique identify to each device. Moreover, each MAC address is stored in an external read-only chip rather than built into the actual network controller so the network controllers can be easily mass produced. Thus, it is the responsibility of the device-driver software to insert the proper MAC address in the source address field of every outgoing packet, making it easy for a malicious user to substitute someone else's MAC address to steal services and/or disrupt the network. How can we stop this? Suppose we addes some intelligence to the MAC address by converting it from a "dumb" bit string to a "smart" value consisting of the public key for a cryptographic identity assigned to the device. At the same time, the device would also receive the corresponding private key, with which it can (a) decode any incoming message from another entity that encoded it with this device's public key, or (b) sign any outgoing message to another entity by encoding it with its own private key (allowing anyone to read the message by decoding with the public key). Clearly, a "smart" MAC address could be used in the same way as a "dumb" MAC address, as long as it is unique to each device. However, the "smart" MAC addresses could also be used to prove that a signed message originated from the owner of that MAC address, or to protect data being sent to that device. How would you use such "smart" MAC addresses to improve network security? Think about applications like controlling denial of service attacks or TCP session establishment.
  2. Stream Control Transmission Protocol (SCTP). What is it? Who supports it and why? Compare and contrast its features with existing protocols, including TCP and HTTP, for supporting multimedia, mobility, and security. What layer(s) in the OSI reference model does it occupy? What special handing (if any) is needed at the IP routers along the path(s), or at the end nodes? Explain why you think it will or will not become an important protocol in the future.
  3. Redesigning the addressing structure for the next-generation Internet. Right now, there is considerable interest in developing a "clean sheet" design for replacing the current Internet architecture. One major issue under discussion is how to replace the current IP addressing scheme by something more general and/or easier to use. Rather than having a fixed-length (i.e., 32 bit) IP address for every host, which is shared between a network ID and a host ID in some network-dependent way, the current thinking is to give every host a fixed-length globally-unique identifier (which may as well be its MAC address), and combine it with another fixed-length string to represent the network ID (or more generally, the Autonomous System ID). Each AS can use any routing algorithm it likes for internal traffic, so the external network ID would only be used for "long distance" traffic. Under the current Internet architecture, the Autonomous System ID is a 16-bit number. Since 64K is not a terribly big number by today's standards (i.e., the LAN infrastructure for a large university already supports that many distinct MAC addresses), should we build routing tables for the Internet core routers that include all possible AS numbers? How should such flat routing tables be created? How (and how often) should they be updated?
  4. Investigate a new idea for routing between AS's that is based on concept of the Interstate Highway System. Just as the Internet is collection of AS's connected by border gateways, the national highway system is a collection of state highway systems that are linked together by major highways (and/or bridges, tunnels, ferries, etc) that cross their common borders. When driving across the country, we rarely give directions in the form of a sequence of states to be crossed. Instead, we describe the route as a sequence of Interstate highways, optionally including the name of the cities where we switch from one highway to the next or perhaps the distance to be travelled along each highway. Naming the highways (rather than just the next state) is important, since an east-bound trip starting from southern California along Interstates 8, 10 and 40 all next pass through Arizona as next state, even though the highways take you in very different directions. Moreover, since Arizona is almost cut in half by the Grand Canyon, the proper route to a destination in the northwest corner of Arizona (near St. George UT) must follow Interstate 15 through Nevada before reentering Arizona, rather than going directly from California to Arizona. How should such "Internet highways" be represented in the routing tables? What information should be carried by the packets?
  5. Compare UDP versus TCP performance in congested routers. We say that TCP is responsive to network congestion because a TCP sender will reduce its transmission rate if it thinks there is a congested router along the path to its destination, based on packet losses or other forms of congestion notification by the queue management algorithms. (See topic #5.) Conversely, we say that UDP is unresponsive to congestion because it has no built-in mechanism to detect packet loss and/or react by slowing down. (UDP provides a simple, unreliable datagram service, under the assumption that the application either does not care if some data is lost in transit, or it is smart enough to handle reliability issues by itself.)  Thus, since routers cannot trust UDP flows to slow down when asked, they often treat UDP traffic as deserving of lower-quality service (i.e., greater chances of being dropped, and subject to higher delay). Generate some controlled tests in which you send a mixture of TCP and UDP traffic through a congested path, and see if you can measure the difference in the quality of service received by these two types of traffic.
  6. Memory is so cheap that we can afford to put enough RAM in all routers to hold a complete world-wide IP routing table. How would you use it? Estimate how much memory you would need to construct a complete world-wide IPv4 routing table, which includes a separate entry for every legal 24-bit prefix (i.e., network number). How much would it cost to buy this much RAM, based on current high-end PC component costs? Describe the route lookup algorithm you would design to take full advantage of this global routing table. Most importantly, how can you keep it up-to-date? Find some information about high-end transaction processing systems, such as credit-card verifications systems, to see if routing updates could be handles from a small number of information repositories. Conversely,  find some information about peer-to-peer overlay networks, like Napster, to see whether a hierarchical distributed update scheme would be better able to scale to very large networks.
  7. Find the "missing" network layer. Historically, there used to be network-level functions to find a path across a multihop wired network, or to recover from errors and/or prevent congestion within that network. Today, the network layer has essentially disappeared and IP (which is actually an inter-networking layer) has taken over its position in the OSI reference model. However, these network-layer functions are still needed for certain applications, such as IP mobility, or Quality-of-Service improvements for wireless systems, and hence people have been trying to find ways to modify IP and/or TCP to incorporate these extra features. Look at the history of old network layer protocols from the 1970's and 1980's to see how we handled these problems before. Alternately, look at a modern application where there have been proposals to modify IP and/or TCP to add functionality, and see how this could be done by creating a network layer instead.