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.
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
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.
- 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.
- 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.
- 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.
- 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.
- 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.
- 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.
- 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.