VIRTUAL TRUSTED DOMAIN

Garrett DrownTianyi Xing

Group #4

CSE548 – Advanced Computer Network Security

Virtual Trusted Domains

What are Virtual Trusted Domains?

A virtual trusted domain (VTD) is a collection of virtual machines, regardless of physical boundaries, that trust one another.

What is NetFPGA? Low-cost platform, primarily designed as

a tool for teaching networking hardware and router design

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.

Preliminary Setup

PC

PING

OpenFlowprotocol

NetFPGAController

controllerofprotocolopenflow_switch.bit

ofdatapath.koofdatapath_netfpga.ko

UserspaceKernel / Hardware

192.168.1.1

192.168.2.1

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

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.

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.

Research & Design a VTD for NetFPGA

Virtual Trust Domains (VTDs): The core idea is still the same.

A collection of virtual machines, regardless of physical boundaries, that trust one another based on security policies that each utilize.

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.

Flow Table Entry

VTD ID & Security Policy

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.

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.

Setup Hardware and Begin Coding

We have our computer and programming environment ready to go.

We have installed the MPLS OpenFlow switch.

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.

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

MPLS ISO model

PPP

Physical (Optical - Electrical) 1

2

IP 34

Applications7to5

FrameRelay ATM (*)

TCP UDP

PPP FR ATM (*)MPLS

Label

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

The MPLS Network Architecture

NetFPGA Preparation(contd.) Hardware

Pre-build NetFPGA server

SoftwareCentOS 5NetFPGA base package (2.X)

NetFPGA Preparation(contd.) Compile driver and tools Load driver and tools Reboot and verify if the driver is loaded

Module NetFPGA interfaceReprogram the CPCI

Run Selftest

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)

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.

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)

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

OpenFlow MPLS Installation (contd.) Make sure the NetFPGA is working fine

with right version Make the OpenFlow-MPLS kernel

moduleCompile 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*/

OpenFlow MPLS Installation (contd.) Setup the openflow switch with 4 ports

(nf2cX ports) (shell script) Verify the installation

Load the environment variablesRun testing script

○ Check the traffic between OF and controller Run OpenFlow MPLS switch

Download the bit file into the NetFPGA

OpenFlow MPLS Installation (contd.) Run the controller (eigther local or

remote is fine) (ask for the xml file) Run secchan from the secchan drectory Real test or run simulated package

generator Run wireshark to capture the packages

Installation Challenges Compatibility issue

With NetFPGA Different reference package was developed upon

different NetFPGA basepakage version, please carefully refer to http://netfpga.org/foswiki/bin/view/NetFPGA/OneGig/ProjectTable

With Linux KernelConsult to the developer or carefully go through their

wiki

Official guide (wiki) has error/typoI contacted developers and corrected some

errors or typos on wiki (version, command)

OpenFlow MPLS Scenario

PC

PING

OpenFlow MPLSNetFPGA

Controller

controllerofprotocolopenflow_switch.bit

ofdatapath.koofdatapath_netfpga.ko

UserspaceKernel / Hardware

Localhost eth0

Localhost eth1

Next Step Deployment

Questions?