Garrett Drown Tianyi Xing Group #4 CSE548 – Advanced Computer Network Security

What are Virtual Trusted Domains? A virtual trusted domain (VTD) is a collection of machines, regardless of physical boundaries, that trust one another.

 Low-cost platform, primarily designed as a tool for teaching networking hardware and router design

 Create and manage virtual trusted domains for virtual machines through the use of a NetFPGA.  Provide the virtual machines with reliable, secure, and fast connections to others in their virtual trusted domain.

PC PING OpenFlow protocol NetFPGA Controller controller ofprotocol openflow_switch.bit ofdatapath.ko ofdatapath_netfpga.ko UserspaceKernel / Hardware

Roadmap of project:  By midterm:  Research how to program NetFPGAs.  Research and design an implementation for Virtual Trusted Domains on a NetFPGA.  Research Path Splicing, which implements similar features that we would like to use in our project.  Setup environment and begin coding our program which creates and manages Virtual Trusted Domains on a NetFPGA  Find and (if time permitting) set up an existing similar solution (if there is one) for VTDs as a basis for our work.  By final:  Modify the existing solution which can or potentially can implement the VTD.  Deploy the program and setup a test-bed on a NetFPGA.  Tested and debugged.  Final documents completed.

NetFPGAs:  Programming will be done in Verilog.  Will be using the Xilinx ISE Design Suite.  The NetFPGA Project primarily consists of open source hardware. As a result, there is a lot of open source hardware available to us that we may use in our project. Still to do:  In depth exploration of the packet handling code.

Virtual Trust Domains (VTDs):  The concept of VTDs is slowly being developed and is not a concrete idea.  Some developers are designing VTDs in such a way that all members must use the same security policies.  Other developers (such as IBM) believe that each computer should have a service which rates the computer’s security level. Based on this result, other computers in the VTD can choose whether or not to trust it.

Virtual Trust Domains (VTDs):  The core idea is still the same. A collection of machines, regardless of physical boundaries, that trust one another based on security policies that each utilize.

Idea so far:  Have the controller maintain and utilize a database which contains the list of approved “members” and other settings (required security policy strength, etc.)  The OpenFlow packet header will be modified to include a user’s security policy and the VTD he wishes to communicate with.  The flow table will maintain good performance by “caching” the controller’s database as needed.

VTD ID & Security Policy

 The label1 is for identifying different domain  The label2 is for identifying different machine in the domain  With this two level identifiers, we can identify the different VMs in different virtual domain.

 The core functionality in path splicing is found in each router which has several routing tables, each with different possible paths.  In the packet header there is an added section for “forwarding bits.” These bits tell the router which routing table to choose.  Similar to our project, as we will be using added bits to our packet headers to represent which VTD the user is in and his security policies.

 We have our computer and programming environment ready to go.  We have installed the MPLS OpenFlow switch.

 Research MPLS (Multiprotocol Label Switching). Used for creating virtual connections between physically distant nodes. Will be used to connect/network distant VTDs together.  Implement and test the MPLS with the OpenFlow MPLS switch on a NetFPGA.

 Delivers high speed L2 (really “Label”) switching at low cost vs. traditional L3 routing  Provides Traffic Engineering - allows the user to direct traffic based on network utilization and demand.  Ease of provisioning QoS  Support for VPNs

PPP Physical (Optical - Electrical)1 2 IP3 4 Applications 7 to 5 Frame Relay ATM (*) TCPUDP PPPFRATM (*) MPLS

 Label Edge Router-LER  Label Switching Router –LSR  Forward Equivalence Class-FEC  Label-Switched Paths -LSPs  Set up an LSP

 Hardware Pre-build NetFPGA server  Software CentOS 5 NetFPGA base package (2.X)

 Compile driver and tools  Load driver and tools  Reboot and verify if the driver is loaded Module NetFPGA interface Reprogram the CPCI  Run Selftest

 The regression test suite is a set of tests that exercise the functionality of the released gateware and software  At least connect 2 interfaces  Load bit file to NetFPGA board  Run regression test (10 Mins)

 Defined actions PUSH: Packet entering MPLS cloud; Merging MPLS FECs into one FEC. POP: Packets leaving MPLS cloud; FEC Demultiplexing SWAP: Changing labels inside MPLS cloud.

 PUSH and POP are not native OpenFlow actions  TTL/TOS operations are very specific to MPLS  Only Swap operation can be done using OpenFlow actions (rewrite action)

 Ericsson have modified the OpenFlow  Match on up to 2 top of the stack MPLS tags.  Rewrite Tag and Exp (in spirit of OF 0.89)  Forward to virtual port to take care of complex MPLS actions

 Make sure the NetFPGA is working fine with right version  Make the OpenFlow-MPLS kernel module Compile the source code (probably have compatibility issue with Linux kernel) Make, make install  Insmod the openflow kernel module and hardware table from datapath/linux-2.6*/

 Setup the OpenFlow switch with 4 ports (nf2cX ports) (shell script)  Verify the installation Load the environment variables Run testing script ○ Check the traffic between OF and controller  Run OpenFlow MPLS switch Download the bit file into the NetFPGA

 Run the controller (either local or remote is fine) (ask for the xml file)  Run secchan from the secchan directory  Real test or run simulated package generator  Run wireshark to capture the packages

 Compatibility issue With NetFPGA Different reference package was developed upon different NetFPGA base package version, please carefully refer to ojectTable ojectTable With Linux Kernel Consult to the developer or carefully go through their wiki  Official guide (wiki) has error/typo I contacted developers and corrected some errors or typos on wiki (version, command)

PC PING OpenFlow MPLS NetFPGA Controller controller ofprotocol openflow_switch.bit ofdatapath.ko ofdatapath_netfpga.ko UserspaceKernel / Hardware Localhost eth0 Localhost eth1

 It is not recommended to deploy the tunnel on the NetFPGA, which makes the system slow.  Find a feasible tunneling implement to be deployed in our system to make different domain into one together.  Deploy the Openflow Switch upon that to build up the MPLS core network.  Implement security policy on the controller to make the domain be with security concern.