软件定义网络中仍然存在未知单播泛洪攻击吗?
如果没有,它是如何被淘汰的?
软件定义网络中仍然存在未知单播泛洪攻击吗?
如果没有,它是如何被淘汰的?
简短的回答是,它是软件定义的:-)
让我们解开你的问题。透明桥接网络中的未知单播是目标 MAC 地址未知的单播。在透明桥接中,我们将其淹没所有接口。该地址将到达感兴趣的 MAC 地址(假设它存在),当该计算机响应时,我们将在以太网帧的源地址中看到该 MAC 地址,并且可以记录看到它的端口。
重要的是,该未知单播 MAC 地址需要交换机的 TCAM 中的条目。
未知单播攻击是当我们发送如此多从未见过的 MAC 地址时,交换机的 TCAM 的未知单播部分充满了这些垃圾地址,并且随着 TCAM 老化真正的 MAC 地址,然后那些真正的 MAC 地址正在与恢复的可能性作斗争。
我们当然可以在交换机中对此采取措施。例如,通过首选 TCAM 中已建立的 MAC 地址条目。
现在,如果我们使用 SDN 来实现透明以太网桥接,那么问题仍然存在。控制器仍然有一个 MAC 地址表,我们正在用大量垃圾(匹配、操作)规则填充 OpenFlow-switch。此外,从交换机到控制器的 OpenFlow 流量和(匹配、操作)规则的变化率可能开始成为问题。
但是我们不必使用SDN来实现透明的以太网桥接。我们可以在不使用相同机制的情况下实现具有相同效果的东西。作为一个非常简单的示例,配置系统可以为 SDN 控制器配置每个 MAC 地址的位置。然后根本没有未知单播处理,因为所有未知单播都是无效的,可以立即丢弃。或者我们可以完全取消 MAC 地址,只需将 IP 地址的低字节配置为以太网接口的 MAC 地址。然后,SDN 控制器应用程序将基本上路由,没有 ARP。
或者以广域问题为例,如果我们提供城域以太网服务,那么我们可以简单地将接收到的数据包封装在 A 端面向客户端的接口处,使用我们自己的 MAC 寻址将其通过我们的网络传送到 B 端面向客户端的接口,并传输数据包。根本不查看客户的 MAC 地址。您可以看到这种方法也可以在数据中心网络中使用,并且有多种“隧道”方案。这样的隧道意味着无论主机声称其 MAC 地址是什么都无关紧要,网络使用主机无法影响的自己的地址。因此,未知的单播攻击是没有实际意义的。
最后,一个重要的实际考虑是 SDN 控制器可以嘲笑 ISO 分层。如果有人尝试攻击,并且可以从上层检测到该攻击(例如,通过入侵检测系统),则可以告知 OpenFlow 控制器阻止该类流被切换。正是这些“整体网络协同效应”使 SDN 比简单地重新实现透明以太网桥接更有趣。迄今为止,感兴趣的协同效应一直是数据中心供应,但互联网网络中显然有很多未开发的范围。