CS261 Homework 3

This problem set is due Thursday, 28 October. Turn in your answers, on paper, at the beginning of class that Thursday. Late homeworks will not be permitted!

You may discuss the questions on this homework with others, but the writeup you turn in must be your own. You may use any source you like (including other papers or textbooks), but if you use any source not discussed in class, you must cite it.

Question 1

This question asks you to explore some of the consequences of active networks, where packets can contain mobile code that is executed by the routers along the path.

For concreteness, we can think of 'adaptive routing' as a sample application: if your TCP connection to France is too slow because of poor bandwidth on the transatlantic link and for some reason you happen to know that there is a much faster route to France via China, you might wish to adaptively update the route your TCP packets take. In this case, you would "push" some mobile code into each router along the way; the mobile code would run at each router before the packet is forwarded and select which interface to send it out over.

We describe below a series of extensions to the IP protocol suite which allows for progressively more sophisticated active networks applications. For each of the extensions below, list the security threats that might arise and how they could be addressed.

1. In the simplest variant, we'd extend the IP packet format to allow an optional extra header which contains some mobile code to run at each router. The mobile code is specified in a very simple bytecode language (much like the Berkeley packet filter). Each router which receives such a packet first verifies that the bytecode contains no backwards loops, and then interprets the bytecode. The only memory locations the bytecodes are allowed to read are (1) the packet itself, and (2) a global list of interfaces available at the router. (No writes to memory are allowed.) There are no function calls, computed gotos, exceptions, or other forms of indirect control flow. Just before exiting, the bytecode should store the name of the desired outbound interface in a fixed register, and the router will use that interface to forward the packet on towards its destination.
2. One obvious performance issue with the previous scheme is that it requires an overhead of potentially hundreds of bytes of code in every packet. So we introduce the notion of "flows" to amortize the cost of specifying the mobile code. Each packet is associated with a flow somehow (for instance, in TCP the flow ID might be the (src host, dst host, src port, dst port) tuple; for other protocols, we might simply extend the packet format to allow for a 32-bit flow ID). We add a "set handler" option which allows endpoints to specify a single chunk of mobile code which will be run at the router every time a packet is received on the same flow. This allows us to specify a chunk of mobile code once; then all subsequent packets in the flow will inherit the same code without incurring any bandwidth overhead.
3. We decide we might like to allow the mobile code to make routing policy decisions based on the payload of the packets. Since this might require scanning the entire packet and possibly interpreting higher-level protocols, we will need to be able to write loops in bytecode. Therefore, we eliminate the restriction on backwards jumps, and allow arbitrary control flow in the bytecode.
4. It occurs to us that it would be neat to have our handler compress packets for us when bandwidth is scarce. But this requires the handler to be able to modify the contents of the packet, so we relax our security policy so that handlers are allowed both read and write access to the packet itself. If the handler modifies the packet during execution, the router will forward the modified packet instead of the original contents.
5. To realize better compression ratios, we relax the security policy so handlers may maintain state across packet reception events. Thus, when a new flow is created, we set aside a chunk of memory for use by that flow's handler; the handler for is allowed read and write access only its own chunk of memory.
6. An astute reader points out that decompression may increase the size of a packet; if this exceeds the network's MTU, our decompression handler may need to send multiple packets. So we allow handlers to construct whole IP packets in their own memory space and invoke a special operation to send that packet over the wire.
7. Users clamor for more features: threads, utility libraries, a better development language, etc. So the protocol is extended to allow handlers to be specified as Java bytecodes instead of BPF bytecodes; the Java bytecodes get executed in a JVM on the router.