《NETHCF:Filtering Spoofed IP Traffic With Programmable Switches》论文阅读笔记
总的来说,本文提出一种可以借助可编程交换机(数据平面+控制平面协调工作)来对欺骗性IP流量进行过滤(通过HCF机制过滤)的系统架构.
一. 引子
DDos攻击中常用的手段是伪造不合法的IP源地址,向服务器端发送大量的请求,进而使得服务器在建立连接时,由于始终不能完整握手阶段的返回,一直占用资源并等待着,进而导致服务器出现资源耗尽而瘫痪的现象.
因此为了对抗这种伪造不合法的IP的方法,有研究者提出了HCF方案,这是一种根据跳数来对不合法IP进行过滤的方案.之所以考虑根据跳数进行过滤,是因为跳数着一变量是基于攻击者到服务端的路由路径所决定的,不会像普通的报文子段那样易于修改.下面的图中展示的就是一个简单的HCF机制的算法描述:
可见HCF机制是通过检查TTL来进行的计算的.
此子段表示的是,一个数据包处于当前的路由器时,可以继续进行转发的最大路由处,每当经过一个路由器转发就会使得TTL值减一,如果已经到了零,就会丢包.因此可以通过计算起始点的TTL之差得出中途所经过的跳数.
关于HCF模式的发展状况,HCF模式在此paper的成果之前,该模式主要部署在网络协议栈中,尤其是linux系统的生态里.因此单纯地借助有HCF机制支持的Server就可以达到一定的HCF过滤效果.但是这种模式是存在一定的问题的.这也是文章后面的主要动机.
除此之外,paper中还提到了可编程交换机的发展.虽然,可编程交换机的功能已经强大了很多,可以运行更加复杂的算法和逻辑.然而在可编程交换机运行HCF机制,充满了困难,首先由于HCF条目数目太多所导致的存储空间紧张的问题,另外一点在于对于处于变化的网络环境中,维护HCF条目的相关的变量是需要进行比较复杂的逻辑的,这会给交换机的计算机资源带来很大的负担.这也就是文章中所说的内存和计算资源的局限.
二. 背景与动机
1. 现有HCF模式的弊端
这篇paper在对现有的HCF模式进行批判和探索更优解的时候,采用了一种循序渐进的思考方式.我认为其思考线索,主要在于两个维度:集中/分散和服务器/交换机.我对这两个维度进行进行简单地说明,前者是说,关于执行HCF过滤机制,应当使得每个服务器各自地运行自己的HCF来进行过滤,还是考虑在欺骗性IP流量进入到Servers之前的某个交汇点进行过滤?后者则是说,应当将HCF部署在服务器上还是交换机上?paper从这两个维度出发,最终得出了NETHCF的设计目标,也就是一种“集中+交换机”的HCF模式.
(1) 分散 && 服务器
这正是前面所提到的当前最最流行的HCF模式.
作者对于这种模式的批判主要在于以下三点:
服务器上网络带宽的浪费.
部署冗余及对内存,CPU等资源的浪费.
系统中负载均衡降低预建立的效率.
下面是我对于以上几点的理解.关于第一点是比较好理解的,因为我们使用HCF机制只能使得欺骗性IP流量在Server端被过滤掉,也就是说欺骗性IP流量还是占用一定的Server上的带宽,因此作者就想,能不能设计一种提前在Server上就被过滤的机制.
关于第二点,部署冗余问题的理解,因为HCF机制会在内核(内存)中维护一个个的HCF条目,然而HCF的运行在这些服务器上是独立运行的,因此在整个系统之中,如果要确保HCF机制被有效运行,就要保证这些服务器对于这些IP的HCF条目都要有一份,因此整个系统中对于同一个IP的HCF条目相当于有了许多份,这显然是一种冗余的问题.此外,对于内存和CPU的浪费更不必说,HCF条目需要安置在内存上,CPU需要额外地进行HCF算法的执行.
至于第三点.结合paper中给的图就可以很清楚地说明:
HCF的预收集
类似于缓存系统中的预热功能.如果不进行HCF进行预收集的话,那么HCF机制将会处于一个真空期,也就是HCF条目处于一种较为空缺的状态,因此IP过滤的效率将会大打折扣.所以在正常投入使用前,会先将运行HCF的服务器处于收集的状态.至于收集的效率,处理流量的密度和收集的效率往往是成反比的.对于一些访问比较热门的服务,所到来的流量也大,因此往往较短时间就能收集到比较全面的IP,对于一些比较生僻的小网站,可能几个月也收集不全.
就如图中所示的那样,虚线是理想的情况.下面的几个就是在有负载均衡机制下的系统中,不同数量的端主机setting-up的情况.正如在上面所说的,处理流量的密度和setting-up的效率是成反比的,因为一个Server所到来的流量是经过上一条交换机分摊之后的结果,因此所经过流量密度会减小.
(2) 集中 && 服务器
结合上面模式的分析,似乎上面几个问题的根源在于HCF处理的分散性.所以作者就自然而然想到,如果能将HCF从一个个的服务器们解放出来,集中在一个个Server之前进行处理.就如同下面的:
因此paper也提到了这种“集中+服务器”的方案,
其实到了这里,我也有在思考,为什么没有直接跳跃到“集中+交换机”的方案?我个人认为这是因为当时还没有在交换机运行HCF机制的方案,此外,工程师在解决问题时都会有一种“尽量不重复造轮子”习惯.因此也就首先考虑,仍然利用现有的轮子,只是将“分散”变为“集中”,而非进行更大的跳跃.
但是考虑这一种中间盒方案,如果直接借助一个服务器,运行HCF机制,这给这个服务器带来巨大的负担,处理能力是有限的,此外单个主机一旦宕机,该机制就会作废.因此这个中间盒往往是一个集群,以一种分布式系统的模式运行一个巨大的中间盒.
分布式系统的烦恼
分布式系统是一种需要多个主机借助网络(RPC)通信进行协同工作,进而完成一种服务的系统模式.相比单机系统,其设计和运行都需要考虑许多额外的棘手的问题.
- 可靠性.单个主机宕机是偶然的,但在一个集群中,宕机几乎就是必然事件.因此必须设计一定的机制使得系统中存在故障的情况下,仍然能够维持有效的服务.
- 一致性.为了保障数据的可靠性(完整),往往会在整个系统中对数据维护多个副本,然而面临复杂的读写情况,我们需要维护多个数据的副本能够同时有最新的结果.
此外,由于这些比较复杂的问题,分布式系统会设计一些更加复杂的机制,耗费更多的网络带宽,带来一定的延迟.这些都是分布式系统的代价.
即使接受这种方案带的额外开销,有一点也是致命的软肋:服务器端这种软件形式的处理方式效率及其有限.其处理速率和延迟是无法忍受的.关于其延迟,后面测评中的一个图可以很好的说明问题:
(3) 集中 && 交换机
至此,考虑到服务器处理包的效率有限,那么谁是最擅长处理网络数据包的呢?那还得是交换机.单论数据包的路由和转发,交换机中ASIC的处理效率远高于服务器中的CPU.
我对于交换机ASIC的简单理解,交换机ASIC在计算方面属于专才,专注于对于网络数据包的处理.而一般的通用计算资源,比如说CPU等,其对于网络数据包的处理是比较逊色的.
因此,至此考虑将HCF模式部署在一个交换机中,就如下展示的一样.
最后也简单地总结一下,paper中对于这三种方案的对比:
paper中对于可编程交换机能力的强调:可以处理高吞吐量,低延迟和抖动的数据包.
2. 可编程交换机的局限
关于其局限性主要在于两点,一个是内存另一个是计算.
关于内存,paper中有比较详细的描述,对于HFC中的IP2HC条目,仅仅借助可编程交换机中的内存资源根本就存储不全.其实使用一定程度的哈希压缩方案,也因为哈希冲突容易影响HCF模式的可用性,并且也不能缓解内存资源的紧张.
关于计算资源,我想主要是由于交换机ASIC的特点所导致的吧,就如前面所说的那样,交换机ASIC在计算方面是专才而非通才,对于一些因为网络动态变化而导致的IP2HC条目内容的更新(比如说网络路由线路发生了变化),以及由于压缩机制所带来的额外的计算.这些都会给交换机ASIC带来了沉重的负担.
三. 核心设计
(1) 控制平面和数据平面互补的缓存模型
这种模型的提出,针对的是交换机本机上内存资源紧张的问题.前面提到,交换机本身不太可能将所有需要的IP2HC条目保存,paper中确实也接受了这个现实.但是paper中想到了利用控制平面这个大后方,可以只让数据平面只保存一部分,而控制平面维护了全局视角的IP2HC条目.简而言之,这是一种将数据平面作为控制平面缓存的方案.
读到这里,我也在尝试挑刺,质疑这种方案的可行性.但是paper中似乎都做出了一些解释,我感觉的确无懈可击.
既然作为一种缓存系统,那么当数据平面miss时就需要访问控制平面,然而这带来一定的额外开销和延迟,这篇paper哪来的自信,可以保证这种开销不会太大呢?
根据以往学习过的缓存系统的使用条件,我认为对于数据的访问应当具有一定的局部性才能高效地发挥缓存系统的优势.但是paper中提到了一种IP访问的“heavy-tail”的特点.大体上就是说,IP的访问热度集中在一小部分IP.因此维护一小部分映射就可以服务于大多数合法的网络流量.因此,像miss的现象应该不会过于频繁.
其中paper中描述的结构如下:
既然可以讲数据平面和控制平面互补的部分视为一个缓存系统,那么这个系统的设计需要考虑哪些缓存系统中的共性问题?
- 存储数据条目的内容及其存储的数据结构.
- cache和mirror之间的置换依据及策略.
- 数据条目更新及一致性等问题.
后面的设计内容主要也是围绕着这几个问题,但是在一些细节的设计上,需要结合一些网络和安全系统的特性,我认为这些也就是理解其设计的难点所在.
此外,值得一提的是,该系统会被划分为两种工作状态,一种是学习状态另一种是过滤状态.之所以要划分两种状态,是为了避免时时刻刻处理miss而导致的额外延迟.
(2) 数据条目及其数据结构
这一部分回答了上面所提到的问题.paper中主要回答了控制平面上的情况.
简而言之,控制平面上所展现的是一种“表+树”的数据结构.
树对于节省存储空间的优势
关于我对树这种数据结构的理解,我认为树对于表示一些具有层级特性(比如说IP地址,页表项等)的数据方面相对于一般的表会有明显的优势.对于表这种数据结构,对于一些有共同前缀的数据,毫无疑问会讲这些“前缀”存储多次,造成冗余.然而树可以避免这种现象,不同条目的共同前缀在树中只会对应一份,剩余不同的部分则对应该共同前缀节点下的不同孩子.
上面是我对于树这种数据结构对于表示IP地址这种具有层次性特点的优势.但此外,我认为其优势不仅仅如此,树这种结构相比表,更便于合并与分离.为什么需要进行合并与分离的操作呢?首先我们知道,合并与分裂的操作肯定是有利于节省空间的.其所依据的经验就是,对于一些具有共同前缀,尤其是共同前缀的IP地址,往往在网络中的位置接近的(比如说处于同一个局域网之中),因此有大量的共同前缀的IP也具有相同的跳数值,因此可以考虑合并成同一项,这对应了合并到同一个父节点上,这种现象很常见因此,因此可以节省大量的空间.
关于数据平面,其中的数据结构则是一个表,及匹配动作表.如下所示:
至此,我们可以发现,控制平面上的压缩机制最终也造福了数据平面,因为数据平面上条目中的IP/IP前缀使得一个条目可以处理多个IP,倘若没有控制平面费尽心思地做压缩机制,也就不会有数据平面上的效果.
(3) 适应网络动态
我觉得这一部分是整个paper中最最难以理解的,理解了这一部分,也就理解了前面所提到的“共性与特性”问题,尤其是一些和网路及安全情境下的细节问题.
a. 条目的更新
这个问题主要考虑,在考虑对抗的情景下,如何判断一个IP是否合法,然后对于合法的更新,如何设计更新机制才可以尽可能保证数据平面和控制平面的一致性?
关于IP合法性,也就相当于到来TCP连接的合法性,该系统是根据Switch-based TCP SYN Cookie workflow进行的.
利用TCP SYN Cookie怎样判断合法TCP连接?
具体地说,对于跳数不一致的TCP SYN数据包,TCP会话监视器模块会响应TCP SYN-ACK数据包等待TCP ACK数据包.
关于条目的更新,对于miss的条目来说,如果当前处于过滤阶段会将整个数据包发给控制平面,如果是学习状态则只发送数据包摘要.当控制平面接收到之后在本地更新,然后再发送消息使得数据平面更新“匹配+动作表”.而对于hit的条目来说,接下来会进入TCP会话监听模块判断是否有跳数变化,如果有跳数变化,TCP监听模块会发送消息给控制平面,控制平面更新后发送消息使得数据平面上的“匹配+动作”表更新.
然而仅仅是这样做的话,会导致一个问题,因为这个过程会带来延迟,在这个延迟之间的真空期如何处理?
这也就是后面引入一个HC Reinspect的意义.HC Reinspect与TCP会话监控模块直接相连,可以接收到最新的IP2HC变化.
b. IP热度变化以及置换机制
对于IP条目需要维护一个表示IP热度的子段,该字段将会作为该缓存系统中的置换依据.如果不考虑任何和安全有关的问题,那么我们对于每个IP,每访问一次就对其热度计数加一就行了.但是一旦考虑安全的问题,就要避免欺骗性IP对其造成影响.
在NETHCF的设计中,对于数据平面没有进行缓存的IP条目,无法在数据平面上完成判断,因此这时就需要借助控制平面进行判断.然而怎样将此数据包报告给控制平面呢?
如果当前处于学习状态,那么就会讲数据包摘要(IP地址,IP TTL,TCP标志等)传递给控制平面镜像,如果是处于过滤状态的话,则是直接发送整个数据包到控制平面.
然而当缓存中的条目计数值发生变化,如何与控制平面进行同步呢?
NETHCF采用了一种类似于批处理的策略,也就是说,并非每次在数据平面更新都会在控制平面上更新,而是当缓存上一个条目的计数器超过一定的阈值时,缓存会将该条目的IP/IPs前缀发送给控制平面镜像.后面的Report Bit Array用来防止一旦超过某个阈值进而重复报告.
当控制平面获取了数据平面上的所有热条目之后,求出其补集(也就是没有被报告的条目),再根据之前所收集到的miss的条目,对这一部分(补集)中的条目进行更新.
有一说一,这一部分没有完全理解.
最终总体结构如下:
四. 评估分析
首先,说明一下实验条件:一个运行NETHCF的Tofino交换机,当作控制平面的交换机,当作服务端的服务器,另外一个服务器用来作为client.
之后的评估工作主要包括预建立测试,IP2HC表压缩,跳数变化捕捉等等.其中将交换机上资源占用率(CPU内存等),控制平面和数据平面开销和处理延迟等作为重要评价指标.
五. 小结和感想
本文虽然是一篇网络安全相关的论文,但是其创新点并不主要体现在安全机制的创新,而是对于运行这种安全机制的系统架构的创新,创新的目的主要侧重于更小的开销和更高的性能.是一篇硬核的系统文章.
此外,这篇论文涉及到的知识面具有一定的广度,从TCP/IP协议,交换机硬件,分布式系统等等皆有涉猎,此外其中缓存模型的思想也是计算机系统中的经典思想.其实虽然创新很大,但是很多设计仍然是使用的计算机领域比较经典的思想.由此可见,对于系统研究者深刻理解计算机基础学科的意义.
并且系统方面的很多设计,不像纯理论的研究,很多设计所依赖的基础是一些工程的经验,难以用完全精准的公式去描述,比如说:网路IP访问的“heavy-tail”性质等等,但是这些经验极其有用.因此有人说”系统设计是艺术,而非科学“.