移动边缘计算的协同防御——CODE4MEC

2024-10-29发布于新兴网络 | 最后更新于2024-11-19 18:11:00

边缘计算 网络攻防

简介

该文章提出了一个针对移动边缘计算MEC（Mobile Edge Computing） 的 应用层分布式拒绝服务（APP-DDoS） 攻击协同防御机制。文章介绍了如何利用网络功能虚拟化NFV和软件定义网络SDN在MEC节点之间协调防御资源，从而在不增加显著成本的情况下，保护边缘计算服务的可用性。

原文： A Cooperative Defense Framework Against Application-Level DDoS Attacks on Mobile Edge Computing Services

主要解决的问题与贡献

CODE4MEC system framework

5G MEC环境下仍缺少适用于CODE4MEC的系统设计。应在何处部署CODE4MEC的关键组件？如何同时保证CODE4MEC丝滑运行与最小化对5G MEC的影响？

该文章中设计的CODE4MEC框架同时考虑了对通用MEC架构的适配和对5G技术的利用。引入了：

  • 逻辑上中心化的控制器 logically centralized controller
  • 协同防御协调器 CODE orchestrator （CDO）
  • 入侵防护系统服务器 IPSservers

利用第三层网络进行通信，包括CDO与IPSserver、IPSserver之间。采用集中-分布式混合的结构，即CDO全局管理IPSservers的scheduling操作，IPSservers本地执行CODE的triggering、coordination与releasing操作。

Online and performance provable response

如何进行性能高效的调度响应？能长期稳定运行的调度决策算法？

该文章设计了一种基于在线拍卖的（online auction based）非本地CODE scheduling调度策略，考虑了公平和效率之间的平衡。

Accommodation to defense schemes

APP-DDoS攻击持久且分散，CODE的拓扑与流量也需要不断变化。在变化过程中，重新协调决策时，如何确保流量及其上下文信息的完整？

开发了一种vIPS正交的CODE协调（VOCC）模式，使得各vIPS分别正交与对应的源IP，并根据需要传输卸载了的信息。根据CODE的拓扑变化特征，将CODE的coordination分为三种类型：

  • 新旧vIPS之间
  • 活跃vIPS之间
  • 活跃vIPS和已发布的vIPS之间

Prototype system

实现了一个CODE4MEC的原型系统，并以HTTP get/post flooding、single-session HTTP get/ post flooding、low and slow attack模拟攻击。

CODE4MEC架构设想

应用层面考量

系统部署于第三层（IP网络层），是因为其能直接触及的设备多、网络灵活性好、设备间距离近、延迟低，整体结构如下图所示

CODE4MEC整体结构

文章假设3GPP（3rd Generation Partnership Project）在5G网络中定义的UPF（User Plane Function）能够利用SMF（Session Management Function）和PCF（Policy Control Function）有效分流用户的流量至锚点UPFs。框架与5G MEC系统的关系如下图所示

CODE4MEC与5G MEC系统的联系

MEC节点的结构

MEC节点的计算资源被划分为多个虚拟机，这些虚拟机会以如下方式呈现：

  • 数据服务器DATAservers：托管特定的MEC应用为用户提供服务
  • 用户平面功能UPF：作为MEC应用与5G的会话锚点存在，负责管理用户数据流的转发
  • MEC管理服务器MECMserver：托管MEP（MEC Platform），从而管理DATAservers的流量规则、UPF和DATAservers间的路由，还可以通过PCF要求SMF更新MEC应用流量的路由规则

CODE4MEC的应用场景与角色定位

5G中的UPF可以减轻基于IP的欺骗，简单的网络及DDoS攻击在到达MEC服务前就能得到很好的缓解，但APP-DDoS攻击就可以绕过这一防护。由于攻击者所需的资源消耗和防御者非常不对等，若防御时使用较多的资源，单单“防御”这个行为本身就会由于资源不足产生拒绝服务。而CODE4MEC就是为了解决这一“不对等”问题而提出。

将CODE4MEC集成入通用MEC架构中

宏观来看，CODE4MEC由IPSserver与CDO组成

  • IPServer：托管vIPS，保护DATAservers；托管vIPS的local control agent，与CDO交互以执行CODE的triggering、coordination与releasing操作，并引导UPF和DATAservers之间的流量。部署于每个MEC节点，预分配资源，作为虚拟化系统单独运行在VM中。
  • CDO：控制中心，协调IPSservers。逻辑上中心化，物理上分布式，以防止单点故障，backhaul网络中可部署多个CDO，协调方式为单主多副，调度信息通过发布/订阅系统与所有备份同步。

CODE4MEC中的一些互联

  • IPSserver支持通用MEC的Mp2 interface：IPSserver通过此接口与MECMserver通信，并可获取本地UPF和DATAservers之间的路由规则
  • IPServer通过3GPP N6 interface与UPF和DATAservers连接，并引导进出这两者的流量
  • IPSservers之间通过GRE（Generic Routing Encapsulation）隧道传输CODE流量，使用的是3GPP N6 interface
  • CDO与IPSServer之间则直接通过5G回程网络互连，交换CODE控制信息

CDO与IPSserver的具体结构

下图展示了CDO与IPServer的具体结构

CODE4MEC的具体结构设计

CDO中包括了调度器和路由器两个主要组件

  • scheduler根据IPSservers的实时资源利用情况将防御请求schedule到IPSservers
  • router作为SDN的控制器，主动更新vSwitches上各IPSservers间的路由规则

IPSserver概念上可分为vIPS和Agent两个组件，

  • vIPS为基本的虚拟化单元，也是根据防御需求执行activate、schedule、release的对象
  • Agent与CDO中的scheduler一起控制协同防御
    • CFE（Control Front End）用于触发/发起本地与非本地的CODE请求，以及activate和release vIPSs
    • vSwitch会通过用户和DATAServers之间建立的会话接收用户数据流量，再转发到相应目的地（例如相邻的IPSserver、UFD、DATAservers、UPF）。具体的路由规则由CDO router和MECMserver更新维护
    • UFD（User Flow Distributor）接收来自vSwitch的用户流量，在vIPSs间分配每个用户的流量

CODE4MEC的工作机制

CODE4MEC工作流

上图展示了CODE请求发起的全过程。

CODE Request Triggering & CODE Scheduling

每个IPSserver都有一个CODE-request trigger，CFE会监控各vIPS的CPU使用率是否达到阈值（连续超过阈值到一定程度才视为达到）。

显然，根据本地的vIPSs是否充足空闲，可以分为两种情况

  1. 本地空闲vIPS充足，CFE为过载vIPS预留一个空闲的vIPS，接着，CFE还会向CDO报告剩余空闲的vIPS数量
  2. 本地无空闲vIPS
    • CODE triggering：CFE为过载vIPS向CDO scheduler发起外援请求，CDO通过一个双端队列接收该请求
    • CODE scheduling：CDO scheduler会定期收到CFE发来的各IPSserver的状态信息（可能不止一种类型的信息），并基于此为请求匹配调度某个IPSserver中的vIPS，具体调度方法见后文

CODE Coordination

对于本地coordination，CFE激活CODE scheduling时选定的vIPS，再通过VOOC将相关的上下文信息从过载vIPS划分过来即可。

对于非本地coordination，CDO会将关于requester-provider对的必要信息告知CFE以建立链接，同时会去更新vSwitch的路由规则，provider的CFE分配一个空闲vIPS，requester的CFE则通过vSwitch建立GRE与provider连接。简单来说，UFD会将用户的上行流量分发至本地与外援vIPS，经过vIPS过滤流量后再转发至目标DATAserver。

CODE Releasing

对于本地releasing，满足释放条件的vIPS会在处理完所有已缓冲包后被CFE挂起

对于非本地releasing，若外援vIPS满足释放条件，provider通过其CFE向CDO发送vIPS hang-up请求。CDO告知requester的CFE不能使用外援vIPS了，告知provider的CFE挂起vIPS（待所有已缓冲包处理完后挂起，再向CDO发送releasing confirmation）。最后CDO告知provider和requester的vSwitches删除相应的路由规则。

Online non-local CODE Scheduling

将原分配问题转换为无资源限制、有次模投标人的经典拍卖问题 (classically combinatorial auction with submodular bidders and no resource constraint)

将MEC网络建模为一个图 \(\mathcal{G}=\left\{ v,\epsilon\right\}\) ，分别记requester和provider集合为 \(v^{re}\subseteq v,v^{pr}\subseteq v\) 。显然，在同一时刻， \(v^{re}\cap v^{pr}=\varnothing\)

另外，记 \(v^{pr}_n\) 为与requester \(n\in v^{re}\) 有连接的provider集合； \(v^{re}_m\) 同理。 \(\bar{v}^{re}_m\subseteq v^{re}_m\) 为分配给了provider \(m\) 的requester集合，其中 \(\left| \bar{v}^{re}_m \right| \le N^{pr}_m\) ， \(N^{pr}_m\) 为provider \(m\) 在CODE4MEC工作流示意图中sub-time slot 1时间段结束时拥有的空闲vIPS数量。

原始问题的建模

某个provider \(m\) 的效用（utility）由分配给了该provider的所有requester的估价（valuation）求和得到，其中 \(m \in v^{\text{pr}}\) 、 \(\bar{v}^{\text{re}}_m \subseteq v^{\text{re}}_m\) 、 \(\lambda\in\left(1/e,\infty\right)\)：

$$ \mathcal{V}^{\text{ori}}_m \left( \bar{v}^{\text{re}}_m \right) = \sum_{n \in \bar{v}^{\text{re}}_m}{\mathcal{U}^{\text{ori}}_{n,m}} $$
$$ \mathcal{U}_{n,m}^{\text{ori}} = \begin{cases} 0 & , \quad \text{if } \left|\bar{v}_m^{\text{re}}\right| = 0 \\ \log{\frac{k \cdot r_{n,m} }{\left|\bar{v}_m^{\text{re}}\right| / \mathcal{N}_m^{\text{pr}}}} & , \quad \text{if } 0 < \left|\bar{v}_m^{\text{re}}\right| \leq N_m^{\text{pr}} \end{cases} $$
$$ \mathcal{N}_m^{\text{pr}}=e^{\lambda\cdot N^{\text{pr}}_m} $$

需要说明的是，上式中的 \(k\) 是个超参数，用于权衡效率和公平，值越大越注重效率； \(r_{n,m}\) 表示provider \(m\) 对 requester \(n\) 的防御效率，单位为pps（packets per second）；

最终构成的优化问题如下：

$$ \begin{align} \mathcal{P}^{\text{ori}} : \max_{\{\bar{v}_m^{\text{re}}\}} \sum_{m \in v^{\text{pr}}} v_m^{\text{ori}} \left( \bar{v}_m^{\text{re}} \right) \\ \text{s.t.} \quad \begin{aligned} & \bar{v}_m^{\text{re}} \subseteq v_m^{\text{re}}, \forall m \in v^{\text{pr}}, \\ & \bar{v}_m^{\text{re}} \cap \bar{v}_{m'}^{\text{re}} = \varnothing , \forall m \neq m', \\ & \left| \bar{v}_m^{\text{re}} \right| \leq N_m^{\text{pr}}, \forall m \in v^{\text{pr}} \end{aligned} \end{align} $$

约束条件含义分别为：

  1. 必须为provider选择与之相连的requester
  2. 每个requester只能分配给一个provider
  3. 最多将 \(N_m^{\text{pr}}\) 个requester分配给provider \(m\) （显然的，因为只有这么多空闲的vIPS）

将原始问题转移到本文提出的算法上

首先，放开第三条约束条件，并重新定义效用和估价，其中的 \(\mathcal{M}\left(N, U\right)\) 表示对集合 \(U\) 的最大 \(N\) 项求和：

$$ \mathcal{V}_m(\bar{v}_m^{\text{re}}) = \mathcal{M}\left(N_m^{\text{pr}}, \left\{ \mathcal{U}_{n,m}, \forall n \in \bar{v}_m^{\text{re}} \right\}\right) $$
$$ \mathcal{U}_{n,m} = \begin{cases} \mathcal{U}_{n,m}^{\text{ori}} &, \text{if } 0 \leq \left|\bar{v}_m^{\text{re}}\right| \leq N_m^{\text{pr}} \\ \log {\frac{k \cdot r_{n,m}}{N_m^{\text{pr}} / \mathcal{N}_m^{\text{pr}}}} & , \text{if } \left|\bar{v}_m^{\text{re}}\right| > N_m^{\text{pr}} \end{cases} $$

另外，还定义了边际效用（marginal utility）增益，即在已经给 provider \(m\) 分配了requester集合 \(\bar{v}^{\text{re}} _m\) 的基础上，又为其分配一个requester \(n'\) 时会增加的效用

$$ \mathcal{V}_m(n'|\bar{v}_m^{\text{re}}) = \mathcal{V}_m\left(\bar{v}_m^{\text{re}} \cup \left\{n'\right\}\right) - \mathcal{V}_m(\bar{v}_m^{\text{re}}) $$

最终的分配算法

  1. 对于每一个 \(m\in v^{\text{re}}\) ，初始化 \(\bar{v}^{\text{re}}_m\leftarrow \varnothing\)
  2. 逐个遍历requester \(n=1,2,\dots,\left| v^{\text{re}} \right|\) ，对给定的每个requester执行步骤3

  3. 遍历每个与给定requester相连接的provider，即 \(m\in v^{\text{pr}}_m\) ，按下式计算边际效用增益。若对于所有的 \(m\in v^{\text{pr}}_m\) 的 \(b_{n,m}\) 均为0，即 \(\sum_{m \in v^{\text{pr}}} b_{n,m}\) ，则直接回到步骤2遍历下一个 \(n\)

    $$ b_{n,m} = \begin{cases} 0 & , \quad \text{if } \mathcal{V}_m(n|\bar{v}_m^{\text{re}}) = 0 \\ \mathcal{V}_m(n|\bar{v}_m^{\text{re}})^{\left|v_n^{\text{pr}}\right|-1} & , \quad \text{if } \mathcal{V}_m(n|\bar{v}_m^{\text{re}}) > 0 \end{cases} $$
    此时便可以用每一个 provider \(m\) 对应的 \(b_{n,m}\) 占比得到其对应的概率，根据此概率选取一个 \(m\) 作为 \(m^*\) ，将此时的 requester \(n\) 并入 \(\bar{v}_m^{\text{re}}\) 中，即 \(\bar{v}_{m^*}^{\text{re}}\leftarrow\bar{v}_{m^*}^{\text{re}}\cup\left\{n\right\}\)：
    $$ p_{n,m} = \frac{b_{n,m}}{\sum_{m \in v^{\text{pr}}} b_{n,m}} $$

vIPS-Orthogonal CODE Coordination

首先引入一些符号，对于单输入多输出的UFD，其输入为待分配的流量，每个输出队列则和一个vIPS相关联。记输出队列集合为 \(Q\) ；每个输出队列对应的源IP（SIP）集合为 \(S_i\) ，其中 \(i\in Q\) ；SIP的预估流量负载为 \(R_s\) 。

另外，规定 \(S_i\cap S_j=\varnothing\) ，其中 \(\forall i,j\in Q\) 且 \(i\ne j\) 。如此使得控制粒度为SIP，很多传统方法也可应用。

UFD架构示意图

将VOCC模式分为三种情况

策略1：为新vIPS初始化输出队列

存在新的vIPS时UFDE会将部分负载从过载vIPS转移到新的vIPS，目的是优化算力划分。通过下面这个优化问题来决定是否将SIP移到新的vIPS。可以观察到，使用了贪心的思想，即在保证移出的SIP的总预估负载不超过当前一半的前提下，尽可能多的移出负载：

$$ \begin{aligned} \max_{\{y_s\}} & \sum_{s \in S_i} y_s \cdot R_s \\ \text{s.t.} & \quad y_s \in \{0,1\}, \; \forall s \in S_i \\ & \quad \sum_{s \in S_i} y_s \cdot R_s \leq \frac{1}{2} \sum_{s \in S_i} R_s. \end{aligned} $$

策略2：将流量分配到已存在的合适输出队列

UFDE会先查看输入的包的SIP，若该SIP已在某个输出队列上登记过，则直接分配给该队列，否则进行后续处理。

定义 \(\hat{S}\) 为未登记的SIP； \(\hat{S_i}\subseteq \hat{S}\) 为要分配到队列 \(i\in Q\) 的SIP集合。未登记SIP分配可以定义为如下优化问题：

$$ \begin{aligned} \max_{\{\hat{S}_i\}} & \sum_{i \in Q} \hat{\mathcal{V}}_i(\hat{S}_i) \\ \text{s.t.} & \quad \hat{S}_i \cap \hat{S}_j = \varnothing, \forall i \neq j \\ & \quad \hat{S}_i \subseteq \hat{S}, \forall i \in Q \end{aligned} $$
$$ \begin{equation} \hat{\mathcal{V}_i}\left(\hat{S}_i\right) = \begin{cases} \left|\hat{S}_i\right| \cdot \log \frac{k' \cdot P_i}{\left|\hat{S}_i\right|} & \text{if } 0 < \left|\hat{S}_i\right| \leq \left|\hat{S}\right| \\ 0 & \text{if } \left|\hat{S}_i\right| = 0 \end{cases} \end{equation} $$
$$ \begin{align} & P_i = (1-\mathcal{C_i}) \cdot \alpha_i\\ & \mathcal{C_i}\in\left[0,1\right],\alpha_i\in\left\{\alpha_L,\alpha_F\right\} \end{align} $$

其中， \(\hat{\mathcal{V}_i}\) 表示输出队列 \(i\) 对于 \(\hat{S_i}\) 的价值； \(\mathcal{C_i}\) 为输出队列 \(i\) 当前的占用率； \(\alpha_L\) 和 \(\alpha_F\) 为调整参数，分别代表本地vIPS与外援vIPS。

另外，还要求如下：

  • \(k'\cdot P_i\ge \left|\hat{S}\right| \cdot e,\forall i\in Q\) ：保证更偏好于较空闲的vIPS
  • \(\alpha_L\ge\alpha_F\gt 0\) ：保证输出队列在一样占有率的情况下，更偏向于本地的vIPS

策略3：其他情况

当已经登记与同一个输出队列的一些SIP突然都开始产生较大的流量负载时，上述策略可能就无法很好地处理。因此，补充以下策略：

  1. 当某些vIPS超载时，供应添加一些新的vIPS，并使用策略1进行负载均衡
  2. 当某些vIPS达到释放条件释放后，对应的输出队列相应释放，其中登记的SIP也全部删除。如此，当被删除SIP的流量包下次到达时，按策略2中未登记的SIP处理即可

性能评估

实验平台示意图

Server 1~10作为MEC节点，Server 11作为正常和攻击流量的生成器，Server 13用作5G用户和控制平面网络的软件模拟。

此处定义一个RTT用于衡量MEC系统的低延迟特性，其中 \(t_{\text{prop1}}\) 为两个相合作MEC节点之间的延迟， \(t_{\text{prop2}}\) 为从server11经由server13到达相应MEC节点的延迟， \(t_{\text{pre1}}\) 为vIPS的处理时长， \(t_{\text{pre2}}\) 为DATAserver的处理时长：

$$ RTT=\left(t_{\text{prop1}}+t_{\text{prop2}}\times 2\right)+t_{\text{pre1}}+t_{\text{pre2}} $$

单vIPS基础防御能力

单vIPS防御性能测试图

如上图，红线表示攻击请求发送速度和单个vIPS的CPU使用率的关系、绿线表示攻击请求发送速度和RTT的关系。可以发现，RTT在攻击速度超过70rps后大幅增加，为了保持RTT在20ms以下（此时对应的CPU占用率为80%），将triggering的阈值 \(\lambda^{\text{tr}}\) 设为80%；当攻击速度低于20rps时，cpu使用率没有显著增加，可以认为其处于空闲状态，因此将releasing阈值 \(\lambda{\text{rls}}\) 设为20%

下图为不同攻击速率下，检出攻击流量的准确率

攻击流量检测准准确率

Non-Local CODE的响应速度

Non-Local CODE的响应速度折线图

上图展示了非本地CODE对攻击的响应速度。

  1. 一开始，不做任何CODE操作、不进行任何攻击（平均RTT 6ms左右）
  2. 从第15秒开始，持续发起90rps的攻击，在攻击持续25秒后，平均RTT达到了900ms
  3. 在第39秒启用了CODE，在2秒内（这2秒中有1秒在做triggering确认、5ms在做CODE scheduling、56ms在初始化CODE环境），平均RTT开始下降
  4. 在第45秒，平均RTT恢复到正常水平

CODE Coordination中VOCC的性能

VOCC性能测试曲线图

上图展示了VOCC中三种策略的作用情况，蓝色、红色曲线分别为本地vIPS和与其协作的外援vIPS的流量分配情况。

  1. 在一开始，关闭CODE并施以90rps的攻击（根据单vIPS防御能力中的图可知，此时CPU使用率近100%）
  2. 在第20秒时，打开CODE，相当于有新的vIPS加入，策略1发挥作用，差不多一半流量都分配到了新vIPS上
  3. 在第70秒时，使用一些新IP以50rps的速度发起攻击请求，策略2发挥作用，根据CPU占有率和本地/外援 vIPS分配SIP到两个vIPS上，两个vIPS最终分配到的流量均在70rps左右
  4. 最后，将整体的攻击速度降至30rps，外援vIPS达成releasing条件后挂起，流量重新分配给了本地vIPS

系统测试

最终系统防御测试曲线图

系统测试中共使用了9个MEC节点，其中1个节点为攻击对象，另8个与之相连，攻击对象的IPSserver中有10个vIPS，其他MEC节点中各有3个空闲vIPS可用于协同防御。上图展示了防御系统的整体效率，此处接收到的请求速率是在DATAserver上测得的。蓝色区域为攻击请求和正常请求数量的加和，红色为部署了CODE4MEC系统的，黄色为仅在单机部署混合防御的，绿色为正常仅有请求的。

可以观察到，在攻击发起后，部署了CODE4MEC的很快恢复到了正常情况（几乎过滤了所有攻击请求）；而未部署协同防御的长时间满负载接收请求（在700rps左右波动），最终似乎也能恢复到正常水平，但由于缓冲溢出，很多正常请求最终未响应。

下图展示了正常请求的响应情况，横轴为响应成功时的RTT（超过10秒是用户不可容忍的，因此超过10秒的均记为10秒），纵轴为累积分布函数（即小于某一RTT的占比）。可以观察到，在部署了CODE4MEC的系统中，33%的正常请求在20ms内成功响应，接近于没有攻击请求下的41%；但在未部署协同防御的系统中，响应时间超过900ms的正常请求占比78%，超过10s的占比81%

正常请求的响应情况