Source Address Validation Solution with

OpenFlow/NOX Architecture

Guang Yao, Jun Bi and Peiyao Xiao

Network Research Center

Tsinghua University

Beijing, China

{yaog@netarchlab., junbi@, xiaopy@netarchlab.}tsinghua.edu.cn

Abstract—Current Internet is lack of validation on source IP

address, resulting in many security threats. The future Internet

can face the similar routing locator spoofing problem without

careful design. The current in-progress source address validation

standard, i.e., SAVI, is not of enough protection due to the

solution space constraint. In this article, a mechanism named

VAVE is proposed to improve the SAVI solutions. VAVE

employs OpenFlow protocol, which provides the de facto

standard network innovation interface, to solve source address

validation problem with a global view. Significant improvements

can be found from our evaluation results.

Keywords- OpenFlow; IP source address validation

I. INTRODUCTION

A. IP/Locator Spoofing

IP address is the de facto locator of current Internet. However, existing Internet routing system was designed without considering the validity of source IP address, and this flaw makes attacks with forged source address possible [6]. A long list of notorious attacks relying on IP spoofing can be enumerated: SYN flooding [7], Smurf [8], DNS amplification [9], etc. Besides such attacks relying on using forged source addresses to amplify attacking ability, using forged IP source address can also take down protocols and applications in which source IP address is used as the identifier for upper layer, e.g., TCP. Attackers can also use forged source address to hide their real locations, and even offload the blame to others. Though this security threat has been recognized from about twenty years, it is not well solved. Indeed, we can find a lot of traces on attacks using IP spoofing attack from the captured packets from network telescopes every day, even actually only a small fraction of such attacks can be caught be network telescopes [10].

As locator/identifier separation can provide explicit benefits [11], there can be a standalone locator for future Internet, and similar locator spoofing can still exist. If the locator is unspoofable, the identifier can be dynamically bound on locator to prevent identifier spoofing. Otherwise, identifier authentication requires cryptography process on each packet, which can lead to considerable overhead and is vulnerable to

Denial of Services (DoS) attack.

B. SAVI and Limitations of SAVI

To solve IP spoofing problem, we believe the best way is to standardize source address validation mechanism to encourage vendors to adopt it in routing devices. The best example is ingress filtering [1], which has been deployed in about 70% Autonomous Systems (ASs) [12]. Though ingress filtering can provide aggregate level source address validation, a mechanism of finer granularity is required for a lot of reasons, e.g., traceback and accounting.

In recent years, IETF SAVI (Source Address Validation Improvements) group [13] has taken a lot of efforts to standardize the mechanisms validating source address on access device, i.e., SAVI device. SAVI devices validate the source address of packet based on a binding-validation model. However, due to the restriction that no new protocol should be introduced, the considered solutions are with a number of limitations. One of the most serious limitations is the protection of SAVI is not good enough. Binding information cannot be exchanged between SAVI devices based on existing protocols. As a result, SAVI devices work separately and a host attached to a SAVI device can be attacked by spoofing traffic with source addresses bound on another SAVI device. This drawback seriously discourages deployment.

On the other hand, adopting no new protocol is essential for a mechanism to work immediately, because it takes a long time from the proposal of a new protocol until the adoption of the protocol on most commercial products. Thus, a solution is required to resolve the conflict between fast delivery of a mechanism and its protection ability.

C. Considerations on a Solution with the OpenFlow/NOX

Architecture

For it is not quite possible to solve the protection limitation problem in current Internet, we turned to find whether it is possible to solve this problem in new architectures. There have been a number of researches on making evolution in the Internet easier. Among them, OpenFlow [3] is one of the most promising solutions. OpenFlow provides the interface to control flow level traffic on router/switch that supports OpenFlow protocol. And NOX [2], which implements the controller for OpenFlow switches, provides necessary components and interfaces to make extensions easy to implement. Such architecture shifts the complexity of adopting a new protocol from the router/switch to the controller, and

This work is supported by National Science Foundation of China under Grant 61073172, Program for New Century Excellent Talents in University,

Specialized Research Fund for the Doctoral Program of Higher Education of

China under Grant 20090002110026,and National Basic Research Program ("973" Program) of China under Grant 2009CB320501.

2011 19th IEEE International Conference on Network Protocols

978-1-4577-1393-4/11/$26.00 ©2011 IEEE 7

makes it much easier to take an evolution. With the adoption of OpenFlow in router/switch, evolutions based on OpenFlow can be adopted much easier. OpenFlow devices have been deployed in a number of campus networks.

D. Proposed Solution: VAVE

In this article, instead of proposing another solution with current Internet, we propose a solution named by Virtual source Address Validation Edge (VAVE) with the OpenFlow/NOX architecture. With no new protocol on switches introduced, the NOX controller determines the validation rules on each SAVI devices from a global view.

VAVE has following unique features compared with other mechanisms:

1. Agility: Current solutions require perpetual resource on

routers to accommodate filters, and source address

validation overhead is generated on each packet, even if

there is no spoofing at all. In contrast, VAVE can provide

on-demand filtering to avoid resource occupation and

packet process overhead in peacetime, and reduce them in

attacks.

2. Quick and light response to route change: Current

mechanisms use protocol to distribute change in

forwarding choice, and the filtering table of each router

must be re-calculated after each change. Because the

propagation and re-calculation require some time, a part

of legitimate traffic will be filtered before the re-

calculation is finished. This problem can be even worse if

the route changes frequently. In VAVE, flow table state

on switches can be tightly tracked by NOX server, thus

corresponding change on filtering rules can be made

much faster. What’s better, because filters are not always

configured on routers, there is generally no need to

update switch configuration to adopt new filters, and

legitimate traffic will not be filtered at all.

3. Data plane overhead cap: In current mechanisms, a

packet is checked on the all the devices enabled filtering

on its path. However, for route based filtering, among all

the routers with filtering ability on the path, the first

router has the best filtering capability. The succeeded

routers cannot identify a spoofing packet that is not

distinguished by the first router. Thus, checking the

packet on the succeeded routers is actually unnecessary.

In VAVE, a perimeter is formed by OpenFlow devices.

Packet originated from the outside of the perimeter is

checked only when it reaches the perimeter. In this way,

no packet is checked more than once.

The remaining sections of this article are organized as follows. First we introduce the proposed VAVE mechanism. Simulation based evaluation result is given afterwards, and an implementation based on NOX is introduced. Then we summarize related works. At last we conclude our contributions.

II. VAVE SOLUTION

A. Overview

As presented in Fig. 1., we use OpenFlow devices to form a protective perimeter, which is also named by Virtual source Address Validation Edge (VAVE). Whenever a packet originated from outside of the perimeter reaches the perimeter, if it is not matched by any entry in the flow table of the device, the first packet will be redirected to the NOX controller. A VAVE application of the NOX controller, checks whether the source of the packet is valid or not based on generated rules. If the packet is found to use forged source, a flow table entry, which covers the spoofing flow, will be configured on the corresponding router to cut the spoofing flow. The entry will be removed by the router if there is no packet matching this entry for a period.

In VAVE, an OpenFlow device has 3 types of interfaces:

attached by host, attached by another OpenFlow device, and attached by a legacy device. For interfaces attached by host, the validation rule is generated based on SAVI mechanisms. For interfaces attached to another OpenFlow device, no rule is needed because the incoming traffic must have been validated by the attached OpenFlow device. VAVE only focus on the interfaces attached to legacy device. Such interfaces are named by VAVE interface. If each OpenFlow device works separately, spoofing traffic with address set to address bound on other

OpenFlow

Device

OpenFlow

Device

Legacy

Device

SAVI based Validation SAVI based Validation

No

Validation

VAVE

VAVE

Interface

Figure 2. Three types of interfaces on OpenFlow

device

Filter Adapter

NOX

Validation Module

Spoofing Flow

(S=A,D= F)

Hit Filtering Rule

VAVE

First Packet

Filter Generator

OP A OP B

OP C OP D OP E

OP F OP G

LD

LD

LD LD LD

LD

LD

VAVEApp

Flow Path (A, F)

OP

OpenFlow device

LD

Legacy device

Figure 1. The Architecture of VAVE

8

SAVI device can arrive at SAVI host through the VAVE interface.

The mechanism is contained in the OpenFlow/NOX architecture, with three additional modules: filtering rule generator, validation module and rule adaptor. These modules are introduced separately in the following sections.

B. Filtering Rule Generator

1) Validation Principle It is not quite possible to enumerate the legal address space

on VAVE interfaces without knowing the state of the other part of the network. However, it is an impossible task to track the state of the whole Internet. Instead, we try to find the illegal address space on VAVE interface based on known flow paths between OpenFlow devices. The path of a part of flows is contained in the perimeter of VAVE. Thus if one of such flows is found arriving the perimeter from the outside, it must be a spoofing flow. Briefly, the filtering principle is simply denying flows which should be contained in the perimeter on VAVE interfaces.

As illustrated in Fig. 1., the path of flow ( , )A F is found

to be contained in the perimeter. Thus, if a packet with source

A and destination F is received on VAVE interface of F , the packet must be a spoofing packet.

To make this mechanism effective, at least there must be one flow whose forwarding path from its origin to its destination is completely contained in the perimeter. Ideally, if the routing of the area in the perimeter is convex, which means path whose source and destination are both in the perimeter is entirely contained in the perimeter, all the flows between OpenFlow devices can be protected from being forged by outside attackers. In special case, if there is only one VAVE interface, the VAVE area must be convex because there should be no loop in routing.

2) Flow Path Calculation To determine the whole path of a flow, the location of the

origin and destination of the flow must be got known. Therefore, the addresses which are located in the perimeter must be discovered first. The addresses of attached hosts can be learned from ARP/NDP protocol (i.e., host detection component of NOX). The validity of the address can be authenticated based on the principled proposed in SAVI, e.g., First-Come-First-Served, or control packet snooping. Denote

the set of all the addresses by A . Then the set containing all

the flows whose path should be calculated is2A .

OpenFlow devices make use of flow table to determine the action on each flow. The flow table is configured by the controller. Thus, the controller can get the state of the flow table on each OpenFlow device. On each OpenFlow device, the forwarding interface of a flow can be known from the flow table, and then the next hop of the flow can be got known from

discovered topology. Then, for each flow f in2A , the path of

f can be determined through track the flow table from its

origin until its destination.

3) Re-Calculation on Flow Path Change

Flow path is not static, and path re-calculation is required whenever flow path changes. Thus, if the controller intends to modify the flow table on OpenFlow devices, or there is data path change event announced by OpenFlow devices, flow path should be re-calculated. However, the flow path will not be re-calculated immediately. Instead, a flag will be set and flow paths calculated only when spoofing event happens. This feature is designed for networks with frequent route change.

If there are some filtering rules configured when the flow path changes, these rules will be removed immediately to avoid discarding legitimate traffic. New filtering rules will be configured gradually, as specified in section 2.4.

C. Validation Module This module determines whether a packet is spoofing or

not. After the calculation of flow path, the filtering rule is simply denying incoming flow whose path in entirely in the perimeter on VAVE interface. The filtering rule set is uniform for all VAVE interfaces. Only one copy of the rule set is needed to be kept on NOX server.

The source and destination addresses of packet redirected from VAVE interface will be looked up in the rule set. Because the redirected packets can be of a certain number, the look-up procedure must be fast enough. Thus, we store the rule set in a hash table.

If a redirected packet is matched in the rule set, the controller will check whether the route change flag is set. If no flag has been set, the controller will call the rule adaptor to configure a filtering rule. Else, an entry will be configured to let pass the flow first, and flow paths will be re-calculated. The packet will be checked on new rule set. If the packet is not matched, a rule will be set to let pass the flow.

D. Rule Adaptor

This module configures rule onto the OpenFlow device through interface supplied by NOX.

If the rule to configure is to allow some flow, the rule will be simply configured on the corresponding VAVE interface. However, the legitimate space of flow is quite large, and it can be impossible to configure all the flows on OpenFlow devices. In this situation, a minimal coverage flow space is configured on OpenFlow device, and only flows in this space will be processed by VAVE function. The addresses out of the space should be checked by the aggregate device. For example, if the

prefix of a link is P , then the minimal coverage flow space is2P . Only flow in

2P is processed by VAVE.

However, to deny a spoofing flow, the procedure is somewhat tricky. It is generally not wise to only deny the match flow, because the attacker may send packets with various source addresses. On the other hand, it is neither wise to configure the whole rule set all in one considering the configuration delay and huge resource requirement. Instead, we choose to configure the hit rule, i.e., the rule covers the largest flow space and the spoofing flow in the space of filtering rules, as presented in Fig. 3.. Such a strategy is found to be effective against spoofing with specified source, brute force search source and random source in simulation.

9

The structure of flow tables on OpenFlow devices with

VAVE interface is specified in Fig. 4. Rules will be configured into the first flow table of OpenFlow device. Spoofing traffic will be dropped directly, and legitimate traffic from VAVE interface will be processed by the next flow table. An idle timeout is set with each entry of these two types, which requires the OpenFlow device to delete the corresponding entry after the entry is inactive from a time. Unrecognized packet from VAVE interface in the minimal coverage flow space will be sent to the controller and processed by the validation module. Packet from other types of interfaces will be processed by the next flow table. The table is configured to continue packet process in case of miss match, in order to process flows out of the minimal coverage flow space correctly.

E. Scalability Considerations

Mechanisms with central controllers face a similar scalability problem: with the growth of deployment area, the processing capability of the controller will become the bottleneck of the mechanism. Because such a problem exists in all the solutions with OpenFlow/Controller architecture, there have been some solutions [4] [5] proposed for the scalability

problem. In case there are multiple controllers assigned to multiple perimeters, the information of flows inside each perimeter can be exchanged between controllers, and a controller can treat flows inside other perimeters as flows that shouldn’t appear on perimeter it manages.

About VAVE alone, the scalability problem is mitigated by the perimeter. Though there can be a lot of interfaces inside the perimeter that should be managed by the controller, only VAVE interface is required to be managed by the VAVE component on controller. There is no need to manage inter-connect interfaces between OpenFlow switches, which are generally accounted for a greater proportion of all the interfaces.

F. Security Considerations DDoS attacks can be launched to flood the link between the

controller and the network so as to prevent the controller from processing flows. To prevent such attack, the controller should be placed inside the perimeter, and flows to the controller should be cut on managed interfaces if they are not from OpenFlow devices. In this way, the controller can be protected from flooding attack.

Besides DDoS, a tricky attack can be launched against the controller. Attackers can send a large number of packets with random sources to trigger OpenFlow devices to redirect a lot of packets to the controller and thus take down the controller. However, such an attack is not as powerful as it seems. In general IPv4 address allocation practice, addresses of adjacent hosts can be aggregated well. As a result, the number of rules required to cover all the flows are less than the address pairs, and thus less than the spoofing packet sent. For IPv6, the addresses are generally too sparse for an attacker to find most of them. Besides, because the duplicate sources will be generated by random strategy and such packet will be discarded directly, the attack is found even not as effective as a brute force attack in our simulation.

III. EVALUATION AND RESULTS

We present a part of evaluation results of VAVE with an inferred topology (RF3755) from Rocketfuel project [14] through simulation. For we don’t have knowledge of the routing and addressing of the network, we use randomly assigned addresses and Shortest Path First algorithm to generate the flow table on each device.

The performance of VAVE depends on the deployment strategy. Minimal vertex coverage strategy is chosen to generate the set of nodes in VAVE perimeter. There can exist multiple perimeters.

A. Increased Protectiveness

VAVE is proposed to improve the protectiveness of SAVI devices, especially, to prevent attacker from using addresses bound on SAVI devices to send packet to SAVI host. In another words, VAVE is used to prevent SAVI-SAVI flow from being spoofed.

1

1

1 1 1

1 1 1 1

1 1 1

1

1

Source(X)

De

stina

tion

(Y)

X000 X001 X010 X011 X100 X101 X110 X111

Y000Y001Y010Y011Y100Y101Y110Y111

HitRule: Deny (X11/P-1,Y01/P-1)

Spoofing Flow

Figure 3. The hit rule to cut a spoofing flow

Table0

Table1

Table2

TableN...

VAVE Table Other functions

· Matched DROP from VAVE: DROP· Matched GOTO from VAVE: GOTO table 1

· Matched by P ╳ P from VAVE: Output to Controller· From other interfaces: GOTO table 1· Miss: Continue

OpenFlow Device

Figure 4. The structure of flow tables

10

The ratio of unspoofable SAVI-SAVI flows to all the flows in the network is given in Fig. 5. The deployment ratio is the devices inside to perimeter over all the devices in the network. Compared with SAVI which cannot prevent a SAVI-SAVI flow been spoofed by attacker attaching to legacy device until fully deployed, VAVE can effect effectively protect such flows from be forged with partial deployment.

VAVE doesn’t filter spoofing traffic with source outside the perimeter for two reasons: 1. Traffic with source address outside the whole OpenFlow network can be filtered effectively through performing ingress filtering at the upstream router. If requiring VAVE to build binding entries for addresses outside the network, it will be a big problem for devices to load the huge number of entries. 2. It is generally not necessary to enforce a fully host granularity source address validation in the whole network. VAVE is proposed to protect the important addresses that shouldn’t be forged, e.g., the addresses of servers and routers. If fully host granularity validation is required, the better solution is enabling SAVI on all the devices in the network.

B. Evaluation on Agility

Agility is a distinctive feature of VAVE compared with other mechanisms. In practice, this feature is quite important. The same as other distributed IP spoofing filtering mechanisms, the rule number on one device can be huge. However, the flow table entry number on one OpenFlow device is quite limited. There can be not enough resource to hold all the entries, or at least the process speed of the device will be degraded seriously.

We evaluate the benefits of agility feature from two aspects: (1) packet process cost; (2) Resource requirement on device.

We use weighted average checked times on each flow to measure the packet process cost. If the validation function on one interface is always configured, packet passing through the interface will always be checked. However, if validation rule is only configured whenever spoofing is detected, the checked time will be reduced in peace time. Fig. 6(a) shows the simulation result with a deployment ratio of 50%. From the diagram, it can be found that whenever the ratio of attackers is less than 10%, the average checked times on flows by VAVE is quite small. We also give the simulation result on a mechanism which checks packet on all the devices enabled filtering. The advantage of VAVE against such a mechanism is obvious.

Fig. 6(b) show the ratio of deployed rule to the whole rule

set with the trial times of attack under brute force search and random search (only for rule set on the perimeter). In this simulation, an attacker is required to traverse almost the whole space of flow to make the VAVE configured all the rules. If the attacker uses random sources to launch attack, though it is more effective at the beginning, after a period the attack effect will be below the effect of brute force attack. This result shows the VAVE can greatly reduce resource requirement on devices.

IV. IMPLEMENTATION

A prototype has been implemented based on NOX. Minor modification is made on the existing NOX component to store the configured flow table entries which are required by VAVE. VAVE is implemented as a network application working with other existing components, e.g., routing component, host detection component and topology discovery component. The implementation is tested with OpenFlowVMS. The whole project has only hundreds lines of Python code. As a comparison, a similar mechanism is implemented with commodity routers by 30k lines of C++ code. Most of the codes are used to handle: 1, the outer-sync problem between device and controller; 2, different CLI syntaxes of devices from different vendors. This great contrast support that OpenFlow is a promising technique to help network evolve.

We also evaluate the delay introduced by VAVE to the flow setup procedure based on the implementation. The delay depends on the flows inside the perimeter. The result is given in Figure 7. The experiment is performed on a PC with 2.66

Figure 5. The ratio of unspoofable SAVI-SAVI flow

0.0 0.2 0.4 0.6 0.8 1.0-0.1

0.0

0.1

0.2

0.3

0.4

0.5

0.6

0.7

0.8

0.9

1.0

1.1

Ratio o

f U

nspoofa

ble

SA

VI-

SA

VI

Flo

w

Deployment Ratio

VAVE

SAVI

Figure 6. (a) Weighted average checked times on flows

(b) Ratio of deployed rules to whole rule set

0.01 0.1 1

0.0

0.5

1.0

1.5

2.0

2.5

VAVE

SAVI

Checking on all the devices enabled filtering

We

igh

ted

Ave

rag

e C

he

cke

d T

imes o

n F

low

s

Ratio of Attackers to All the Hosts(a)

0 10000 20000 30000 40000 50000 60000 70000

0.0

0.1

0.2

0.3

0.4

0.5

0.6

0.7

0.8

0.9

1.0

VAVE (brute force attack)

VAVE (random attack)

Static configuration

Attacking flow countRatio o

f D

eplo

yed R

ule

s to W

hole

Rule

Set

(b)

11

GHz CPU and 4GB memory. With the increase of entries in rule table from 1000 to 10,000,000, the time cost by VAVE module to process a flow increases slightly from 0.00015 ms to 0.00037 ms. The time is trivial compared with the time for message forwarding.

V. RELATED WORKS

Using route information to build IP spoofing filtering table is more common in mechanisms for intra-AS and inter-AS networks. SAVE [15] is a protocol for routers. It announces the local route selection choice and helps others build the mapping table from incoming prefix to interface. SAVE can work independent of the routing protocol on routers. BASE [16] updates BGP message to contain BGP route selection choice. iDPF [17] builds inter-domain filtering rules based on the valley-free feature of inter-domain routing and the BGP announcement filtering rules. BASE and iDPF both work for inter-domain network.

For LAN, current solutions build filtering rules assuming the layer 2 routing is symmetric and static. However, in a lot of scenarios, e.g., campus network, enterprise network and data center network, the LAN structure has been quite complex, and layer 2 routing protocol for complex layer 2 topology has been standardized [18]. In these cases, current filtering principle almost surely works incorrectly.

VI. CONCLUSION

In this article, a mechanism named VAVE which builds protective perimeter for SAVI devices is proposed. We conclude our contributions as follows:

1. We raised an important drawback of SAVI: bound

addresses on one SAVI device can still be forged to

attack host attaching to the other SAVI devices. This

problem makes SAVI addresses in SAVI area still

trustless and discourages SAVI deployment.

2. To solve the raised problem, we proposed a novel and

practical solution: VAVE. This is the first proposed

source address validation mechanism with

OpenFlow/NOX architecture.

3. Due to the difference between OpenFlow/NOX

architecture and traditional network operation model,

VAVE is endowed with several distinctive features. The

most important feature is agility. Because address

validation in VAVE is of agility, the packet process

overhead and resource requirement are greatly reduced.

REFERENCES

[1] Ferguson, P. and D. Senie. (May 2000). "Network Ingress Filtering:

Defeating Denial of Service Attacks which employ IP Source Address Spoofing.", RFC2827.

[2] N. Gude, T. Koponen, J. Pettit, B. Pfa, M. Casado, N. McKeown, and S.

Shenker. NOX: Towards and operating system for networks. In ACM

SIGCOMM Computer Communication Review, July 2008.

[3] Nick McKeown , Tom Anderson , Hari Balakrishnan , Guru Parulkar , Larry Peterson , Jennifer Rexford , Scott Shenker , Jonathan Turner,

OpenFlow: enabling innovation in campus networks, ACM SIGCOMM

Computer Communication Review, v.38 n.2, April 2008

[4] A. R. Curtis, Jeffrey C. Mogul, Jean Tourrilhes, Praveen Yalagandula, Puneet Sharma, and Sujata Banerjee. "DevoFlow: Scaling Flow

Management for High-Performance Networks," SIGCOMM, 2011.

[5] Z. Cai, A. L. Cox, and T. S. E. Ng. Maestro: A System for Scalable

OpenFlow Control. Tech. Rep. TR10-08, Rice University, 2010.

[6] S. Bellovin, "Security Problems in the TCP/IP Protocol Suite," Computer Communication Review, Vol. 19, No. 2, pp. 32-48, April

1989.

[7] CERT, “CERT Advisory CA-1996-21 TCP SYN Flooding and IP

Spoofing Attacks”, http://www.cert.org/advisories/CA-1996-21.html , 1996.

[8] CERT, “CERT Advisory CA-1998-01 Smurf IP Denial-of-Service

Attacks”, http://www.cert.org/advisories/CA-1998-01.html, 1998.

[9] Vaughn, R. and G. Evron. (March 17, 2006). "DNS Amplification

Attacks." from http://www.isotf.org/news/DNS-Amplification-Attacks.pdf.

[10] UCSD network telescope, http://www.caida.org/data/realtime/telescope/.

[11] Bruno Quoitin , Luigi Iannone , Cédric de Launois , Olivier

Bonaventure, Evaluating the benefits of the locator/identifier separation,

Proceedings of 2nd ACM/IEEE international workshop on Mobility in the evolving internet architecture, August 27-30, 2007, Kyoto, Japan.

[12] Robert Beverly, Arthur Berger, Young Hyun, and k claffy,

Understanding the Efficacy of Deployed Internet Source Address

Validation Filtering, ACM SIGCOMM/USENIX IMC 2009

[13] IETF SAVI Working Group, http://tools.ietf.org/wg/savi/.

[14] Neil Spring, Ratul Mahajan, and David Wetherall Measuring ISP Topologies with Rocket fuel. In Proceedings of ACM SIGCOMM,

August 2002.

[15] J. Li, J. Mirkovic, M. Wang, P. Reiher and L. Zhang. SAVE: source

address validity enforcement protocol. In INFOCOM, June 2002.

[16] Heejo Lee, Minjin Kwon, Geoffrey Hasker and Adrian Perrig,”BASE: An Incrementally Deployable Mechanism for Viable IP Spoofing

Prevention,” ASIACCS’07, 2007, Singapore.

[17] Z. Duan, X. Yuan, J. Chandrashekar, Constructing inter-domain packet

filters to control IP spoofing based on BGP updates. In Proceedings of IEEE Infocom, 2006.

[18] J. Touch, R. Perlman. Transparent Interconnection of Lots of Links

(TRILL): Problem and Applicability Statement, RFC5556.

Figure 7. The time cost by VAVE module to process a

flow

100 1000 10000 100000 1000000 1E7

0.00015

0.00020

0.00025

0.00030

0.00035

0.00040

Tim

e c

ost

by V

AV

E m

od

ule

(m

s)

Number of entries in rule table

12