Virtual Trusted Domain

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

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

3. What is NetFPGA? • Low-cost platform, primarily designed as a tool for teaching networking hardware and router design

4. Project Goal • 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. Preliminary Setup PING PC 192.168.1.1 NetFPGA Controller OpenFlow protocol openflow_switch.bit ofdatapath.ko ofdatapath_netfpga.ko controller ofprotocol 192.168.2.1 Kernel / Hardware Userspace

6. Technical Details 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. Research how to program NetFPGAs 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. Research & Design a VTD for NetFPGA 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. Research & Design a VTD for NetFPGA 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. Research & Design a VTD for NetFPGA 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. Flow Table Entry VTD ID & Security Policy

12. Identify different VMs using two labels • 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. Research Path Splicing • 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. Setup Hardware and Begin Coding • We have our computer and programming environment ready to go. • We have installed the MPLS OpenFlow switch.

15. New Tasks • 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. Why MPLS? • 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. Applications 7to5 IP 3 PPP FR ATM (*) Physical (Optical - Electrical) 1 MPLS ISO model TCP UDP 4 MPLS PPP Frame Relay ATM (*) 2

18. Label

19. Components (contd.) • Label Edge Router-LER • Label Switching Router –LSR • Forward Equivalence Class-FEC • Label-Switched Paths -LSPs • Set up an LSP

20. The MPLS Network Architecture

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

22. NetFPGA Preparation (contd.) • 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. Regression Test • 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. OpenFlow MPLS • 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. OpenFlow MPLS • 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. OpenFlow MPLS • 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. OpenFlow MPLS Installation (contd.) • 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. OpenFlow MPLS Installation (contd.) • 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. OpenFlow MPLS Installation (contd.) • 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. Installation Challenges • 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/ProjectTable • 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. OpenFlow MPLS Scenario PING PC Localhost eth0 NetFPGA Controller OpenFlow MPLS openflow_switch.bit ofdatapath.ko ofdatapath_netfpga.ko controller ofprotocol Localhost eth1 Kernel / Hardware Userspace

32. Next Step - Deployment

33. Next Step - Task • 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.

34. Questions?