本备忘录状态

这是一个互联网标准轨道文档。¶

本文档是互联网工程任务组（IETF）的产物。它代表了 IETF 社区的共识。该文档已接受公开评审并已获互联网工程指导组（IESG）批准发布。有关互联网标准的更多信息，请参阅 RFC 7841 的第 2 节。¶

有关本文件当前状态、任何勘误以及如何提供反馈的信息，可在 https://www.rfc-editor.org/info/rfc9298 获得。¶

Copyright Notice

Copyright (c) 2022 IETF Trust and the persons identified as the document authors. All rights reserved.¶

This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (https://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Code Components extracted from this document must include Revised BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Revised BSD License.¶

目录

1. 引言

虽然 HTTP 提供了 CONNECT 方法（参见 RFC9110 第 9.3.6 节） 用于创建到代理的 TCP [TCP] 隧道，但在本规范之前， 它并不具备用于 UDP [UDP] 流量的相应方法。¶

本文档描述了一个用于通过充当 UDP 专用代理的服务器在 HTTP 上对 UDP 进行隧道传输的协议。UDP 隧道通常用于创建端到端的虚拟连接，然后可以使用 QUIC [QUIC] 或其他运行在 UDP 之上的协议对其进行保护。与 HTTP CONNECT 方法不同，UDP 代理本身由包含目标地址的绝对 URL 标识。客户端使用 URI 模板 [TEMPLATE] 生成这些 URL，如 第 2 节 所述。¶

该协议通过使用 HTTP 数据报 [HTTP-DGRAM] 支持所有现有版本的 HTTP。当使用 HTTP/2 [HTTP/2] 或 HTTP/3 [HTTP/3] 时，它使用如 [EXT-CONNECT2] 和 [EXT-CONNECT3] 所述的 HTTP 扩展 CONNECT。当使用 HTTP/1.x [HTTP/1.1] 时，它使用 RFC9110 第 7.8 节 定义的 HTTP Upgrade。¶

2. 客户端配置

HTTP 客户端使用包含变量 "target_host" 和 "target_port" 的 URI 模板 [TEMPLATE] 配置以使用 UDP 代理。下面给出示例：¶

https://example.org/.well-known/masque/udp/{target_host}/{target_port}/
https://proxy.example.org:4443/masque?h={target_host}&p={target_port}
https://proxy.example.org:4443/masque{?target_host,target_port}

以下要求适用于该 URI 模板：¶

• URI 模板 MUST 为 3 级或更低级别的模板。¶
• URI 模板 MUST 必须为绝对形式，并且 MUST 包含非空的 scheme、authority 和 path 组件。¶
• URI 模板的 path 组件 MUST 以斜杠 ("/") 开头。¶
• 所有模板变量 MUST 位于 URI 的路径或查询组件内。¶
• URI 模板 MUST 必须包含两个变量 "target_host" 和 "target_port"，并且 MAY 包含其他变量。¶
• URI 模板 MUST NOT 包含任何非 ASCII 的 Unicode 字符，且 MUST 仅包含 0x21-0x7E 范围内的 ASCII 字符（注意允许使用百分号编码；见 RFC3986 第 2.1 节）。¶
• URI 模板 MUST NOT 使用保留扩展（"+" 操作符）、片段扩展（"#" 操作符）、带点前缀的标签扩展、带斜杠前缀的路径段扩展，或带分号前缀的路径样式参数扩展。¶

客户端 SHOULD 验证上述要求；然而，客户端 MAY 使用不具备此类特定验证的一般用途 URI 模板实现。如果客户端检测到任何 URI 模板不满足上述要求，客户端 MUST 拒绝该配置并在不向 UDP 代理发送请求的情况下中止该请求。¶

原始的 HTTP CONNECT 方法允许传递目标主机和端口，但不包含 scheme、代理 authority、path 或 query。因此，一些代理配置界面仅允许用户配置代理主机和代理端口。受此类限制约束的本规范的客户端实现 MAY 尝试使用默认模板 访问 UDP 代理能力，该默认模板定义为 "https://$PROXY_HOST:$PROXY_PORT/.well-known/masque/udp/{target_host}/{target_port}/"，其中 $PROXY_HOST 和 $PROXY_PORT 分别为配置的 UDP 代理主机和端口。若需与此类客户端互操作，UDP 代理部署 SHOULD 在该位置提供服务。¶

3. 通过 HTTP 隧道传输 UDP

为了协商用于在 HTTP 上传输 UDP 的隧道，本文档定义了 "connect-udp" HTTP Upgrade 令牌。由此建立的 UDP 隧道使用 Capsule 协议（参见 RFC9297 第 3.2 节）并采用在 第 5 节 定义的 HTTP 数据报格式。¶

要为与单个 HTTP 流关联的 UDP 隧道发起协商，客户端发出包含 "connect-udp" upgrade 令牌的请求。隧道的目标由客户端通过 URI 模板的 "target_host" 和 "target_port" 变量向 UDP 代理指示；参见 第 2 节。¶

"target_host" 支持使用 DNS 名称、IPv6 字面量和 IPv4 字面量。注意不支持 IPv6 作用域地址标识符。使用 [URI] 中的术语 IPv6address、IPv4address、reg-name 和 port，"target_host" 与 "target_port" 变量 MUST 遵循 图 2 中的格式，使用 [ABNF] 的记法。此外：¶

• "target_host" 与 "target_port" 变量均 MUST NOT 为空。¶
• 如果 "target_host" 包含 IPv6 字面量，冒号 (":") MUST 进行百分号编码。例如，如果目标主机是 "2001:db8::42"，则在 URI 中编码为 "2001%3Adb8%3A%3A42"。¶
• "target_port" MUST 表示一个在 1 到 65535（含）之间的整数。¶

target_host = IPv6address / IPv4address / reg-name
target_port = port

在发送其 UDP 代理请求时，客户端 SHALL 执行 URI 模板展开以确定请求的路径和查询部分。¶

如果请求成功，UDP 代理承诺将接收的 HTTP 数据报转换为 UDP 数据包，反之亦然，直到隧道被关闭为止。¶

根据 Capsule Protocol 的定义（参见 第 3.2 节，见 [HTTP-DGRAM]），UDP 代理请求不携带任何消息内容。 同样，成功的 UDP 代理响应也不携带任何消息内容。¶

GET https://example.org/.well-known/masque/udp/192.0.2.6/443/ HTTP/1.1
Host: example.org
Connection: Upgrade
Upgrade: connect-udp
Capsule-Protocol: ?1

HTTP/1.1 101 Switching Protocols
Connection: Upgrade
Upgrade: connect-udp
Capsule-Protocol: ?1

HEADERS
:method = CONNECT
:protocol = connect-udp
:scheme = https
:path = /.well-known/masque/udp/192.0.2.6/443/
:authority = example.org
capsule-protocol = ?1

HEADERS
:status = 200
capsule-protocol = ?1

4. 上下文标识符

本文件定义的在 HTTP 中代理 UDP 的机制允许未来扩展交换携带与 UDP 有别语义的 HTTP 数据报。这些扩展有的可以为 UDP 有效载荷增加附加数据，有的可以交换与 UDP 有效载荷完全独立的数据。为实现此目的，所有与 UDP 代理请求流相关的 HTTP 数据报都以 Context ID 字段开头；参见 第 5 节。¶

Context ID 为 62 位整数（0 到 2⁶²-1）。Context ID 以可变长度整数编码；参见 RFC9000 第 16 节。值 0 的 Context ID 为 UDP 有效载荷保留，非零值为动态分配。非零的偶数 Context ID 由客户端分配，奇数 Context ID 由代理分配。Context ID 的命名空间绑定到给定的 HTTP 请求；在不同请求中可以同时分配相同数值的 Context ID，且可能具有不同语义。Context ID MUST NOT 在给定的 HTTP 命名空间内被重新分配，但 MAY 以任意顺序分配。对偶数和奇数 Context ID 的分配限制存在以避免端点之间需要同步。然而，一旦分配了 Context ID，这些限制不再适用于该 Context ID 的使用；任何客户端或 UDP 代理均可使用它，无论最初由哪一端分配。¶

注册是端点将给定 Context ID 的语义和格式告知其对端的动作。本文档不定义注册如何发生。未来的扩展 MAY 使用 HTTP 头字段或 capsule 来注册 Context ID。根据所使用的方法，可能会出现带有尚未注册的 Context ID 的数据报被接收的情况。例如，这可能由于承载数据报的分组与承载注册消息的分组在传输过程中发生重排序导致。¶

5. HTTP 数据报负载格式

当 HTTP 数据报（参见 RFC9297 第 2 节）与 UDP 代理请求流相关联时， HTTP Datagram Payload 字段具有在 图 7 中定义的格式，使用 RFC9000 第 1.3 节 的记法。注意，当 HTTP 数据报使用 QUIC DATAGRAM 帧 [QUIC-DGRAM] 编码时，下述 Context ID 字段直接跟在 Quarter Stream ID 字段之后，而 Quarter Stream ID 位于 QUIC DATAGRAM 帧负载的开始；参见 RFC9297 第 2.1 节。¶

UDP Proxying HTTP Datagram Payload {
  Context ID (i),
  UDP Proxying Payload (..),
}

Context ID:

一个可变长度整数（参见 RFC9000 第 16 节 的说明），包含 Context ID 的数值。如果接收到携带未知 Context ID 的 HTTP/3 数据报，接收方 SHALL 要么静默丢弃该数据报，要么在等待相应 Context ID 注册期间暂时缓冲该数据报（大约一个往返时间量级）。¶

UDP Proxying Payload:

数据报的有效载荷，其语义取决于前一字段的值。注意该字段可以为空。¶

使用 Context ID 为零的 HTTP 数据报对 UDP 数据包进行编码。当 Context ID 字段为零时，UDP Proxying Payload 字段包含 UDP 数据包的未修改有效载荷（在 [UDP] 中称为数据八位组）。¶

由于 UDP 头的定义（参见 [UDP]），无法编码超过 65527 字节的 UDP 有效载荷。因此，端点 MUST NOT 发送 UDP Proxying Payload 字段长度超过 65527 的使用 Context ID 为零的 HTTP 数据报。接收到使用 Context ID 为零且 UDP Proxying Payload 字段长度超过 65527 的 HTTP 数据报的端点 MUST 中止对应的流。如果 UDP 代理知道由于其底层链路 MTU 限制只能发送特定长度的 UDP 包，那么它别无选择，只能丢弃那些 UDP Proxying Payload 字段长度超过该限制的传入 HTTP 数据报。如果被丢弃的 HTTP 数据报是由 DATAGRAM capsule 传输的，接收方 SHOULD 在不缓冲该 capsule 内容的情况下丢弃该 capsule。¶

如果 UDP 代理在收到相应请求之前收到 HTTP 数据报，它 SHALL 要么静默丢弃该 HTTP 数据报，要么在等待对应请求期间暂时缓冲它（大约一个往返时间量级）。¶

注意，缓冲数据报（无论是因为尚未收到请求，还是因为 Context ID 尚未知）都会消耗资源。缓冲数据报的接收方 SHOULD 应用缓冲限制以降低发生资源耗尽的风险。例如，接收方可以限制缓冲数据报的总数或按每流、每上下文或每连接累计缓冲数据报的大小。¶

客户端 MAY 在收到其 UDP 代理请求的响应之前，乐观地开始在 HTTP 数据报中发送 UDP 数据包。然而，实现者应注意，如果代理对请求响应失败，或者代理在请求到达之前收到被代理的数据包并选择不进行缓冲，则这些被代理的数据包可能不会被 UDP 代理处理。¶

6. 性能注意事项

突发性流量常常导致时间相关的分组丢失；反过来，这会导致在 UDP 上运行的协议的拥塞控制器做出次优反应。为避免这种情况，UDP 代理 SHOULD 力求避免增加 UDP 流量的突发性；它们 SHOULD NOT 为了增加批量处理而对数据包进行排队。¶

当被代理的在 UDP 上运行的协议使用拥塞控制（例如 [QUIC]）时， 被代理流量至少会遭遇两个嵌套的拥塞控制器。底层的 HTTP 连接 MUST NOT 在没有渠道外的、能够绝对确定内部流量已受拥塞控制的方式的情况下禁用拥塞控制。¶

如果包含 UDP 代理请求流的连接上的客户端或 UDP 代理禁用了拥塞控制，则它 MUST NOT 在该连接上声明对 ECN [ECN] 的支持。也就是说，它 MUST 将所有 IP 头标记为 Not-ECT。它 MAY 继续通过 QUIC 的 ACK_ECN 帧或 TCP 的 ECE 位报告 ECN 反馈，因为对端可能并未禁用拥塞控制。¶

当被代理的在 UDP 上运行的协议使用丢失恢复（例如 [QUIC]），且底层 HTTP 连接运行在 TCP 之上时，被代理流量将至少遭遇两层嵌套的丢失恢复机制。这可能会降低性能，因为两者有时可能独立地重传相同数据。为避免此情况，UDP 代理 SHOULD 在 HTTP/3 上执行，以便利用 QUIC DATAGRAM 帧。¶

7. 安全性考虑

允许任意客户端建立到任意目标的隧道存在重大风险，因为这可能允许不法分子发送流量并使其归因于 UDP 代理。支持 UDP 代理的 HTTP 服务器应限制其使用，仅允许经过认证的用户使用。¶

存在基于传入请求源 IP 地址执行访问控制检查的软件和网络部署。例如，某些软件若来自 127.0.0.1 则允许未认证的配置更改。此类软件可能运行在与 UDP 代理相同的主机上或同一广播域中。被代理的 UDP 流量将以来自 UDP 代理的源 IP 地址到达目标。如果该源地址被用于访问控制，UDP 代理客户端可能利用 UDP 代理提升其访问权限，超出其原本应有的权限。除非 UDP 代理禁止对易受攻击的目标（例如 UDP 代理自身的地址、本地主机、链路本地、多播和广播地址）进行 UDP 代理请求，否则这可能导致未经授权的访问。UDP 代理在拒绝此类请求时可以使用来自 PROXY-STATUS 第 2.3.5 节 的 destination_ip_prohibited 代理错误类型。¶

在将其作为滥用基础设施以支持拒绝服务（DoS）攻击时，UDP 代理与 TCP CONNECT 代理具有许多相似性。两者都可以隐藏攻击者的源地址不被攻击目标看到。在无状态的大量流量攻击（例如 TCP SYN 洪泛或 UDP 洪泛）中，两种类型的代理都会将流量传递给目标。对于通过 TCP CONNECT 代理发送的有状态大量流量攻击（例如 HTTP 洪泛），代理仅在目标通过 TCP SYN-ACK 表示愿意接收数据时才会发送数据。一旦到目标的路径被洪泛，TCP CONNECT 代理将不再接收来自目标的回复并停止发送数据。由于 UDP 不在 UDP 代理与目标之间建立共享状态，UDP 代理在此类情况下可能会继续向目标发送数据。虽然 UDP 代理可以在观察到来自目标的响应之前限制其愿意转发的 UDP 包数，但当攻击目标为会响应的开放 UDP 端口时，这对防止 DoS 攻击的保护有限，因为协议的响应会被解释为目标愿意接收 UDP，且此类数据包限制也可能对合法流量产生问题。¶

适用于 RFC9297 第 4 节 中所描述的 HTTP 数据报的安全性考虑也适用于此处。由于可通过 UDP 隧道传输 IP 分组，[TUNNEL-SECURITY] 中的指导也可能适用。¶

8. IANA 考量

致谢

本文档为 MASQUE 工作组的产物，作者感谢所有 MASQUE 愛好者的贡献。该提案直接或间接地受许多人的先前工作启发，特别是 [HELIUM]（作者 Ben Schwartz）、[HiNT]（作者 Lucas Pardue）以及作者本人最初的 MASQUE 协议草案 [MASQUE-ORIGINAL]。¶

作者感谢 Eric Rescorla 建议使用 HTTP 方法来代理 UDP。作者还感谢 Mark Nottingham 和 Lucas Pardue 对本文档的诸多改进。本文档中的可扩展性设计源自 HTTP 数据报设计团队，该团队成员包括 Alan Frindell、Alex Chernyakhovsky、Ben Schwartz、Eric Rescorla、Lucas Pardue、Marcus Ihlar、Martin Thomson、Mike Bishop、Tommy Pauly、Victor Vasiliev 以及本文档作者。¶

作者联系方式