VIEWS: 6 PAGES: 3 POSTED ON: 12/19/2011
Virtual Trusted Domain Final Report Group members: Garrett Drown Tianyi Xing Group number: 4 Project goal 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. Background 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). Project Tasks 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. System Setup Hardware o Pre-build NetFPGA server o Dell Rack Server (Xenserver) Software 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 Idea 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. Our Implementation 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. Conclusion 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 careers.
Pages to are hidden for
"CSE548 Final Report - Final Revision"Please download to view full document