SDN-RDCD: A Real-Time and Reliable Method for Detecting Compromised SDN Devices
SDN-RDCD: A Real-Time and Reliable Method for Detecting Compromised SDN Devices
- abstract
- I. introduction
- II. detection of compromised SDN devices.
- III. the proposed method: SDN-RDCD
- A. threat model
- B. principles
- C. SDN-RDCD algorithm for controller
- D. effectiveness analysis
- E. 系统实现
- F. overhead analysis
- G. scalability
- H. discussion
- IV. evaluation
- A. setup
- B. evaluation methodology
- C. effectiveness and performance evaluation
- D. overhead evaluation
abstract
SDN 面临很多安全挑战，例如SDN控制器和交换机劫持。本文提出了在交换机和控制器都不可信的环境下实时监测受损SDN设备。本文的主要思想就是设置一个审计控制器，用于①审计从主控制器交换机收集到的更新事件；②检测异常事件从而判断出受损的设备。异常事件就是主控制器审计控制器以及交换机行为和期待（计算）的不同。
另外heterogeneous审计控制器这个概念提出用于避免和主控制器一样的脆弱性问题（单点故障）。
I. introduction
现在的SDN架构可能会遭受安全攻击，受损设备存在监控可信通信，阻碍正常管理，破坏基础架构这些问题。因此有必要实时监测受损的SDN设备。
首先基于原有的两种角色-master 和 slave上，提出一个新的角色auditor控制器，auditor是从slave中选出。
从master controller和switch中分别收集信息。
master：update request。一个合法的更新请求分配一个唯一ID。master对应ID的执行结果镜像到对应的审计控制器。
switch：发送①来自master的网络更新指令②state update。
审计控制器会创造审计记录：包含ID,请求，执行结果，审计控制器自己执行的结果（re-execute result）交换机给的两种消息。
创新点：
①提出了交换机和控制器都不可信环境下检测受损SDN设备。
②提出了审计控制器，收集网络信息，低负载实现检测
③基于现在SDN设备提出了假设，展示了相应的算法，介绍了实现细节。
④使用理论证明以及实验结果验证假设方法。
II. detection of compromised SDN devices.
A. SDN paradigm-不多介绍
B. 受损设备导致的安全威胁
C Problem Definition and Motivation
SDN device is compromised or not: 传统网络中需要判断是否他的转发行为偏离路由协议。但是SDN可编程介入使得他的行为模型不只是有限的几种，SDN中一个判断方法就是验证网络事件是否按照期待的方式处理。所有的网络事件都可以被解耦成一系列的网络更新事件。
网络更新时间开始于一个请求，控制器执行请求，下发指令给交换机，我们可以对比执行结果和期待结果发现受损设备。难点在于如何获取期待数据。
III. the proposed method: SDN-RDCD
A. threat model
交换机和控制器都不可信，假定攻击者可能劫持一组交换机和控制器的结合，并且完全控制了设备。
攻击者可以指示受损设备以及劫持的控制器下的交换机随意改变状态，
既定至少一个交换机以及至少一个相关的审计控制器是诚实的。
B. principles
需要收集（1）网络更新请求，（2）master关于请求的执行结果（3）交换机收到的网络更新指令（4）交换机的每个状态更新。
一个审计ID打在合法的请求上，用于追踪后续的处理（PS，ID连接着请求发起者，用于追溯异常的根源）。
上面四种信息依旧不可以判断是否网络请求正确执行。slave和master有一致的网络相关和应用相关的状态，所以使用slave作为审计可以得到相同的执行结果。
- master设计为镜像每个合法的update request 给审计，对应的执行结果也给审计。
- 审计会根据合法的request 给一个ID，重新执行这个网络请求，把自己执行的结果加到ID的记录中。
- 交换机设计为镜像收到的每个更新指令给审计，当状态更新时，交换机会抓取状态更新并且通知给审计。
当然交换机可以直接把packet_in消息给审计和master这样审计就可以从交换机得到request消息，不用从master获取了。
综上，设计得到五类消息①网络更新请求②master执行结果Rm③审计控制器执行结果Ra④相关交换机收到的指令Is⑤交换机对应的状态更新Rs
基于五中信息可以判断是否有受损设备，当检测到受损设备通知操作者operator。
（1）Rm = Is = Rs = Ra 一切正常
（2）Rm = Is = Rs != Ra 主控制器可能受损
（3）Rm = Is != Rs 执行没有正确执行，交换机可能受损。
（4）Rm != Is 网络更新指令在传输过程中被更改，可能有中间人攻击。
（5）不匹配的交换机状态更新，一些交换机的状态更新不匹配任何审计记录，交换机可能偷偷的进行状态更新没有收到任何master的指令。
图2位示意整个收到的过程，为了表示清楚，只涉及了一个交换机。
C. SDN-RDCD algorithm for controller
图三展示了收到审计信息后的决策过程。
D. effectiveness analysis
分析了算法的有效性-理论上。
如果审计控制器被劫持或者来自控制器和交换机的消息被合作操控，算法无效。
假定一个最坏的例子，受损的master和switch可以通过操作审计消息避免被检测，受损的审计控制器也忽略有害的审计结果，证明有效性。
我们针对的是通用的劫持攻击，这类攻击要么破坏所有的特定交换机，或者劫持master。
PROOF： P’表示攻击在RDCD下成功概率，P表示不再RDCD下成功的概率。S表示所有特定交换机被成功劫持，A表示每个审计控制器被劫持，M表示主控制被劫持。
实际上P’比P小的多，因为攻击者可能没有意识到RDCD的存在。
公式不好写，看原文吧。
E. 系统实现
（1）现存的控制器ONOS， ODL都实现了master和slave的状态一致性，所以可以直接利用。
（2）switch state update traceability：审计控制器会为每个网络请求创造ID，为了实现ID传递，需要添加一个ID参数，另外为了实现不同控制器和交换机之间的ID传递，通过扩展openflow协议添加一个ID域。另外，审计ID连接请求的发起者，可以追溯恶意攻击的来源。
（3）交换机端信息传递给审计控制器：通过利用现有的openflow消息实现，例如flow-removed消息，由交换机发送，用于通知控制器特殊的流表项已经移除，我们做一些调整，把新消息作为审计消息，同时原有的flow_removed 消息也保留。
（4）捕获交换机端信息：根据RDCD，交换机中所有关于状态更新的功能需要调整为可以抓获保存相关的状态更新消息。
F. overhead analysis
负载三个部分（1）master需要发送消息给auditor，流量很小，负载忽略（2）switch给auditor和master发消息，对比数据平面流量，这些也很小（3）auditor:执行网络请求，执行审计任务，审计不需要生成指令给交换机，所以对比控制器的计算资源，这些负载也很小。实验验证了以上观点
另外维持审计和master的一致性也带来了负载，这类负载不是因为RDCD，本来master和slave也需要维持一致性。
G. scalability
分布式控制平面解决了SDN可扩展性，每个控制器管理一定数量交换机，在各自的domino，每个控制器有一个或者多个slave。RDCD通过选择slave做审计分别在每个域，实现扩展性。
另外可以将任务分给不同的审计控制器，例如根据ID的范围。
H. discussion
需要【29】【30】【33】的策略检测是否网络请求合法。
IV. evaluation
A. setup
实验一，detection rate， detection time，分别利用一个控制器劫持，一次交换机劫持。
实验拓扑如图5，
配置：
- 网络跑在服务器： Intel CPU 2,5GHZ, 16G内存，
- master分别使用ONOS作为controller，
- master分别使用ODL作为controller，
- master跑在2.5GHZ的INTEL CPU上，16G内存
- auditor跑在2.4GHZinte CPU上，16G内存
三台服务器时间保持一致。
B. evaluation methodology
packet-IN消息作为 update request,一般情况下，收到这个消息，master的路由计算模块会计算一条路径，并且下发给路径上的交换机更新相应的流表。
如果host1 每0.2秒发送一个源目的不一样的包，交换机会每秒发送5个packet——in消息，这些消息我们看做是特殊packet—in，另外master也受到普通的交换机每秒100个的packet——in消息作为背景负载。实验持续时300S, 也就是收到特殊packet——in消息为1500个。
这个实验分别跑两次，分别模拟控制器劫持和交换机劫持。
如果控制器受损，路由计算模块会给一条其他的路径，如图5蓝色路径，现有的检测方法是难以检测到。
如果特殊路径上的交换机受损，他们可能根据攻击者的指令，为那些特殊packet——in消息配置一条路由路径。只要有一个交换机提交了正确的审计信息，这类攻击可以被RDCD发现。
C. effectiveness and performance evaluation
第一组实验测试 : 检测率和检测时间，
实验检测率都是100%，图六图七分别展示了控制器和交换机1受损的检测时间概率分布，平均检测时间分别是1.926ms 和7.4867ms.
实验结论，RDCD是有效的，而且速度快。
D. overhead evaluation
第二组实验：CPU, 内存，带宽，三种设备的（master， switch， auditor），他们连接链路之间的带宽。 以及不使用RDCD时，同样的拓扑的overhead。
图8,9,10，三种设备CPU使用率概率分布，无RDCD-93， 119， 18， 有95， 136， 27
结论：RDCD造成的CPU负载很小。
图11,12,13 三种设备内存使用率概率分布，
图14， 15， 16 链路使用概率分布。
第二个实验结论是：RDCD造成的CPU,内存，链路负载低，而且可接受。