SDN知识材料整理(一)
SDN知识材料整理(一)
一、SDN概念及特性:
1、SDN是一种将网络【控制功能】与【转发功能】分离、实现控制可编程的新兴网络架构。这种架构将从控制层从网络设备转移到外部计算设备,使得底层的基础设施对于应用和网络服务而言是透明的、抽象的,网络可被视为一个逻辑的或虚拟的实体
-
SDN的三个主要特征
A:转控分离:网元(网络设备元件)的控制平面在控制器上,控制器负责协议计算,产生流表;而转发平面只在网络设备上。 B:集中控制:设备网元通过控制器集中管理和下发流表,这样就不需要对设备进行逐一操作,只需要对控制器进行配置即可。 C:开放接口:第三方应用只需要通过控制器提供的开放接口,通过编程方式定义一个新的网络功能,然后在控制器上运行即可
-
SDN网络体系架构的三层模型:
[SND网络构架图] -
SND三层模型的负责分工:
-
协同应用层:
这一层主要是体现用户意图的各种上层应用程序,此类应用程序称为协同层应用程序,典型的应用包括OSS(Operation support system 运营支撑系统)、Openstack等。传统的IP网络同样具有转发平面、控制平面和管理平面,SDN网络架构也同样包含这3个平面,只是传统的IP网络是分布式控制的,而SDN网络架构下是集中控制的。 -
控制层:
控制层是系统的控制中心,负责网络的内部交换路径和边界业务路由的生成,并负责处理网络状态变化事件。 -
转发层:
转发层主要由转发器和连接器的线路构成基础转发网络,这一层负责执行用户数据的转发,转发过程中所需要的转发表项是由控制层生成的。 -
SDN架构下的接口:
[SDN接口图]
北向接口 NBI(North Bound Interface)
SDN控制器,业界有很多基于Openflow控制协议的开源的控制器实现,如NOX、Floodlightt等,都能够实现链路发现、拓扑管理、策略制定、表项下发等支持SDN网络运行的基本操作。控制器是SDN网络的核心,其可能存在负载过大、单点失效等问题。【注:核心存在的安全问题】
SDN北向接口是通过控制器向上层业务应用开放的接口,其【目标】是使得业务能够便利地调用底层的网络资源和能力。
北向接口缺少业界公认的标准,成为当前SDN领域竞争的焦点南向接口 SBI(South Bound Interface)
SDN网络架构中。SDN交换机可以忽略控制逻辑的实现,全力关注基于表项的数据处理,而数据处理的性能也就成为评价SDN交换机优劣的最关键指标,因此,很多高性能转发技术被提出,例如基于多张表以流水线方式进行高速处理的技术。
当前最著名的南向接口协议莫过于ONF的【OpenFlow】协议。OpenFlow【解决】了如何由控制层把SDN交换机所需的用于和数据流做匹配的表项下发给转发层设备的问题Restful接口
Restful接口为控制器与上层APP的北向接口,开放的API、设备私有接口,所有满足rest架构的互联网软件架构都是restful。
Rest为“表现层状态转化”,表现层就是资源的表现,即rest是被访问的资源(文本,图片,音乐,视频等),从一种形式的状态迁移到另一种形式的状态,本质就是一种互联网资源访问的协议OpenFlow接口
OpenFlow接口是控制器与下层转发器之间的一种基于芯片的接口协议。OpenFlow协议基于TCP/IP,用于转发器与控制器之间的通信BGP接口
BGP接口是在BGP协议基础上添加一些BGP路由属性(比如Additional Path属性和BGP Flowspecification属性),用于下发BGP的一些路由特性,从而使得IDC数据中心出口路由器根据这些特性实现流量调优PCE接口:
PCE接口用于控制器根据网络可用带宽计算出流量工程路径,用于数据中心AS内部的TE隧道的建立
运营商网络已经大规模部署了传统分布式网络,不能在较短时间内升级到SDN网络,与传统网络互通就是必要的。SDN控制器必须支持各种传统的跨域路由协议,以便解决和传统网络互通问题
东西向协议是必须的,在SDN控制器上运行东西向协议,通过简单的修改或升级控制器程序就能提供新业务。另一方面,东西向协议为SDN控制器跨域互联及SDN控制器分层部署提供了接口。
-
2、SDN与传统网络对比:
- 传统的网络及其设备只能配置,不能实现编程
- 网络的分布式控制与管理架构带来的制约
A:传统网络:
【1】传统网络一开始就是分布式的网络,没有中心控制节点,每台网络设备自己决定是否转发,所以没有整体的观念。
【2】网络的互通依靠网络协议,不同的运营商之间运用约定俗成的协议完成数据互通,这样限制了运营商的想象力,约束了发展速度。
【3】传统网络的更新部署采用的是“打补丁”的方式,存在部署速度慢,新旧设备共存的问题,所以新的设备和服务必须兼顾之前的功能和服务。<旧设备存在的安全漏洞和问题将会长期侵蚀网络的安全>
【4】传统的网络无法根据用户个性化的需求提供网络服务,因为服务就那几种,一旦现有的网络无法满足一定基数的用户,就需要上升到修改协议的层次。繁琐的更新过程注定了网络升级的速度缓慢。
【5】传统网络,协议的修改为了兼顾之前,必须在现有的基础上改进,这样就束缚了网络升级的思路,不利于网络的发展。
【6】传统的网络现在因为用户需求的提高,发展的越来越复杂,涉及到各种技术,协议越来越多,这给网络的配置带来了困难,网络维护人员的培养过程比较困难。
【7】传统网络优点:协议本身和网络设备提供商无关,标准统一。
B:SDN网络:
当前SDN网络的形式:
a:一个控制器(或者集群):负责整个网络的拓扑,流量信息,计算流量转发的路径,通过OpenFlow协议将转发表下放给交换机。
b:多个交换机(或者叫转发器):只负责接收控制器的转发表,执行转发功能。
c:这样就实现了控制层从传统网络的单个设备上分离,集中到了一个控制器(或者集群)上。
【注:支持SDN和openflow协议的交换机又称转发器.】
网络的部署形式:
a:Underlay网络:
所有流量信息,路由的计算,转发行为全部由控制器层决定,然后通过OpenFlow协议下放转发表给各个交转发器,转发器仅仅执行转发动作(没有单独的控制层)
b:Overlay网络:(过渡)
这种网路的转发器还只能叫做交换机,不支持OpenFlow,这时候需要利用隧道技术将数据报文进行封装或者解封装,让报文可以走传统网络,但其实内在已经是虚拟化。(常用技术Vxlan,GRE,NVGRE等)
c:总结:
Overlay的存在只是一种过渡时期的手段,这种方式可以让两种网路共存,但是是以牺牲网络性能为代价的,最终会向Underlay完成进化
SDN的控制层:
不再是没有中心的分布式,而是能从更高的层次看整个网络,并通过软件实现控制网络的行为。更方便且智能
而控制网络的【软件】可以不再是网络运营商提供,这种【软件】用户可以自己实现并且高度的个性化,这将可以定制个人专属的网络
SDN网络唯一标准化的是控制器与转发器的通信接口,即OpenFlow,它不是传统意义上的网络协议,只是一个接口
至于控制器怎么控制,转发器怎么转发,SDN还都是空白
SDN的现阶段:
ovs已经成为转发器实现事实上的标准,而控制器则是百家争鸣,有ODL、ONOS、AC、Ryu等。各种控制器的实现也有不小的差异,控制原理也都不同,这就对运维人员带来了挑战。在传统网络时代懂得了协议就懂得了网络,而在SDN时代,控制器才是网络的核心,只有弄懂控制器实现原理,才能懂得网络。
【控制器的技术难点,安全隐患,漏洞将对整个网络影响巨大
在现阶段,OpenFlow作为接口,网络上传递的报文还是按照传统网络时代定义的格式进行封装,而控制器现阶段能做的也仅是对报文封装的字段进行修改。而下一阶段,当P4或者华为的POF作为接口时,网络将彻底变革,用户不仅可以控制转发行为,还能按需定义报文封装格式,而不再局限于mac、ip等等。虽然更灵活,但是各个局域网络的实现可能都不相同,对网络运维人员来说可能会更困难,换一个网络可能就需要学习一套新的规则。但是这也真正体现软件定义的魅力,控制器的控制形式势必会更加多种多样,网络也会进入一个新的轮回】_
【注: OVS是一个高质量的,多层虚拟交换机(网络分层的层),其目的是让大规模网络自动化可以通过编程扩展,同时仍然支持标准的管理接口和协议:NetFlow. SFlow 等,并且它还支持多个物理机的分布式环境
虚拟交换:就是,利用软件的方式形成交换部件,所以也叫软件交换机,跟传统的物理交换机相比,虚拟交换机同要具备很多有点:
1.配置灵活,因为是软件实现的,一台物理服务器上可以配置数十太或者数百台虚拟交换机,而且端口数目可以灵活选择
2.成本低廉,通过软件的方式可轻易达到10Gbps的交换速度
所以OVS是一个虚拟交换机,可以用来组成虚拟网络,虚拟机还有其他的类型不同的架构。】
【Open vSwitch的官方定义:Open vSwitch是一个具有工业级质量的多层虚拟交换机。通过可编程扩展,可以实现大规模网络的自动化(配置、管理、维护)。它支持现有标准管理接口和协议(比如netFlow,sFlow,SPAN,RSPAN,CLI,LACP,802.1ag等,熟悉物理网络维护的管理员可以毫不费力地通过Open vSwitch转向虚拟网络管理)。】_
3、ping的流程:
A:传统的网络:
传统网络的路由器之间可以通过ping或者tracert看到路由器和路由器之间的各种信息关联。因为传统路由器之间存在两个关键字段:下一跳和路由前缀。各个路由器之间不论是由协议还是手工配置,都会连接到关联的另外路由器,整个网络就是通过这一个一个连接的路由器互通的。也正因为这样,传统的网络的规划,设计,部署都需要设计整个拓扑,路由协议,ip和端口等等,整个网络的构建和维护都需要人工的干预。
B:SDN网络:
控制器通过ovs上报的packetin消息触发处理流程,计算好路径后,通过openflow下发给所有转发器,打通链路,主机之间能够互通。转发器上没有控制功能,之间也没有交互,转发器最基本动作就是对收到的报文上报控制器,一切的逻辑行为都由控制器负责
转发器上需要绑定物理接口,方便OVS统一管
SDN网络中的匹配和动作行为比传统网络要丰富的多,不仅仅是匹配前缀,转发下一跳那么简单了。但是SDN网络设备的用户界面信息表现不直观,相比传统网络还有很大的提升空间。
4、总结:
传统网络已经经过半个世纪的发展,凝聚了无数人的智慧和心血,但是由于天生的缺陷,导致在很多场景上心有余而力不足,并且越来越复杂。SDN虽然诞生没多久,但是已经表现出非常强的生命力。传统网络在安全、可靠性、可维护性和性能上还有很大的优势,但是随着SDN相关设备的发展,这种优势必然会越来越弱,而SDN依靠自己的优势,一定会不断占领传统网络的领地。而在SDN内部,overlay网络相比underlay网络,简化不足,复杂有余,在传统网络的基础上叠加虚拟化,比传统网络更复杂。overlay之于underlay,就好比ipv4之于ipv6,要从根本上解决问题,underlay必然是最终的选择。
二、关于Open vSwitch(ovs):
a:概述:
Open vSwitch的官方定义:Open vSwitch是一个具有工业级质量的多层虚拟交换机。通过可编程扩展,可以实现大规模网络的自动化(配置、管理、维护)。它支持现有标准管理接口和协议(比如netFlow,sFlow,SPAN,RSPAN,CLI,LACP,802.1ag等,熟悉物理网络维护的管理员可以毫不费力地通过Open vSwitch转向虚拟网络管理)
b:模块介绍:
ovs-vswitchd :核心模块,实现交换功能的守护程序(daemon),和Linux内核模块一起,实现基于流的交换。
ovsdb-server :提供轻量级数据库查询服务。其保存了整个OVS的配置信息,包括接口,流表,VLAN等。ovs-vswitchd从其查询配置信息。
ovsdb-tool: 不通过ovs-server就能直接操控数据库。
ovsdb-client: 直接通过ovs-server数据库操作。
ovs-brcompatd :让 ovs-vswitch 替换 Linux bridge,包括获取 bridge ioctls 的 Linux 内核模块。
ovs-dpctl :dapapath control. 用来配置 switch 内核模块,可以控制转发规则。
ovs-vsctl :获取或者更改ovs-vswitchd的配置信息,此工具操作的时候会更新ovsdb-server数据库。
ovs-appctl :openvswitch apply control, 发送命令来运行相关 daemon(很少使用)。
ovsdbmonitor GUI 工具,用于显示 OVS 数据库中的相关数据
此外, OVS 也提供了支持 OpenFlow 的特性实现,包括:
ovs-openflowd:一个简单的 OpenFlow 交换机。
ovs-controller:一个简单的 OpenFlow 控制器。
ovs-ofctl : openvswitch openflow control,用来控制OVS作为OpenFlow交换机工作时的流表内容。
ovs-pki : OpenFlow 交换机创建和管理公钥框架;
ovs-tcpundump: 实现类似tcpdump 的抓包分析功能
ovs-vswitchd是Open vSwitch的核心模块:
vswitchd 模块主要包括 bridge、ofproto 等模块。作为主模块,负责解析和执行其他各个 ovs 命令。vswitchd 的主要功能就是不断检测并调用所有 bridge 上的ofproto,执行其上的处理函数。
ovs-vswitchd.c中有main函数,分析vswitchd可以从这里开始,这里包含以下头文件,其中大部分都是与业务无关的代码,其中与业务有关的也就bridge.h、dp if.h、netdev.h、openflow/openflow.h、ovsdb-idl.h、vconn.h、lib/vswitch-idl.h。
#include "bridge.h" //the bridge module,需要访问ovsdb-server获取配置信息,与ofprotos和ofproto-dpif也有些关系。
#include "command-line.h"
#include "compiler.h"
#include "daemon.h" //守护进程管理模块
#include "dirs.h" //目录管理模块
#include "dpif.h" //dpif, the DataPath InterFace.ovs-vswitchd使用这个接口与内核模块通信,ovs-dpctl也会使用
#include "dummy.h"
#include "memory.h"
#include "netdev.h" //Generic interface to network devices ("netdev"s).用来管理网络设备的模块
#include "openflow/openflow.h" //openflow协议规格定义
#include "ovsdb-idl.h" //Open vSwitch Database Interface Definition Language (OVSDB IDL).应该是访问ovsdb-server进程的接口
#include "poll-loop.h" //High-level wrapper around the "poll" system call.poll系统调用的封装模块
#include "process.h" //Starting and monitoring subprocesses.进程监控模块
#include "signals.h" //signals系统调用的封装模块
#include "simap.h" //数据结构定义和hash map的封装操作接口模块
#include "stream-ssl.h" //SSL安全网络通信封装模块接口
#include "stream.h" //网络通信封装模块接口
#include "svec.h" //SVEC数据结构操作模块,SVEC是什么?
#include "timeval.h" //计时相关系统接口封装模块
#include "unixctl.h" //Unix domain socket control connection.UNIX相关网络通信模块
#include "util.h"
#include "vconn.h" //virtual connections to OpenFlow devices.
#include "vlog.h"
#include "lib/vswitch-idl.h" //自动生成的文件,应该是Open vSwitch Interface Definition Language,可能是openflow协议的具体内容实现
c:Open vSwitch相关术语
1)Packet (数据包)
网络转发的最小数据单元,每个包都来自某个端口,最终会被发往一个或多个目标端口,转发数据包的过程就是网络的唯一功能
2)Bridge (网桥)
Open vSwitch中的一个网桥就是一台以太网交换机交换机,可以创建一个或者多个Bridge设备。其功能是根据一定流规则,把从端口收到的数据包转发到另一个或多个端口
3)Port (端口)
端口是收发数据包的单元,和物理以太网交换机的端口概念类似。Open vSwitch中,每个端口都属于一个特定的网桥。端口收到的数据包会经过流规则的处理,发往其他端口;也会把其他端口来的数据包发送出去。Open vSwitch支持的端口有以下几种:
【Normal Port:】 用户可以把操作系统中的网卡绑定到Open vSwitch上,Open vSwitch会生成一个普通端口处理这块网卡进出的数据包。
【Internal Port:】 当设置端口类型为internal,Open vSwitch会创建一快虚拟网卡,此端口收到的所有数据包都会交给这块网卡,网卡发出的包会通过这个端口交给Open vSwitch
当Open vSwitch创建一个新网桥时,默认会创建一个与网桥同名的Internal Port
【Patch Port:】 当机器中有多个Open vSwitch网桥时,可以使用Patch Port把两个网桥连起来。Patch Port总是成对出现,分别连接在两个网桥上,在两个网桥之间交换数据。
【Tunnel Port: 】隧道端口是一种虚拟端口,支持使用gre或vxlan等隧道技术与位于网络上其他位置的远程端口通讯
4)Interface (iface/接口)
它是连接到 Port 的网络接口设备。Open vSwitch通过Interface与外部交换数据包。在通常情况下,Port 和 Interface 是一对一的关系, 只有在配置 Port 为 bond 模式后,Port 和 Interface 才是一对多的关系。一个接口就是操作系统的一块网卡,这块网卡可能是Open vSwitch生成的虚拟网卡,也可能是物理网卡挂载在Open vSwitch上,也可能是操作系统的虚拟网卡(TUN/TAP)挂载在Open vSwitch上
5)Flow (流)
流定义了端口之间数据包的交换规则。每条流分为匹配和动作两部分,匹配部分选择哪些数据包需要可以通过这条流处理,动作决定这些匹配到的数据包如何转发。流描述了一个网桥上,端口到端口的转发规则。
比如我可以定义这样一条流:
当数据包来自端口A,则发往端口B
来自端口A 就是匹配部分,发往端口B 就是动作部分
流的定义可能非常复杂,比如:
当数据包来自端口A,并且其源MAC是aa:aa:aa:aa:aa:aa,并且其拥有vlan tag为a,并且其源IP是a.a.a.a,并且其协议是TCP,其TCP源端口号为a,则修改其源IP为b.b.b.b,发往端口
6)Datapath(数据路径)
由于流可能非常复杂,对每个进来的数据包都去尝试匹配所有流,效率会非常低,所以有了datapath。Datapath对流进行缓存,把流的执行结果保存起来,当下次遇到匹配到同一条流的数据包,直接通过datapath处理。【根据流进行数据转发
7)Controller
OpenFlow 控制器。OVS 可以同时接受一个或者多个基于 OpenFlow 的控制器的管理
8)Flow table
每个 datapath 都和一个"flow table"关联,当 datapath 接收到数据之后,OVS会在flow table 中查找可以匹配的flow,执行对应的操作,例如转发数据到另外的端口。
三、关于OpenFlow:(南向接口协议之一)
OpenFlow模型的指导思想是:
底层的数据通信(交换机、路由器)是“简化的”,并定义一个对外开放的关于流表FLowTable的公用API(应用程序接口),同时采用控制器来控制整个网络
a:OpenFlow Controller:
用于控制OpenFlow Switch,计算路径,维护状态和将信息流规则下发给交换机(转发器)
b:OpenFlow Switch:
从OpenFlow Controller控制器接收命令或者流信息,以及返回状态信息。OpenFlow Switch基于流表并根据流规则进行转发、处理数据
c: 术语解释:
“Flow”指的是一组具有相同性质的数据包。
OpenFlow协议是控制器和转发器之间的控制协议。
交换机与控制器之间可以通过加密的OpenFlow协议通信。
OpenFlow交换机是数据平面,基于Flow Table(流表,转发表)进行数据转发,并负责网络策略的具体执行。
OpenFlow Controller是控制平面设备,负责生成OpenFlow交换机上的Flow Table,以及对Flow Table的更新和维护。
OpenFlow Switch的基本组成:
1)Flow Table:保存对每一个流的定义及相应处理行为。
2)安全网络通道:连接交换机和控制器,用于传输控制信令。当一个新数据包第一次到达交换机时,交换机通过这个隧道将数据包送往控制器进行路由解析。
3)OpenFlow协议:一套公开标准接口,用于读写Flow Table的内容。
四、关于SDN的安全隐患:
“其中一个最大的安全问题便是,这仍然是一款相对不成熟的技术,所以我们并不确切地知道企业可能会遭遇什么类型的安全风险问题。”位于芝加哥的伊利诺伊大学公共卫生学院的IT主管弗兰克·塞文表示说
安全风险在【控制平面】内被放大了,因为“其在SDN环境成为了一个【单一故障点】,并在很大程度上严重依赖于自动化。”安全技术供应商Gemalto公司的高速加密产品经理Stan Mesceda如是说.
SDN挑战1:接口/协议的标准化。SDN标准体系是否要统一或能够统一还有争论,ONF开始强调Drive,对于南向接口不再局限于Openflow,北向接口以RESTFUL为主,以IT的思路为主,采用模型/模板的方式,每个厂商公布自己的模板就可以实现互通和控制,SDN实现上,VMware和Openstack各成体系,类似于IOS和安卓。
SDN挑战2:互操作性。SDN相关标准还有待完善,各厂商支持程度也有差异,实现互操作有相当困难,于此同时中国供应商众多,更加重视互操作性能。
SDN挑战3:安全性问题。SDN的集中控制方式及开放性将使得控制器的安全性成为潜在风险,需要建立一套隔离、防护盒备份机制来确保其安全稳定运行,包含了控制器本身的安全问题、控制器和应用层之间的安全问题、控制器和转发设备之间的安全问题。
SDN挑战4:关键性能。现有ASIC芯片架构无法满足SDN对性能的需求,基于OpenFlow的专用芯片架构及实习方案还有待开发。SDN组网关键指标(流表容量、流表学习速度、流表转发速率、转发时延等)在不同厂商设备上差异极大,无法商用,入流表容量从几K道几百K不等,流表学习速度从2秒/千条到20秒/千条。
SDN挑战5:控制器实现方式。SDN控制器的种类多样化,SDN控制器是SDN的核心,在利益驱使下,SDN控制器受到产业链中的不同角色的激烈争夺,涌现出众多控制器,控制器之战将在很长一段时间内一直存在;云数据中心、接入、光和IP、骨干网和城域网都可能出现专属的控制器,且这些控制器协同也有待研究。SDN控制器在网络不同领域的层次架构不一致,例如在数据中心采用单层架构、在移动核心网中采用三层架构,难以形成明确的网络架构。SDN控制器接口标准不统一,南向接口除了支持openflow外,还存在多种接口协议,如部分厂商的设备采用的BG、SNMP等,北向接口方面,ONF也明确了不同的场景将使用不同的北向接口,东西向接口的研究工作刚刚开展,尚存在很多争议和不确定性
A:主要挑战
1)集中式的控制器可以实时获取网络全局结构,设计之初并未将安全问题作为重点内容,目前针对NOX和Floodlight等开源控制器提出了部分安全扩展方案,但只针对SDN中某个具体的安全威胁进行设计,尚无完善的控制器安全防护策略
2)可编程性提供了便捷的攻击渠
3)交换机对控制器的请求增加了遭受DDoS和Dos攻击的可能性,同时整个网络状态和配置的动态变化,使得攻击者可以伪装来自控制器的流规则,从而改变流量路径绕开SDN中部署的安全设
B:与传统网络对比
主要的安全问题体现在两个方面
1)对数据流的控制方式不同:传统网络中,数据被强制通过安全设备;而SDN是流规则驱动的,数据流是否通过安全设备并不能具有自主决定
2)对网络安全态势信息获取方式不同:传统网络中,管理员要讲请求信息发送到多个设备后,在对收到的状态信息进行综合评估后,才能得到当前网络的安全态势信息。而SDN中,控制器已经包括网络的全局视图,能够实时获取全网的状态信息,但这种方式也很容易遭受攻击,攻击者通过控制器可以得到全网的安全状态信息从而进行有效的网络攻
C:典型的安全问题分析:
1)OpenFlow协议安全性
依据OpenFlow协议,控制器与交换机之间通过安全通道进行连接,安全通道采用安全传输层协议TLS对消息进行加密和认
2)各层/接口面临的安全问
a:应用层:
OpenFlow应用程序、安全服务类应用程序及一些其他的第三方应用程序会制定一些流规则,而这些参与流规则制定的应用程序一旦遭遇篡改或身份假冒等问题,就会对底层数据转发造成威胁。
b:控制层:
一旦攻击者接入控制器,将有能力控制整个SDN网络,典型安全问题是集中式管控带来的单点故障问题,主要体现在两个方面:Dos/DDoS攻击,以及控制器在逻辑上或物理上遭到破坏。除此之外还面临非法访问、身份假冒、恶意/虚假流规则注入以及控制器自身的配置缺陷等
c:基础设施层:
对控制器下发的流规则绝对信任。主要威胁包括:恶意/虚假流规则注入、DDoS、Dos攻击、数据泄露、非法访问、身份假冒、交换机自身配置缺陷等。除此之外,还可能面临虚假控制器的无序控制指令导致的交换机流表混乱等威胁
d:南向接口:
主要是指由OpenFlow的脆弱性而引发的安全威胁。
e:北向接口:
种类繁多暂无统一规定,且北向接口的开放性与可编程性使得更容易被攻击。主要问题是非法访问、数据泄露、消息篡改、身份假冒、应用程序自身的漏洞以及不同应用程序在合作时引入的新漏洞等
D:安全机制:
SDN安全控制器的开发
演进式安全控制器:
在现有的开源控制器的基础上,改进或开发部署新的安全模块,如FortNOX、SE-Floodlight等
FortNox:
在NOX控制器上分别增加了基于角色的数据源认证模块、状态表管理模块、流规则冲突分析模块和流规则超时回调模块等功能
1)基于角色的数据源认证模块:
主要用于对每个流规则进行签名,并为候选流规则指定相应的特权类别
2)状态表管理模块:
主要对NOX控制器总流表中流规则的插入、删除等操作进行管理
3)流规则冲突分析模块:
可以根据NOX控制器当前总流表中流规则的状态,对每一个候选流规则进行评估;若流规则冲突分析模块提供的检测结果显示某个候选流规则与总流表中的流规则无冲突,则该候选流规则奖杯转发给SDN交换机,同时被更新到NOX控制器的总流表中,并由状态表管理模块对其进行管理
4)流规则超时回调模块:
当SDN交换机流规则过期时,FortNOX将启动流规则超时回调接口模块,对NOX控制器的总流表进行更新
SE-Floodlight:
继承了FortNOX安全内核的基本设计思想,并对这些模块进行扩充,添加了程序证书管理模块、安全审计子系统、权限管理等新安全模块
1) 程序证书管理模块:主要对与控制面交互的应用程序及其身份凭证进行审核与认证
2)安全审计子系统:主要负责对与控制其安全相关的事件进行审计和跟踪,如应用程序身份认证与授权、流规则修改、流规则冲突处理、交换机配置信息变更、控制器配置信息变更、审计系统的启动与关闭等
3)权限管理模块:主要对数据面和控制面之间除流规则以外的交互消息进行管理,该模块仅允许由管理员授权的应用程序访问控制面资源
存在问题:多数成果针对的是特定控制器,不能实现不同控制器之间的平滑过渡,因此在移植和推广方面存在问
革命式安全控制器:
在SDN控制器的设计和开发之初将安全性作为核心问题之一进行考虑,开发全新的、内嵌安全机制的SDN控制器
RoseMary:
主要由数据抽象层、RoseMary内核、系统库和资源控制器四部分组成
1)数据抽象层:主要用于收集数据层中各种网络设备的请求信息
2)资源监控模块:主要对RoseMary中正在运行的应用程序及其行为进行监控,并及时终止具有异常行为的应用程序
3)RoseMary内核:细分为资源管理模块、安全管理模块、系统日志管理模块和内核程序区。为网络的应用层提供基本服务,同时还为应用程序提供各种类型的系统库
PANE:
内嵌安全机制,用于解决SDN中不可信用户访问请求之间的冲突问题。控制器允许管理员根据网络资源制定相应的访问控制策略,通过提供的API接口,终端用户可以动态、自助地请求网络资源
存在问题:
各个SDN标准化组织尚未发布控制其设计方面的安全标准与规范,同时,一些已有的控制器已经在实际应用中得到部署,而革命性安全控制器的开发和部署还处于实验室测试阶段,并未得到大规模的部署和应用。而分布式控制器面临的安全通信、资源调度等方向都存在诸多挑战,通信的东西向接口也没有明确的安全标
E:控制器可组合安全模块库的开发和部
FRESCO:允许开发人员在控制器上创建新的安全模块,且互相之间可以组合并协同合作,从而加快了控制器安全模块库的设计与开发。集合了大量API接口,并与传统安全工具进行通信,而且部署与NOX之上,由应用层和安全执行内核两部分组成。研究人员可以自己编写具有安全监控和威胁监测功能的Module安全模块,不同的Module模块用于提供不同的安全功能,这些模块可以被共享或者组合以提供更加复杂的安全防护功能,但具体安全强度还没有完善的评估机制,同时不同的安全模块组合后是否会存在新的安全漏洞也有待检
控制器Dos/DDoS攻击防御:
解决方案思路:
基于流量变化特征对控制器Dos/DDoS攻击行为进行检测
基于连接迁移机制对Dos/DDoS攻击进行防范
基于STRIDE、UML等威胁建模方法,对SDN中潜在的DoS/DDoS攻击行为进行评价和预
流规则的合法性和一致性检测:
主要思路:
基于应用程序的角色和优先级,对流规则的等级进行划分
采用形式化和数学分析方法,对不同流规则之间的一致性和冲突性进行分
北向接口的安全性
应用程序安全
F:未来方向
面向安全的新型控制器/网络操作系统的设计与开发
控制器跨域协同安全通信问题
北向接口安全协议标准化
控制器Dos/DDoS攻击检测和防范技术
by 久违 2019.12.18