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

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

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

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

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

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

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

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

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

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

11. VTD ID & Security Policy

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

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

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

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

16.  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 http://snac.eas.asu.edu/snac.html

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

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

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

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

23.  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)

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

25.  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)

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

27.  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*/

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

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

30.  Compatibility issue With NetFPGA Different reference package was developed upon different NetFPGA base package version, please carefully refer to http://netfpga.org/foswiki/bin/view/NetFPGA/OneGig/Pr ojectTable http://netfpga.org/foswiki/bin/view/NetFPGA/OneGig/Pr 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)

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

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