您应该传输所有 IP 数据包，而不仅仅是 TCP 数据包

[netflix]

出于多种原因，这会很方便：它将使 Tor 能够更好地处理 VoIP 等新协议。它可以解决sockify应用程序的全部需求。 退出中继也不需要为所有退出连接分配大量文件描述符。

我们正在朝这个方向前进。一些难题是：

1. IP 数据包揭示操作系统特征。我们仍然需要进行 IP 级数据包标准化，以阻止 TCP 指纹攻击之类的事情。考虑到 TCP 堆栈的多样性和复杂性，以及设备指纹攻击，我们最好的选择是推出我们自己的用户空间 TCP 堆栈。
   
2. 应用程序级流仍然需要清理。我们仍然需要像 Torbutton 这样的用户端应用程序。因此，这不仅仅是捕获数据包并在 IP 层将其匿名化的问题。
   
3. 某些协议仍然会泄露信息。例如，我们必须重写 DNS 请求，以便将它们传递到无法链接的 DNS 服务器，而不是用户 ISP 的 DNS 服务器；因此，我们必须了解我们正在传输的协议。
   
4. DTLS（数据报TLS）基本上没有用户，而IPsec肯定很大。一旦我们选择了传输机制，我们就需要设计一个新的端到端 Tor 协议，以避免标记攻击和其他潜在的匿名和完整性问题，因为我们允许丢弃、重新发送等。
   
5. 针对任意 IP 数据包的退出策略意味着构建安全的入侵检测系统 (IDS)。我们的节点运营商告诉我们，退出政策是他们愿意运行 Tor 的主要原因之一。添加 IDS 来处理退出策略会增加 Tor 的安全复杂性，而且很可能无论如何都行不通，正如整个 IDS 和反 IDS 论文领域所证明的那样。许多潜在的滥用问题都通过 Tor 仅传输有效的 TCP 流（而不是任意 IP，包括格式错误的数据包和 IP 泛洪）这一事实得到解决。随着我们能够传输 IP 数据包，退出策略变得更加重要。我们还需要简洁地描述 Tor 目录中的退出策略，以便客户端可以预测哪些节点将允许其数据包退出。
   
6. Tor 内部名称空间需要重新设计。我们通过在地址传递到 Tor 客户端时拦截地址来支持洋葱服务“.onion”地址。在 IP 级别这样做将需要 Tor 和本地 DNS 解析器之间有一个更复杂的接口。