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
192.168.1.1
NetFPGA
OpenFlow
protocol
openflow_switch.bit
ofdatapath.ko
ofdatapath_netfpga.ko
ofprotocol
Controller
controller
192.168.2.1
Kernel / Hardware
Userspace
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
http://snac.eas.asu.edu/snac.html
7
to
5
Applications
TCP
PPP
PPP
UDP
IP
MPLS
Frame
4
3
ATM (*)
ATM (*)
2
Physical (Optical - Electrical)
1
FR
Relay
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
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)
PC
Localhost eth0
NetFPGA
Localhost eth1
openflow_switch.bit
ofdatapath.ko
ofdatapath_netfpga.ko
Kernel / Hardware
OpenFlow MPLS Controller
ofprotocol
controller
Userspace
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.
