O-CPF: an OpenFlow based intra-AS source address validation ...

1 downloads 0 Views 555KB Size Report
Jun 7, 2013 - NAPP physically, we design a general communication protocol between them, thus they can run separately and communicate using socket.
O-CPF: an OpenFlow based intra-AS source address validation application Peiyao Xiao

Jun Bi

Tao Feng

Institute for Network Sciences and Cyberspace, Tsinghua University, Beijing 100084, China.

Institute for Network Sciences and Cyberspace, Tsinghua University, Beijing 100084, China

Institute for Network Sciences and Cyberspace, Tsinghua University, Beijing 100084, China

[email protected]

[email protected]

[email protected]

ABSTRACT

OpenFlow swith device, Network OS and Network Apps.

In order to filter out traffic with forged source IP, we proposed a method of source address validation in intra-AS named CPF. But due to the limitations of current network equipment, we came across a lot of difficulties when implementing it. In this paper, we introduce an OpenFlow based CPF (O-CPF). By transforming a commercial router into an OpenFlow-able device named OpenRouter, extending OpenFlow protocol to meet CPF’s requirements and designing a general communication protocol between NOS and CPF, We build up an OpenFlow based environment and transplant CPF into it.

Categories and Subject Descriptors C.3.3 [Network Operations]: Network management

General Terms Algorithms, Management, Design, Security. Figure 1. Principle of Traditional CPF.

Keywords OpenFlow, SDN, IP source address validation.

1. INTRODUCTION It is of great value to filter out traffic with forged source IP address for the security, management and accountability. We proposed a method of intra-AS source address validation named CPF based on the idea of centralized computing forwarding path. During the implementation of CPF, we used SNMP to collect routing information, xFlow (including sFlow, NetFlow. etc) to collect sampling and Expect script to configure ACL (based on telnet command-line). We suffered a lot from the dissimilarity and non-standard interfaces brought out by different equipment. Figure 1 shows the principle of traditional CPF.

2. OPENROUTER OpenRouter is described in former paper [1]. It’s already implemented in DigitalChina’s DCRS-5980 routing switch. We add an OpenFlow module into a commercial router to enable the OpenFlow feature and extend OpenFlow protocol (OpenFlow+) using TLV format, to meet CPF’s requirements such as routing information transmission.

As SDN provides us with a programmable environment for network controlling and decouples the low-level hardware from control logic, we decided to transplant CPF into it. According to SDN’s architecture, we will introduce our system in three parts: Permission to make digital or hard copies of all or part of this work for personal or classroom use is granted without fee provided that copies are not made or distributed for profit or commercial advantage and that copies bear this notice and the full citation on the first page. Copyrights for components of this work owned by others than the author(s) must be honored. Abstracting with credit is permitted. To copy otherwise, or republish, to post on servers or to redistribute to lists, requires prior specific permission and/or a fee. Request permissions from [email protected]. CFI’13, June 05 - 07 2013, Beijing, China Copyright is held by the owner/author(s). Publication rights licensed to ACM. ACM 978-1-4503-2147-1/13/06…$15.00..

Figure 2. OpenRouter.

3. NOS We apply OpenFlow+ into NOX. In order to decouple NOS and NAPP physically, we design a general communication protocol between them, thus they can run separately and communicate using socket. There are 4 kinds of message: register, request, post, remove. They are supposed to support general data

transferring demands (including pull and push mode). The NOSNAPP protocol is designed using TLV format too, so it can be extended easily. OpenRouter FlowTable sendAcl

Nsm fullTable Event Handler

SAMPLE_PACKET

NSM_CHANGES

NSM_FULL_TABLE

generate latest filtering rules. Figure 6 shows the filtering rules delay cumulative probability distribution. It’s obvious that OCPF improves a lot in reducing filtering false positives as it takes changes-driven calculating instead of polling mode.

Nsm changes Event Handler

Sample packet Event Handler

nsm_full_table_observers nsm_changes_observers sample_packet_observers Observer (once 2) Observer (permenent) Observer (permenent) Observer (permenent) Observer (once 2) Observer (permenent) …………

nsm_full_table

post

…………

register remove

request nsm_changes

sampel_packet

TLV Parser

TLV Encoder

NOS

…………

Recv Thread register post request remove

TLV Data

CPF

Figure 5. CPU utility comparison

Figure 3. OpenRouter.

4. O-CPF Based on the OpenFlow environment provided by OpenRouter and NOS, we redesign and reimplement CPF. Firstly, we implement the NOS-NAPP protocol interface, thus CPF can transfer data using a uniform protocol. Secondly, as OpenRouter support notifying network status changes, CPF takes changesdriven calculating mode to react to network topology updates. And we design a partial calculating algorithm for changesdriven invoke. Compared with traditional polling calculating method, it will save much CPU resources and get better filtering performance.

Figure 6. Filtering Rules Delay CPD

6. CONCLUSION AND FUTURE WORK In this paper, we transplant a source address validation application CPF into an OpenFlow environment. Thanks to the flexibility and support for innovation provided by SDN, we not only can be free from considering hardware and interface details, but also optimize CPF’s performance. Our work is an example of making use of SDN. During exploring into it, we find that there are still a lot of blank fields worthy of research.

7. ACKNOWLEDGMENTS Figure 4. Architecture of O-CPF.

5. EVALUATION To evaluate O-CPF’s performance compared with traditional CPF, we design experiments to measure the metrics in computing performance and filtering effect. We take the IPv6 topology of Tsinghua University campus network as evaluation environment, and set the traditional CPF’s polling interval as 10 minutes. Figure5 shows the CPU utility of 2 CPFs when running them separately and both make topology changes in 45th minute. When topology changes, there exists delay before CPF can

This work is supported by the National High-tech R&D Program ("863" Program) of China (No.2013AA010605), the National Science Foundation of China (No.61073172), and National Key Basic Research Program ("973" Program) of China (No.2009CB320501). Jun Bi is the corresponding author.

8. REFERENCES [1] T. Feng, J. Bi and H. Hu. OpenRouter: OpenFlow Extension and Implementation Based on a Commercial Router, in proceedings of the 19th IEEE International Conference on Network Protocols (ICNP11), pp141-142, Vancouver, Canada, 2011.

Suggest Documents