QUIC 与 防火墙

金瑜

网络中立性，一直争吵了快 40 年...
QUIC 几乎把防火墙半废了，特别是基于五元组的防火墙：

• 无法分析 payload，因为加密了。
  
• 无法阻断特定元组，因为元组可变。
  

除非把特定两台主机的 TCP/UDP 通信完全禁止，否则完全可以通过更改端口重试的方式绕开防火墙。这并不复杂。
接收端很容易实现 “侦听所有 UDP 端口” 的逻辑，学着 iptables REDIRECT 的样子就行，将收到的无主 UDP 报文交给 QUIC 解析，QUIC 本身即端口无关，QUIC 通过 Connection ID 来识别流。
即使禁掉所有 UDP，刚刚我不是展示如何将 socket(AF_INET, SOCK_DGRAM, 0) 传输给 socket(AF_INET, SOCK_STREAM, 0) 么。
传输层协议本身即运载协议，端口号本不应该和应用进程耦合，端口号的存在仅增加了复用率，在 1970～1980 年代，端口号只是不经意间让人觉得 “它真的代表特定服务，比如 80 就是 HTTP”。难道不该让服务自己识别自己吗？QUIC 着实解除了端口号和服务之间的耦合。
为防止协议僵化，QUIC 要求无条件加密，端与网络解耦，各自独立发展，网络不能再对传输协议进行任何假设，当然也就无法禁止特定流，传统防火墙依赖传输协议 IP 和端口进行流量阻滞， 便无法再发挥作用。
QUIC 传输本身甚至是可序列化的，虽然 TCP Repair 也做过类似尝试，但终究还是没能力尽力。
我曾经以为 QUIC 的部署会促使防火墙进行一波升级，但现在看来，事情并不是升级能解决的，传统的安全防火墙面对 QUIC 是无能为力的，无论怎么升级都不行。
看起来 QUIC 周边的配套还很苍凉。除了防火墙，可能还有 QoS，流量工程。仅存的 Connection ID 不变量能做什么？但仔细推敲，这个字段也是可以协商变更的，而协商的内容在 encrypted payload 里 ...
但这就是 QUIC，真正的传输协议该展现出的样子。
浙江温州皮鞋湿，下雨进水不会胖。

瀟

禁止特定流、特定端口、协议，或者悄咪咪的对这些流量进行整形，本就不应该是防火墙应该做的，防火墙做这些事就是防君子，防不了小人。要流量整形应该做的是基于接口（而不是ip）在网络层进行控制，将qos权力归还用户，同时让用户对自己的行为负则。要审核内容，可以要求用户提交密钥，否则加密内容不予转发。

白色的夜

关于网络中立性，一直争吵了快40年

破晓的曙光

确实……二十几年前用哪些unix机器跑mudlib的时候就有这些争吵了

就是喜欢怼

网络中立性我看了一篇18页的英文文档，复制粘贴到谷歌有道翻译里看的。。。看烦了，直接quic不好嘛，我加密，你也别想看，爱转不转[耶]

枝叶繁茂

gfw会不高兴

缓峰居士张仍

答主说的fw是isp的fw吧。企业自己的ngfw现在的趋势是per app steeling+control。quic下类似tls1.3，只要有植入fw自己的证书照样可以decrypt和做DPI，只是门槛高了很多

山之北水之南

QoS 交给用户？用户能把核心网干废[流泪]

还是算了吧

虽说不是学通信的，但还是觉得QUIC好[爱]

布满星辰的夜晚

在接口限流啊，分配你的接口1000m，你喜欢用来走upd,tcp甚至ping都没问题，核心网怎么干得废？