A rapid filtering rule management plane implementation using distributed in-memory caching system With the wide spread of SDN and NFV in progress, network virtualization would benefit from a unified rule management base. However, there are some challenging concerning scalability and diversity in handling filtering rules. In this paper we propose a rapid filtering rule management plane implementation using in-memory data store. We leverage in-memory caching system for achieving functionality, flexibility and scalability for managing virtual networking environment. In experiment, we have prototyped a lightweight management plane for IP filtering. It is shown that proposed method can achieve reasonable utilization in filtering IP packets. Technical Report, vol. 114, no. 471, ISEC2014-97, pp. 139-147, 2015 March.

1. A rapid filtering rule management
plane implementation using
distributed in-memory caching
system
Network Security Research Institute, National Institute of Information and
Communications Technology
Ruo Ando
情報通信研究機構 ネットワークセキュリティ研究所
安藤類央
IT・ISEC・WBS合同研究会 3/2 – 3/3
(23) 16:40-17:05
http://starbed.nict.go.jp/

2. 概要：仮想ネットワーク上での分散インメモリキャッシュを
用いたフィルタリングルール処理の高速化
ネットワーク仮想化（抽象化）とその周辺技術（Software Defined Network, クラ
ウドコンピューティング）の発達により、アクセス制御技術、特にパケットフィルタ
リングルール処理に修正が求められている。
また、SDNの基本設計方針の結果として、データプレーンは分散、大規模化し、
コントロールプレーンに処理が集中し、SPOF（単一障害点）やスケーラビリティ
の点で問題が生じている。
提案システムには大規模なフィルタリングルールの処理のためにMemcached
（分散インメモリキャッシュシステム）を用いた。また、C (Consistency)、
A(Availability)、P(Partition Torelance)のうち、Cの制約を緩めることでスケール
アウトまたは冗長化が容易なシステムの構築を行った。
評価実験では、radix treeを用いたIPフィルタリングを実装し、10, 1000, 10000,
100000までのルールセットの処理を行い、通常のデータストアを用いたシステ
ムではルール1000以上で処理が許容不可能になるのに対し、提案システムは
ルール数が100000を越えても許容可能な負荷率で稼動する（CPU負荷率で１
０%以内）ことを示した。

3. Network Virtualization: Separation of data,
control and management plane
HW
DataPlane
HW
Control Plane
rule DB
upcaller
HW
DataPlane
HW
DataPlane
Control Plane
HW
Data Plane
Control Plane
HW
Data Plane
Control Plane
HW
Data Plane
Firewall
Load Balancer Application Firewall
Firewall
Load Balancer
Application Firewall
Management Plane
本論文での改良対象
スケーラビリティを確保することが現状では困難

4. Avenues of Attack
Sensitive data
Enterprise Network
Missing
Security Patches
Misconfigured
Database
Advanced Attacks
Sensitive
Data Leaks
Escalating
User Privileges
Default
Passwords
Weak
Passwords
Unauthorized
Database
Weak
PRNG
CDP:Functional & Operational Firewall Pattern - AWS-CloudDesignPattern
Nemesis: preventing authentication & access control vulnerabilities in web
applications, SSYM'09 Proceedings of the 18th conference on USENIX security
symposium
Detecting BGP configuration faults with static analysis, NSDI'05 Proceedings of the
2nd conference on Symposium on Networked Systems Design & Implementation
A security enforcement kernel for OpenFlow networks, HotSDN '12 Proceedings of the
first workshop on Hot topics in software defined networks
Misconfigured
Filtering
Management planeの
対象領域

5. Network virtualization: abstraction and
centralization
NIC
HD
CPU
RAM
FW
LB
VLANS
VRF
２００１ ２０１２
image
vCPU
vRAM
vNIC FlowTable
vFW
vLB
abstraction layer
Xen
KVM
VMWare
OpenFlow
Open vSwitch
FloodLight
Decouple
Virtualization layer
reproduce
Automate

6. Network virtualization: slicing after virtualization and
abstraction
x86 / ARM
Virtualization
Layer
Windows Linux
Open Flow
Virtualization
Or Slicing
NOX NOX
CPU, Hardisk, PIC, IO
X86 instruction set
Xen, QEMU, etc
Windows Linux
Hardware Resources
Abstraction layer
Virtualization Layer
slice slice
Bandwidth, CPU, FIB
OpenFlow
FlowVisor
Controller Contoller
Definition of a slice
• Slice is a set of flows (called flowspace) running on a topology of switches.
https://www.clear.rice.edu/comp529/.../tutorial_4.pdf

7. Network virtualization: Deployment example
• Virtualized Networking environment = SDN + Cloud computing.
• Instance is virtualized
• Network is also virtualized
hypervisor
VM VM
hypervisor
VM VM
SDN controller Network operating system
Routing Traffic
Engineering
Load
Balancing
Open Flow Switch Open Flow Switch
Data Plane
Control Plane
各ノードは仮想化
され、マルチテナント
として同一物理NIC
上に配置される。
ネットワークも仮想化
され、フィルタリングと
マッチング処理が分離
一元化される。
Open vSwitch. B. Pfaff, J. Pettit, K. Amidon, M. Casado, T. Koponen, an
d S. Shenker. Extending Networking into the Virtualization Layer. In
HotNets, 2009
Operational /
Functional FW
Amazon EC2
Design Pattern

8. Drawbacks of SDN: Distributed Dataplane vs
Centralized Controller
HW
DataPlane
HW
Control Plane
Switch DB
upcaller
HW
DataPlane
HW
DataPlane
データセンターなどの
コアネットワークでは
データプレーンはスケールア
ウトし、性能は変わらない。
②通常のvSwitchの設計では
パケットデータはユーザ空間
に転送されるが、その際のボ
トルネックが生じる。
①SDNの一元管理の性
質から、コントローラに
処理が集中する。
本論文では、①と②の
問題点に対して、ユーザ
モードで稼動する
Memcachedを用いて
スケーラブルなシステムを
構築する。

9. 設計上の問題：仮想化環境とスケーラビリティ
Centralized access
control model
2000 2005 2010 2014
Virtualization
Technology
(hypervisor)
Cloud computing
Domain Specific /
Declarative Language
Open Flow
DSL for IDS and access
control
New Security
Concerns
DSL for SDN
Rules and conflict
management
sHype
Pyretic
Xen
Chimera
ForNox
RuleBricks
Remote Attestation
Attack on multi-tenant
アクセス制御の
一元化
ネットワーク
抽象化
アクセス制御の
表現方法の問題
Open vSwitch
vMAC
sandbox xenprobe
subvirt
仮想化、ハイパーバイザー内でのAC一元化
スケーラブル、合成可能な
観測システムの構築BGP attack
ネットワークのスライシング
仮想化技術を用いた
動的解析
ConfAid
BotMiner
解析の大規模化
大規模システムでの設定・
Access Ctrlの検査
Flowvisor
HyperDex Ensenble

10. CAP定理：分散システムでの３つの設計条件
"Logically centralized?: state distribution trade-offs in software defined networks", Dan Levin, Andreas
Wundsam, Brandon Heller, Nikhil Handigol and Anja Feldmann, HotSDN '12 Proceedings of the first workshop
on Hot topics in software defined networks
Controller component choices:
[1] Strongly consistent – controller components always operate on the same
world view. Imposes delay and overhead.
[2] Eventually consistent – controller components incorporate information as
it becomes available but may make decisions on different world views.
http://www.richardclegg.org/node/21
C A
P
NoSQLRDBMS
Consistency Availability
Tolerance to network
partition
CAP Theorem (Eric Brewer 2000)
Enforced Consistency Eventual Consistency パケットフィルタなどの処理では
Strongly Consistentであることが
求められる（望ましい）
NoSQLを用いることで
A (availability)
P (Tolerance to network partition)
S (Scalability)
が達成される。

11. Memcached – In memory distributed
caching system
Memcached
Client
memcached は、汎用の分散型メモリキャッ
シュシステムである。
DataBase WebServer
Client Client
HW
DataPlane Forwarder
本システムでは、ユーザモードで稼動する
forwarderがMemcachedに問い合わせる。
cache miss
memcached の API は、複数のマシン上に分
散された巨大なハッシュテーブルを提供する。
テーブルがいっぱいの場合、以降のデータの
新規挿入により古いデータはLeast Recently
Used 順序で削除される。memcached を用い
るアプリケーションは、背後にあるデータベー
スなどの低速な記憶装置へのアクセスの前に
memcached のリクエストを挿入する。
オンメモリで稼動し、クライアントがConsistent
Hashingをもちいることで、分散・冗長化が可能。

12. Rapid filtering rule management plane
with memcached tier
Memcached 1
Memcached 2
Memcached 3
ruleDB
ruleDB
ruleDB
control plane
Hardware
data plane
Hardware
data plane
Hardware
data plane
Hardware
upcaller
Select memcached
1..n with consistent
hashing
Cache miss
同手法はFlow Tableがほとんど
変化しないCore networkで有効
であると想定される。

13. Memcached tier achieves A (availability) and P (partition tolerance)
"Logically centralized?: state distribution trade-offs in software defined networks", Dan Levin, Andreas
Wundsam, Brandon Heller, Nikhil Handigol and Anja Feldmann, HotSDN '12 Proceedings of the first workshop
on Hot topics in software defined networks
Controller component choices:
[1] Strongly consistent – controller components always operate on the same
world view. Imposes delay and overhead.
[2] Eventually consistent – controller components incorporate information as
it becomes available but may make decisions on different world views.
http://www.richardclegg.org/node/21
C A
P
NoSQLRDBMS
Consistency Availability
Tolerance to network
partition
CAP Theorem (Eric Brewer 2000)
Enforced Consistency Eventual Consistency パケットフィルタなどの処理では
Strongly Consistentであることが
求められる（望ましい）
NoSQLを用いることで
A (availability)
P (Tolerance to network partition)
S (Scalability)
が達成される。

14. Basic SDN architecture and proposed system
Node (VM)
Node (VM)
Node (VM)
Flow
Table
ControllerSecure
Channel
Node (VM)
Node (VM)
Node (VM)
Filtering
rule
Table
Data store
match
match
判定処理(match)はノード側で行い、パケットは転送
しない。→ これにより、フィルタリングの一元管理を
達成しつつ、Control/Management Planeの負荷を下
げる。
Ingress packets
Ingress packets
Data plane Control plane
Control and Data plane Management plane
VCRIB: Virtualized rule management in the cloud Masoud Moshref, Minlan Yu, Abhishek Sharma, Ramesh Govindan the
4th USENIX Workshop on Hot Topics in Cloud Computing (HotCloud). Boston, MA, June 2012.
Basic SDN
提案手法

15. Management Plane Isolation:提案システムの機能配置
DataStoreの
適用
Scalabilityを
確保する
一元管理：
設定管理
ミスをなくす
Data planeとControl planeは
同一ホスト（インスタンス）内で
分離しない。
フィルタリング・設定情報の
管理用にManagement planeを
設置して管理。
全てのcomponentをuser modeで実装することでdeploymentのコストを下げ、迅速にする。

16. Adopting basic datastore on management plane
auto_ptr<mongo::DBClientCursor> cursor =
client.query(ns, mongo::BSONObj());
while(cursor->more()) {
mongo::BSONObj p = cursor->next();
mongo::OID oid = p["_id"].OID();
string dest = p["dest"].str();
int mask = p["mask"].numberInt();
string gateway = p["gateway"].str();
const char *p0 = dest.c_str();
const char *p1 = gateway.c_str();
add_rtentry(p0, mask, p1);
int res;
res = find_route(dstAddress);
if(res==0)
printf("route find n");
/* flush entry /*
rm_rtentry(p0, mask);
{"_id":
"$oid":"53370eaeb1f58908a9837910"
"dest":"10.0.0.0","mask":
8,"gateway":"192.168.0.2"}
Radix treeのエントリを動的に読み出すことで
リモート(management plane)から任意の
タイミングでフィルタリングルールを変更できる
ようにする。
Filtering ruleはBSON (JSON)で記述
a radix tree (also patricia trie or radix trie or
compact prefix tree) is a space-optimized trie
data structure where each node with only one
child is merged with its parent.
14 entry.addr = ntohl(addr dst.s addr);
15 entry.prefix len = 32;
17 radix tree<rtentry, in addr>::iterator it;
18
19 it = rttable.longest match(entry);
20 if (it == rttable.end()) f
21 std::cout << ‘‘no route to ‘‘ << dst << std::endl;
22 return 1;

17. if ((memc = memcached_create(NULL)) == NULL) {
fprintf(stderr, "failed to allocate memoryn");
// return 1;
}
rv = memcached_server_add(memc, "localhost", 11211);
if (rv != MEMCACHED_SUCCESS) {
fprintf(stderr, "failed to set servern");
return 1;
}
char *result;
uint32_t flags;
size_t result_length;
/* retrieving gateway address */
sprintf(key1,"gate-%s", dstAddress);
printf("key1: %s n", key1);
result = memcached_get(memc, key1, strlen(key1),
&result_length, &flags, &rv);
if (rv != MEMCACHED_SUCCESS) {
fprintf(stderr, "failed to fetch recordn");
return 1;
}
/* retrieving netmask */
snprintf(key2,32,"mask-%s", dstAddress);
printf("key2: %s n", key2);
result = memcached_get(memc, key2, strlen(key2),
&result_length, &flags, &rv);
if (rv != MEMCACHED_SUCCESS) {
fprintf(stderr, "failed to fetch recordn");
return 1;
}
Adopting Memcached on
management plane
import bmemcached
import random
client =
bmemcached.Client(('127.0.0.1:11211',
),
'user','password')
client.set('gate-10.0.0.8', '10.0.0.1')
client.set('mask-10.0.0.8', '8')
{"_id": "$
Basic datastore query representation
oid":"53370eaeb1f58908a9837910"
"dest":"10.0.0.0","mask":
8,"gateway":"192.168.0.2"}

18. Experimental result on Amazon VPC
We compiled our system on ubuntu12 LTS with
Linux kernel 3.2.0. proposed system is hosted
on Intel Xeon E5645 with 2.4 GHZ clock.
ルール数が１０～１００以内であれば、CPU負
荷率（３％以内）、コンテキストスイッチ（５０００
回以内）とも許容範囲内で稼動。
設定した環境内では、1000～10000のルール
を用いるケースは稀なため、提案手法は妥当。
vNIC1 vNIC2
Bridge
IP capture
1
2
3
MongoDB
5
8
7
8
Radix Module
6
0
Management plane Control plane
Python module
パケットキャプチャは
ユーザモードでの
pcapを利用。ルールは
Pythonを用いて設定

19. Experimental result on Amazon VPC (Memcached)
vNIC1 vNIC2
Bridge
IP capture
1
2
3
Memcached
5
8
7
8
Radix Module
6
0
Control plane
Python module
パケットキャプチャは
ユーザモードでの
pcapを利用。ルールは
Pythonを用いて設定
We compiled our system on ubuntu12 LTS with
Linux kernel 3.2.0. proposed system is hosted
on Intel Xeon E5645 with 2.4 GHZ clock.
通常のNoSQLシステムを用いると、ルール数
が１０００を越えると負荷率が錯乱（１０％を超
えて不安定になる）するが、Memcachedを用
いるとルール数が100000を越えても許容可能
な範囲で安定している。

20. まとめ：仮想ネットワーク上での分散インメモリキャッシュを
用いたフィルタリングルール処理の高速化
ネットワーク仮想化（抽象化）とその周辺技術（Software Defined Network, クラ
ウドコンピューティング）の発達により、アクセス制御技術、特にパケットフィルタ
リングルール処理に修正が求められている。
また、SDNの基本設計方針の結果として、データプレーンは分散、大規模化し、
コントロールプレーンに処理が集中し、SPOF（単一障害点）やスケーラビリティ
の点で問題が生じている。
提案システムには大規模なフィルタリングルールの処理のためにMemcached
（分散インメモリキャッシュシステム）を用いた。また、C (Consistency)、
A(Availability)、P(Partition Torelance)のうち、Cの制約を緩めることでスケール
アウトまたは冗長化が容易なシステムの構築を行った。
評価実験では、radix treeを用いたIPフィルタリングを実装し、10, 1000, 10000,
100000までのルールセットの処理を行い、通常のデータストアを用いたシステ
ムではルール1000以上で処理が許容不可能になるのに対し、提案システムは
ルール数が100000を越えても許容可能な負荷率で稼動する（CPU負荷率で１
０%以内）ことを示した。