NetHide: Secure and Practical Network Topology Obfuscation 论文阅读笔记

Introduction

恶意的用户可以通过一些像 tracerout 这样简单的网络工具来推断一个 AS 的内部结构，并识别结构中薄弱的链路发起链路洪泛攻击（Link-Flooding Attack, LFA)。虽然存在这样的问题，但大部分的网络管理者依然会允许路径的追踪，因为这也是他们查找网络错误原因的重要工具。如何在保证 trace 工具可用性的前提下对网络路由进行隐藏是一个值得研究的重要问题。
这篇文章提出了一个混淆网络路由的框架——NetHide，NetHIde 的核心思想是把路由混淆问题转换成一个多目标优化任务，并把安全要求设置成硬约束，trace 工具的可用性要求编码成软约束。最后利用可编程交换机（P4），在保证效率的情况下对网络路由进行混淆。

Formulation

1. 文章的一个假设
   网络中的路由是确定的，即对于一个 Destination，只有唯一确定的路由路径。（没有例如 ECMP 这样的概率路由机制）

2. 公式标注
   
   网络中原来存在的节点集合是 $N$，链路集合是 $L$。将网络中的每一个节点（$n$）作为树根节点，可以把网络中其他节点对该节点的路由抽象成一颗转发树（$T_n$)，所有节点的转发树集合为$T$。网络中的每一个 Flow 都可以看成一个 $(s,d)$ 节点对，形成的集合为 $F$。
   网络的真实物理路由拓扑结构由节点集合$N$，链路集合$L$，转发树集合$T$ 所组成，用 $P$ 来表示。经过混淆形成的虚拟拓扑结构 $V$ 由新的节点集合 $N^{{}^{\prime }}$（虚拟节点 + $N$），新链路集合 $L^{{}^{\prime }}$，以及新的转发树集合 $T^{{}^{\prime }}$ 所组成。
   每条链路上会经过的 flow 的数量计作流密度 $fd(T,l)$， 每条链路（$l$）最大能同时流经的流的数量为 $c(l)$。$acc$ 用于表示混淆得到的网络结构与原结构的相似度，物理链路出错能够在混淆的结构中同样有所展示的概率用 $util$ 表示。

3. 关于安全的硬约束
   
   (C1) 表示对于网络中的任意一条链路，流密度都不能大于容量；（C2，4）表示原网络结构中的节点和边也是新的网络结构中的点和边；（C3）表示对于每一个节点，只有一颗转发树；（C5）是一致性约束。

4. 关于 accuracy 以及 utility 的软约束
   目标函数为：
   
   其中 accuracy 为：
   
   $LD(a,b)$ 表示 a 和 b 的 编辑距离（Levenshtein distance）。
   
   utility 为：
   

寻找合适的拓扑结构（考虑 scalability 问题）

1. 在确定新增的虚拟节点数量后，NetHide 首先构造一个 $N^{{}^{\prime }}\times N^{{}^{\prime }}$ 的全连通图。每一条边的权重 $W(e)$ 都初始化为 1，接下来 NetHide 利用 Dijkstra 算法计算每一个节点的转发树；在计算完毕后，又开始新的一轮计算，$W(e)\sim Uniform(1,10)$，直到针对每个节点都找到一定数量的转发树。
2. 针对每个节点提前计算一批转发树后，NetHide 便开始利用 ILP 求解器求解上述的多目标优化问题，得出混淆后的网络结构。

实现方式

• 部署方式：程序由放置在网络进出口的可编程交换机来执行。
• 识别需要修改的报文：如果 Nethide 收到一个进入网络的新报文，如果该报文对应的虚拟路径和真实的转发路径相同，则不做任何修改；如果虚拟路径和真实路径长度相同，并且报文的 TTL 值足够该报文到达出口，不做任何修改；虚拟路径和真实路径长度不同，TTL 需要加上或减去对应的差值。并且如果 TTL 值不足够到达出口，NetHide 需要确保该报文在虚拟网络结构中对应的节点处发送 ICMP 超时报文，即把 Destination 地址改为该节点，Source 地址改为修改节点。这样就能够保证在正确的虚拟位置上发送 ICMP 报文给修改该报文的路由器。然后值得一提的是，路由器还会把报文的原 source 和 destination 以及其他信息放在 IP 报文的 Meta Data 中。
• 恢复发送出网络的 ICMP 报文：路由器收到需要修改的 ICMP 报文时，由于 ICMP 报文会携带原 IP 报文的 Meta Data，所以路由器能够根据 Meta Data 中的信息对 ICMP 报文进行修改，保证 ICMP 报文能够正确的到达原目标地址。具体的流程如下图所示：
  
• 系统总架构：
  
  如上图所示，在 NetHide 的顶层还有一个 controller 设备，它的具体作用是根据虚拟的网络结构完成下列形式的转化，并将转化后的规则发送给可编程交换机：
  

NetHide 的问题

文章对于 NetHide 安全性的建模是建立在 flow density 的容量小于最大容纳流容量这个基础上，但是这个很明显不怎么符合实际（文章的这种建模需要建立在流大小相同的条件下才能说通）。当然文章也承认了这一点，因为如果按照数据流量进行建模会极大的增加模型的复杂程度，也需要对拓扑和流量进行更多的假设。