Source Address Validation Solution with. OpenFlow/NOX Architecture. Guang Yao, Jun Bi and Peiyao Xiao. Network Research Center. Tsinghua University.
2011 19th IEEE International Conference on Network Protocols
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 Denial of Services (DoS) attack.
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.
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.
Keywords- OpenFlow; IP source address validation
I.
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.
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].
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
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 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.
978-1-4577-1394-1/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.
NOX OP OpenFlow device
VAVE Filter App Generator
Validation Module
Filter Adapter
LD
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.
First Packet
Legacy device
LD
Flow Path (A, F) OP A
OP C
Hit Filtering Rule
OP B
LD
OP E
OP D
VAVE
VAVE has following unique features compared with other mechanisms: 1.
2.
3.
LD
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.
OP G
OP F
LD
Spoofing Flow (S=A,D= F)
LD
LD
LD
Figure 1. The Architecture of VAVE 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.
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 recalculation 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.
VAVE
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.
OpenFlow Device
No Validation
SAVI based Validation
OpenFlow Device
VAVE Interface
Legacy Device
SAVI based Validation
Figure 2. Three types of interfaces on OpenFlow device 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
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.
8
SAVI device can arrive at SAVI host through the VAVE interface.
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 recalculated 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.
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.
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.
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.
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.
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.
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.
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.
D. Rule Adaptor This module configures rule onto the OpenFlow device through interface supplied by NOX.
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 2 the flows whose path should be calculated is A .
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 is P 2 . Only flow in P 2 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.
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 2 discovered topology. Then, for each flow f in A , 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
9
Source(X)
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.
Spoofing Flow
; ; ; ; ; ; ; ;
Destination(Y)
