Secure Communication Between OpenFlow Switches and Controllers(搬运论文)

Secure Communication Between OpenFlow Switches and Controllers

1.介绍：
我们研究了与OpenFlow通信的软件定义网络中交换机和控制器之间安全通道的认证和访问控制相关的不同协议的适用性。我们首先展示了OpenFlow体系结构中安全机制的不足之处。然后分析传输层安全，安全外壳和IPSec协议作为交换机和控制器之间的OpenFlow通信的安全通道介质的可用性，优点，缺点和实现细节。最后，我们讨论了可能的认证和访问控制机制的扩展。

OpenFlow协议[1]由于其为软件定义网络（SDN）的架构师和开发人员提供的功能而引起了学术界和商业界的兴趣。通过创建标准化的接口来连接交换机和控制器，控制平面逻辑被转移到集中控制器（或控制器组）。但是，即使严格遵守规范[2]，OpenFlow也不会强制使用交换机和控制器之间的安全通信通道。即，传输层安全性（TLS）使用的条目在OpenFlow规范中引入，然后进行修改。在最新版本中，它的使用只是一个推荐（不是“必须”的要求）。在OpenFlow交换机规范ver。 1.4.0秒6.3.3。 itreads：“交换机和控制器可能通过TLS连接”。而且，由于OpenFlow协议的性质不断变化，许多厂商还没有完全实现这个建议。由于缺乏TLS的采用以及TLS基础设施的实施问题，攻击者通过使用以下各节中描述的可能的攻击来渗透OpenFlow网络。为了使安全情况更加恶化，没有认证和访问控制机制（除了TLS中的身份验证）。

在不强制安全的通信渠道的情况下，Open-Flow有可能重复其他管理协议的错误，这是基于链路和基础设施是安全的假设（例如Telnet，SNMPv2，TFTP）设计的。当然，在生产环境它们必须被替换为安全版本（SSH，SNMPv3，SFTP，分别）。提出的OpenFlow解决方案之一是在分支机构网络结构中通过Internet控制交换机，或者将交换机管理提供为“安全即服务”。如果安全通信通道，认证和访问控制不被执行，则OpenFlow将不能发展成上述角色，并将被安全协议（例如在从Telnet到SSH的转换中）或另一个安全协议协议（如从SNMPv2到SNMPv3的转换）。

在本文中，我们比较了在OpenFlow通信中实现不同的身份验证和访问控制机制与TLS，SecureShell（SSH）和IPSec三种通用协议的可能性。

传输层安全性[3]及其前身SecureSockets Layer（SSL）是保护数据通信的密码网络协议。 TLS提供数据的机密性和完整性，以及服务器的身份验证，有时还包括客户端的身份验证。 它基于非对称加密，可以采用两种模式，即：

•X.509证书和公钥基础设施密码系统，使用公钥和私钥加密和数字证书提供身份验证，加密，完整性和不可否认性;
•Web of Trust体系结构 - 分散认证方法，认证机构没有层次结构，每个证书的信任度是网络上其他成员签名的总和，在该证书下签名。

SSH [4]是整个协议族的通用名称，而不仅仅是终端。它也用于文件传输（SCP，SFTP），资源远程控制，隧道和其他应用程序。所有这些协议的一个共同特征与SSH数据加密技术和用户识别相同。可以通过加密通道配置SSH隧道来传输网络上的未加密通信。

IPSec [5]是一套实现主机之间密钥的安全连接和加密交换的协议.IPSec可以用来保护三种传输方式：

•主机到主机 - 主机对之间;
•网络到网络 - 在安全网关对之间;
•网关到主机 - 在网关和主机之间。

IPSec由连接的设备之间的至少两个通信通道组成：（a）交换通道，通过该通道传输与认证和加密（密钥）相关的数据;（b）通过已安全线路传输数据包的通道（一个或多个） 。

本文组织如下。在第2部分，wediscuss相关的作品。第3节描述了最近规范中OpenFlow的安全通道认证问题。它也提出了一些可能的攻击和影响。在第4节中，我们将提出有关所提议解决方案的技术细节，包括带有PKI体系结构的传输层安全性，安全壳隧道和IPSec协议。第5部分对所提出解决方案的安全性进行简单的安全性分析。第六部分结束了讲稿，介绍了我们今后在这方面的工作计划，包括PL-LAB2020的新解决方案和实验的实施，这是一个在波兰建立的大型试验台和实验网络。

2.相关工作：

SSH [4]是整个协议族的通用名称，而不仅仅是终端。它也用于文件传输（SCP，SFTP），资源远程控制，隧道和其他应用程序。所有这些协议的一个共同特征与SSH数据加密技术和用户识别相同。可以通过加密通道配置SSH隧道来传输网络上的未加密通信。

IPSec [5]是一套实现主机之间密钥的安全连接和加密交换的协议.IPSec可以用来保护三种传输方式：

•主机到主机 - 主机对之间;
•网络到网络 - 在安全网关对之间;
•网关到主机 - 在网关和主机之间。

IPSec由连接的设备之间的至少两个通信通道组成：（a）交换通道，通过该通道传输与认证和加密（密钥）相关的数据;（b）通过已安全线路传输数据包的通道（一个或多个） 。

本文组织如下。在第2部分，wediscuss相关的作品。第3节描述了最近规范中OpenFlow的安全通道认证问题。它也提出了一些可能的攻击和影响。在第4节中，我们将提出有关所提议解决方案的技术细节，包括带有PKI体系结构的传输层安全性，安全壳隧道和IPSec协议。第5部分对所提出解决方案的安全性进行简单的安全性分析。第六部分结束了讲稿，介绍了我们今后在这方面的工作计划，包括PL-LAB2020的新解决方案和实验的实施，这是一个在波兰建立的大型试验台和实验网络。

FlowVisor [6]充当控制器和交换机之间的透明代理，以便对由控制器创建的规则应用限制。它创建网络资源的切片（交换端口，MAC地址，IP地址，端口地址或ICMP类型的组合），并委派对不同控制器的切片控制。 FlowVisor的作用是将重写的规则的作用与网络的特定切片隔离，即一个切片不能控制另一个切片的流量。

类似的概念是FortNOX [7] - 在NOX控制器上开发的软件扩展，实时检查流量规则冲突。它在Open-Flow应用程序上使用基于角色的授权（在这种情况下，需要使用OpenFlow协议修改网络流量，例如防火墙，入侵防御系统）。 FortNOX和FlowVisor的不同之处在于，FortNOX是一个单独的控制器软件，可执行并行应用程序，而FlowVisorruns则不同于控制器（通常位于不同的主机上）。这两种解决方案都限制了内部控制器/应用程序引入安全威胁。但是，它们依赖于OpenFlow协议及其通信通道的安全性。

另一种方法是使用OpenFlow为SoftwareDefined Networks提供安全性。 NICE [8] DistributedDenial服务保护基础设施即服务是一种基于攻击图分析模型和可重构对策的分布式漏洞检测工具。

在OpenFlow环境中移动目标防御[9]是一种经常改变内部主机IP地址的机制，以减轻来自外部网络的攻击和侦察。

所有提到的工作都是为了提供基于OpenFlow的SDN架构的安全性，但其基本假设是没有协议的网络设计漏洞。在[10]中提出了一个全面的OpenFlow脆弱性评估。漏洞列表包含缺少TLS采用，流量执行，拒绝服务风险和控制器漏洞。通过使用本文所述的认证和访问控制机制，可以充分减轻其中的前三个（或至少显着减少）。

3.Openflow 安装信道问题

1.0版本中的OpenFlow规范包含了对TLS使用的要求[11]。 然而，下一个版本将这个要求从“必须”改变为“应该”。这也是当前版本（1.4）的情况。 在当前的SDN交换机和控制器中，TLS明显缺乏支持。 表I显示了OpenFlow设备供应商提供的TLS支持[10] [12]。

传输层安全的使用也影响到基于OpenFlow协议的软件定义网络的准备和维护。特别是，这包括生成控制器和交换机证书，使用私钥签署证书，在设备上安装正确的密钥和证书。假设拓扑结构分布在不同的地点，技术人员必须准备好公钥基础设施的所有组件，并提供安全性。

虽然在对物理设备的访问困难的安全网络（例如数据中心）中缺乏TLS支持是可行的，但是在类似于校园式或分支机构部署的体系结构中，它变成了严重的安全漏洞，其中访问网络在“安全即服务”中，管理协议的作用可能是OpenFlow由不可信的ISP（例如，客户端在有意拦截传输的国家）传输。在这种情况下，我们无法将攻击者将设备放置在交换机和控制器之间的通信路径上，或者将流量复制到他/她的机器上（图1）。他/她可以获得配置，插入或删除规则，修改/记录敏感数据流（使用OpenFlow设备配置）。另外，攻击可以在没有任何可观察到的正常传输差异的情况下执行，即攻击者充当透明代理（通过转发消息的过程将其与FlowVisor代理对规则的修改进行比较）。这种类型的攻击（所谓的“中间人”攻击）在以前非常流行和成功[13] [14]。软件定义的网络可以减少充分利用的难度，并且可能允许攻击者自动化该过程。在SDN中，中间人攻击可以说比在非软件定义的网络中更糟糕，因为嗅探流量没有必要获取纯文本证书或者可能在单次攻击中重新配置设备组。

注意确保交换机和控制器之间的安全通信是不够的 - 我们也应该认证连接到控制器或交换机的所有设备。例如，由于以下两个原因，可能需要认证和访问控制：

•限制添加虚假设备的可能性（例如，向OpenFlowdomain添加新的交换机或控制器）;
•对联合中的设备进行分组（比较，例如，奥菲利亚项目，[15]），当不同的组应该配置不同的规则。

有了完整的TLS实现和认证机制，我们可以保证主机和消息传输的安全。但是，我们无法检测到在数据库中的规则上错误操作的交换机。保持流经控制器和交换机上的网络的流量的同一个视图的唯一解决方案似乎是定期倾倒并检查在流量架构中的所有主机上的流量表。在[10]中描述的潜在解决方案基于生成具有校验和的保持活动消息，其中，发送给控制器的交换机的表被发送。

4.分别介绍3种方式的认证和加密详情
略过

5.安全分析
我们分析了所提出的解决方案在安全性方面的优点和缺点。 TLS，SSH和IPSec减少或防止执行以下攻击的可能性：
•嗅探（缺乏保密性）
•数据修改，
身份欺骗，基于密码和应用层攻击，
•中间人攻击（man-in-the-middle）
•拒绝服务攻击
但是，每个解决方案都有一些问题。

传输层安全性依赖私钥和证书机构信任的保密性，所以保证这些部分的安全性是维护这种类型体系结构的关键任务。对TLS的一些重大攻击包括FREAK [17]，BEAST [18]和CRIME和BREACH [19]攻击。但是，假设TLS及其最新版本得到正确实施，则认为是安全的。理论上TLS可以使用SSL-Striping和SSL-Spittingattack进行攻击[20]，但由于软件定义网络与TLS安全的OpenFlow的新功能，这些攻击尚未得到证实和充分研究。

如上所述，Secure Shell可以使用公钥和私钥或预共享密钥进行部署。无论使用什么选项，密钥（和CA如果使用）的保密性是至关重要的安全性方面。关于可能的攻击，使用修订版本的SSH-2被认为是安全的，然而，在[21]中发现默认加密模式CBC的理论上的可靠性。因此，我们建议在实施中使用CTR模式。另一个安全问题是有些机构能够解密SSH流量（参见[22]）。与这种攻击有关的细节没有公布。

IPSec，类似于TLS和SSH，依赖于预共享密钥的保密性。然而，关键方面是加密密钥生成器的随机性以及加密和哈希算法的安全性。至于这项工作，从IPSec实现算法中可以看出，我们假定sha1为散列算法3DES，AES作为加密算法是安全的。在应用推荐的解决方案以外，已知的IPSec攻击[23]。与SSH类似，有些机构一直在积极地将漏洞插入到IPSec实施中[24]。

6.结论和未来的工作

本文研究了OpenFlow协议缺乏认证，访问控制和安全通道创建的一些可能的解决方案。正如所主张的那样，实现TLS（如OpenFlow规范推荐）并不能解决网络运营商的配置问题。以增加OpenFlow传输安全性为核心思想，提出了一种新型的已知互联网安全系统的应用。

通过比较TLS，SSH和IPSec，结果表明，就OpenFlow架构的使用而言，每个提议的协议都有其自身的优势（即IPSec中的实现方式，或者TLS中规定的规则）和弱点（可能的攻击）。 The36版权所有（c）IARIA，2015. ISBN：978-1-61208-428-2AFIN 2015：第七届未来互联网论文进展国际会议表明，实施任何提议的解决方案将导致安全性的增加，减少或防止攻击OpenFlow协议。

对于未来的工作，我们计划利用PL-LAB2020实验室[25]来实现每个解决方案，并分析文章中提到的安全问题，同时验证协议的性能。目前正在建设的PL-LAB2020实验室将由六个地理分散的节点组成，这些节点与波兰主要的研究和学术中心相关：

•国家电信学院（NIT），
•华沙理工大学（WUT），
•波兹南超级计算和联网中心（PSNC），
•西里西亚科技大学（SUT），
•格但斯克理工大学（GUT），
•弗罗茨瓦夫理工大学（WrUT），

通过专用的2 * 10Gb / s光纤链路连接。这些节点将配备专门的设备进行多方面的研究，包括软件定义的网络。特别是，至少有三家不同的供应商会有超过30个OpenFlowswitch，还有一些OpenFlow控制器在PL-LAB2020基础架构的5个位置创建不同的技术域（图5）。为了验证所研究解决方案的性能和分析安全性，PL-LAB2020还将包括几台带有数据平面开发套件的服务器和三个位于不同位置的带有10Gb / s接口的网络流量生成器和分析仪。

CKNOWLEDGMENT
这项工作得到了欧洲区域发展基金国家研究与发展中心的支持，批准号：POIG.02.03.01-00-104 / 13，PL-LAB2020项目