Here is a list of potential projects. As people pick up projects, I
shall be creating individual project home pages linked to this page.
Needless to say, more than one group can work on the same project; it
will be interesting to compare results! Also, you are welcome to
suggest your own projects; if you think you have a good project but
would like project partners, post on the class bboard.
Consider an enviroment where users have wireless communications
devices and are worried not only about the privacy of their
communication, but also about disclosing patterns of communication
(i.e.,they want to protect themselves against traffic
analysis). This is particularly worrisome in a wireless environment
because the adversary, along with the obvious software ways of
detecting traffic, can also use radio direction-finding (DF) equipment
and triangulate on individual senders. For example, in a battlefield
situation, the station that is sending most of the traffic is likely
to be the local commander; DF equipment can tell how much traffic is
coming from what geographic location, and the largest source of
traffic can be targetted. The Protocol Enabling an Anonymous
Communications Environment (PEACE for WAR!) allows a set of wireless
nodes to exchange traffic whose origin cannot be traced even by
traffic analysis, using a combination of onion routing and cover
traffic generation.
There is already a 3-person group working on this.
Autonomous System Routing Authority Protocol (ASRAP)
(From the abstract of a recently-submitted (but not yet accepted)
paper:
BGP is essential to the operation of the Internet, but is
vulnerable to both accidental failures and malicious attacks. We
propose a new protocol that works in concert with BGP, which
Autonomous Systems will use to help detect and mitigate accidentally
or maliciously introduced faulty routing information. The protocol
differs from previous efforts at securing BGP in that it is
receiver-driven, meaning that there is a mechanism for recipients of
BGP UPDATE messages to corroborate the information they receive
and to provide feedback. We argue that our new protocol can be
adopted incrementally, and we show that there is incentive for network
operators to do so.
There is interesting work to be done here; actual implementation on
real routing code (e.g.,Zebra), validation of the
claims in the paper through simulation, working out reasonable
configuration templates, and so on.
This is a 2-3 person project, and could also lead to future research.
IOS ↔ DML converter
In most large networks, the real network configuration is to be
found in the actual router configuration files. We would like to be
able to simulate such a
network, e.g., in order to test what would happen if BGP
parameters or OSPF
weights were changed, if new links were added or moved around, where
to home particular customers with high capacity demands. Obviously,
we cannot afford to do the tests on the real network, hence the need
for simulation. Writing the DML files from scratch can be an
extremely tedious and error-prone process. We would like to be able
to take the configuration files from all the routers, along with
specifications of what each router is, and generate the corresponding
DML files.
Conversely, if we already have a set of DML files
(possibly themselves generated from router configurations), we
want to automatically convert them back to the router configurations
so translation errors can be avoided.
This is a 2-3 person project.
Interface SSFNet with Nam
Nam is the Network
Animator; it a Tcl/Tk tool that can be used to animate both
simulations and real-world trace data. It was written primarily to
work with the NS Network
Simulator, but there is no reason that it cannot be used as an
animator for SSFNet. A quick Google search reveals a fair amount of
interest in this.
This is a 2-4 person project.
Generalized Packet Classifier
A packet classifier is a piece of code that takes an incoming or
outgoing packet and decides how to process it. The forwarding code is
an example: it takes an incoming packet, decides if it is for its own
machine; if not, it passes it to the output code, which is
where packets from its own machine go. It will then consult the
forwarding table, and decide what the output interface and next hop
router should be, and send the packet out. Filtering/firewalling code
has packet classifiers of its own, to determine whether packets will
be accepted, rejected, NAT-ed, forwarded to particular proxies, and so
on. IPsec, multicast, tunneling, and so on, all require their own
packet classifiers. I would like to see a single packet classifier in
Unix that can determine all the transforms that need to be applied to
a packet, and then apply them.
This is a programming project for 3-4 people who can do heavy-duty
Unix kernel programming.
Internet-in-a-box
Probably better described as the Internet Holodeck! It's a box that,
when used as your default router, behaves as if an entire network is
behind it. It should respond to traceroutes, pings, connections to
arbitrary (but nonexistent) machines, and simulate link malfunctions
(packet loss/delay/reordering/corruption/duplication). Its simulated
routers should be running various routing protocols, so that faults
can be injected and their effects observed from the edge. Real
machines could also be connected to additional interfaces and
"attached" to various places in the simulated network, so that
software running on them can be studied in the presence of erratic
links. You can also turn this around, and use it as a honeypot.
Niels Provos' Honeyd is a
subset of what this would be.
This is a fairly open-ended project for a 2-3 people, involving both kernel- and user-level programming,
SSFNet programming, and it can grow beyond the scope of a class
project.
"Come-from" tables
Forwarding tables can be viewed as "go-to" tables; given a packet's
destination, figure out where to send it. Forwarding tables are, of
course, populated by first building routing tables obtained through
routing protocols. A "com-from" table would be the opposite: when a
packet arrives at an interface, can we decided (based on routing-like
information that we have built) whether that packet could have indeed
arrived from that interface? The obvious application is a generalized
form of ingress filtering (documented in, among other places, RFC2827, ingress
filtering is what you do at customer routers to make sure that
customers don't send out packets with source addresses outside their
assigned address space). Obviously, this is much harder to do in
transit routers; it is not even clear it can be done in all
cases. There is not much related work on this subject.
This is a 1-2 person research project that should produce
interesting publishable results.
$Id: index.html,v 1.1 2002/10/05 18:59:50 ji Exp ji $