Virtual Trusted Domain Final Report
Group number: 4
Our project’s goal is to create and manage virtual trusted domains for virtual machines through
the use of a NetFPGA. By doing so, we hope to provide the virtual machines with reliable, secure, and
fast connections to others in their virtual trusted domain.
What is a virtual trusted domain? A virtual trusted domain (VTD) is a collection of virtual
machines, regardless of physical boundaries, that trust one another. What is a NetFPGA? It is a low-cost
platform, primarily designed as a tool for teaching networking hardware and router design. Physically, it
is a PCI card containing a large Xilinx FPGA, which primarily consists of 4 gigabit Ethernet ports, double-
date Rate (DDR2) Dynamic RAM (DRAM), reprogrammable CPCI bus, and NetFPGA packages (NFPs)
containing source code (both for hardware and software).
Our team has researched how to program NetFPGAs and researched and designed an
implementation for Virtual Trusted Domains on a NetFPGA. We have modified the NOX Controller to
manage Virtual Trusted Domains by way of a NetFPGA. We have deployed the program and set up a
test-bed on the NetFPGA. We have completed testing, debugging, and troubleshooting.
o Pre-build NetFPGA server
o Dell Rack Server (Xenserver)
o CentOS 5
o NetFPGA base package
o Openflow Switch
o Nox Controller
For this project, we have completed:
Researching how to program NetFPGAs.
Researching and designing an implementation for Virtual Trusted Domains on a NetFPGA.
Setting up the environment and coding our program which manages Virtual Trusted
Domains on a NetFPGA
Modified the NOX Controller to implement the VTDs.
Deployed the NOX Controller and set up a test bed on the NetFPGA.
Tested and debugged
Final documents completed
Our original idea for implementing this was to have the controller maintain and utilize a database
which contains the list of approved computers, their domain, and security level. The OpenFlow packet
header will be modified to include the user’s trust level and the VTD he wishes to communicate with.
The flow table will maintain good performance by “caching” the controller’s database as needed.
We have implemented this idea by utilizing the VLAN ID of the packet header and placing the
requested domain and the requestor’s trust level in this field. When the NOX Controller receives the
packet, it will check the domain and trust level fields of the sender and determine whether the traffic,
from this sender, should be allowed or not. This could be used, for example, to block inter-domain
communication or prevent an less-secure computer from communicating with a very secure computer
and possibly create a vulnerability.
We have modified the NOX Controller to check for and implement the following fields and rules.
The domain field is used for indicating the domain that a group of VMs belong to. Machines in the same
domain are able to talk with each other while machines cannot talk to other machines in other domains.
The domain field is ten bits wide, so the system can support up to 1024 domains.
The trust level (TL) indicates the trust relationship among different machines in the same
domain. Any machine trying may send data to another machine if it has a greater than or equal TL than
the other machine. Machines with cannot communicate with machines with a greater TL. The trust
level field is two bits wide, so the system can supports up to four trust levels (with four being the highest
trust level and zero being the lowest).
D o m a in F ie ld Tru st Level
1 0 B its 2 B it
We have implemented a proof-of-concept prototype in the Mobicloud by programming these
two fields to be in the VLAN tag. While this set up should not be used in a final implementation (to
maintain standards and for security reasons), this set up was implemented as a solid foundation for
future work. A better solution would be to use MPLS and store the domain and trust level fields in the
two extra MPLS tags (rather than using the VLAN tag). However, the current OpenFlow MPLS switch
software does not support the use of a NetFPGA.
As a result, we chose to implement our solution using the VLAN tag so we could use the regular
OpenFlow switch software (which utilizes the NetFPGA). With this setup we could show that our
implementation works and is capable of providing the necessary features. In addition to this, once the
OpenFlow MPLS switch is released with support for the NetFPGA, the code we have created can be
easily modified to support the new MPLS tags. A programmer can modify a small portion of the code to
check the MPLS1 and MPLS2 tags for the domain and trust fields respectively, rather than looking in the
VLAN tag. All other code and logic could remain the same.
We have successfully designed the VTD concept for a cloud system. We have deployed an
innovative platform using the NOX Controller on top of an OpenFlow Switch on top of a NetFPGA to
provide the features required by the VTD. In addition to this, we have successfully implemented our
solution in an existing cloud system where it can currently be used in a real-world environment. Our
team has a learned a lot during this project and this knowledge will probably be useful later in our