11. 安全考量

允许任意客户端建立一个可向任意主机发送流量的隧道存在重大风险, 无论隧道是否限定于特定主机都是如此. 恶意行为者可能滥用这种能力发送流量, 并使这些流量归因于 IP 代理. 支持 IP 代理的 HTTP 服务器 SHOULD 将其使用限制为已认证用户. 根据部署方式, 可用的认证机制包括 IP 代理端点之间的双向 TLS, 通过 HTTP Authorization 头部 [HTTP] 进行的基于 HTTP 的认证, 甚至 bearer token. 代理可以对已认证用户实施策略, 以进一步约束客户端行为或处理可能的滥用. 例如, 代理可以对通过代理发送过量流量的单个客户端进行速率限制. 再如, 代理可以基于某些客户端属性, 例如地理位置, 限制向客户端分配地址 (前缀).

地址分配可能对端点产生隐私影响. 例如, 如果代理按已认证客户端数量划分其地址空间, 然后为每个客户端分配不同的地址范围, 目标主机就可能利用这些信息判断哪些 IP 分组对应同一个客户端. 对某些代理部署而言, 避免这种跟踪向量可能很重要. 代理 SHOULD 在可能时避免持久的按客户端地址 (前缀) 分配.

在发送流量中伪造 IP 源地址是拒绝服务攻击中的常见做法. 该机制的实现需要确保不会助长此类攻击. 特别是, 在某些场景中, 端点知道其对等方只被允许从给定前缀发送 IP 分组. 例如, 这可能通过带外配置信息实现, 或在允许前缀通过 ADDRESS_ASSIGN capsule 共享时发生. 在这类场景中, 端点 MUST 遵循 [BCP38] 的建议以防止源地址欺骗.

限制请求范围 (见第 4.6 节) 允许两个客户端共享代理的某个外部 IP 地址, 前提是它们的请求限定于不同的 Internet Protocol Numbers. 如果代理收到一个目的地址为该外部 IP 地址的 ICMP 分组, 它可以选择将该分组转发回客户端. 然而, 其中一些 ICMP 分组会携带触发 ICMP 响应的原始 IP 分组的一部分. 转发这类分组可能意外地向另一个客户端泄露某个客户端流量的信息. 为避免这种情况, 在共享外部 IP 地址上转发 ICMP 的代理 MUST 检查 ICMP 分组中包含的 invoking packet, 并且只将该 ICMP 分组转发给其范围限定与 invoking packet 匹配的客户端.

实现者可参考 [TUNNEL-SECURITY] 中的指导. 由于某些 IPv6 扩展头存在已知风险, 例如 [ROUTING-HDR], 实现者需要遵循关于 IPv6 扩展头处理的最新指导.

将 DSCP 标记从内层分组转移到外层分组 (见第 10.3 节) 会向 IP 代理端点之间路径上的观察者暴露端到端流级别信息. 这可能暴露单个端到端流. 因此, 在隐私敏感上下文中使用这种 DSCP 用法是 NOT RECOMMENDED 的.

HTTP/1.x 中不允许机会式发送 IP 分组 (见第 7.1 节), 因为服务器可能拒绝 HTTP Upgrade, 并尝试将这些 IP 分组解析为后续 HTTP 请求, 从而允许请求走私攻击; 见 [OPTIMISTIC]. 特别是, 将请求从 HTTP/2 或 HTTP/3 重新编码为 HTTP/1.1 的中介, 在解析到成功的 IP 代理响应之前 MUST NOT 转发任何收到的 capsule.