RFC9443 QUIC的多路复用更新

状态：	建议标准
更新：	5764、 7983
更多信息：	数据追踪\| 知识产权\| 信息页
组织：	互联网工程工作组（IETF）
RFC编号：	9443
更新：	5764、 7983
分类：	标准追踪
出版时间：	2023年7月
国际标准期刊编号：	2070-1721
作者：	B. Aboba Microsoft Corporation	G. Salgueiro Cisco Systems	C. Perkins University of Glasgow

RFC 7983为实时传输协议（Real-time Transport Protocol，RTP）接受方定义了一种方案，将到达单个端口的报文传输层安全（Datagram Transport Layer Security，DTLS）、NAT会话遍历工具集（Session Traversal Utilities for NAT，STUN）、安全实时传输协议（Secure Real-time Transport Protocol，SRTP）/安全实时传输控制协议（Secure Real-time Transport Control Protocol，SRTCP）、ZRTP、以及环NAT中继遍历（Traversal Using Relays around NAT，TURN）通道的数据包解除复用。本文更新RFC 7983及5764，以支持QUIC包在单个接受套接字（socket）上进行多路复用。

备忘状态

本文是互联网标准追踪文档。

本文产自互联网工程任务组（IETF），已接受公开审查，并由互联网互联网工程指导委员会（IESG）批准出版。更多互联网标准相关信息详见RFC 7841第2章。

关于本文当前状态、勘误及反馈方式等相关信息请移步https://www.rfc-editor.org/info/rfc9443。

版权声明

本文遵守BCP 78及在本文发布之日起生效的IETF信托涉及IETF文档的法律条文（https://trustee.ietf.org/license-info）。请仔细阅读相关条文，因为其描述了你对本文所有的权利及限制。从本文中摘录的代码组件必须包含信托法律条文第4.e章的简版BSD License文件，并且不附带任何该文件所描述的保证。

1. 引言

“安全实时传输协议（SRTP）扩展用于数据报传输层安全（DTLS）的多路复用方案更新”RFC7983为实时传输协议（RTP）RFC3550接收方定义了一种方案，将到达单个端口的DTLSRFC9147、NAT会话遍历工具集（STUN）RFC8489、安全实时传输协议（SRTP）/安全实时传输控制协议（SRTCP）RFC3711、ZRTPRFC6189以及环NAT中继遍历（TURN）通道的数据包解除复用。本文更新[RFC7983]和"数据报传输层安全（DTLS）扩展用于建立安全实时传输协议（SRTP）密钥"[RFC5764]，以允许QUIC[RFC9000]在同一端口上进行多路复用。

本文描述的多路复用方案支持多种使用场景。在[P2P-QUIC]和[P2P-QUIC-TRIAL]中描述的WebRTC场景中，SRTP传输音视频，而点对点QUIC用于数据交换。对于这种使用场景，SRTPRFC3711使用DTLS-SRTP[RFC5764]生成密钥；因此，SRTP/SRTCP[RFC3550]、STUN、TURN、DTLS和QUIC需要在同一端口上多路复用。如果SRTP使用QUIC-SRTP（尚未规范）生成密钥，那么SRTP/SRTCP、STUN、TURN和QUIC需要在同一端口上多路复用。如果QUIC既用于点对点数据传输，又用于RTP/RTCP[RTP-OVER-QUIC]传输，那么STUN、TURN和QUIC需要在同一端口上多路复用。

虽然本文描述的方案与QUIC版本2RFC9369兼容，但与QUIC比特润滑RFC9287不兼容。因此，希望在其套接字上使用多路复用的端点必须不发送grease_quic_bit传输参数。

1.1. 术语

本文中的关键字"必须（MUST）"、“必须不（MUST NOT）"、“需要（REQUIRED）"、“强烈要求（SHALL）"、“强烈要求不（SHALL NOT）"、“应该（SHOULD）"、“不应该（SHOULD NOT）"、“推荐（RECOMMENDED）"、“不推荐（NOT RECOMMENDED）"、“可以（MAY）“以及"可选（OPTIONAL）“应按照BCP 14[RFC2119][RFC8174]中的描述进行解释，仅当它们以大写形式出现时，才如此处所示。

2. TURN通道的多路复用

TURN通道是一种优化，其中数据报文使用4字节前缀进行交换，而非标准的36字节STUN开销（参见RFC8656第3.5章）。RFC7983分配了64到79的值，以便在TURN客户端执行通道绑定请求并与RFC7983中描述的多路复用方案结合使用时，能够解除复用TURN通道。

在没有QUIC比特润滑的情况下，QUIC报文的第一个八位组（例如QUIC v1或v2中的短头部报文）可能落在64到127的范围内，从而与分配给TURN通道的64到79范围重叠。然而，在实际应用中，这种重叠并不构成问题。TURN通道报文只会从已发送TURN分配和通道绑定请求的TURN服务器接收到。因此，从TURN服务器的源IP地址和端口接收报文的TURN客户端只需要区分STUN（即常规TURN）报文和TURN通道报文；（S）RTP、（S）RTCP、ZRTP、DTLS或QUIC报文不会从先前响应过TURN分配或通道绑定请求的源IP地址和端口发送。

因此，如果报文的源IP地址和端口与响应的TURN服务器不匹配，那么第一个八位组为64到127的报文可以明确解除复用为QUIC。

3. 对RFC 7983的更新

本文更新[RFC7983]第7章（该章节进而更新[RFC5764]）的内容如下：

旧文本

解除复用报文的过程如下。接收方查看报文的第一个字节。如果该字节的值在0到3之间（含），则该报文为STUN。如果该值在16到19之间（含），则该报文为ZRTP。如果该值在20到63之间（含），则该报文为DTLS。如果该值在64到79之间（含），则该报文为TURN通道。如果该值在128到191之间（含），则该报文为RTP（或RTCP，如果RTCP和RTP都在同一目的端口上多路复用）。如果该值不匹配任何已知范围，则该报文必须被丢弃，并且可以记录告警。该过程总结在图3中。

                 +----------------+
                 |        [0..3] -+--> 转发给STUN
                 |                |
                 |      [16..19] -+--> 转发给ZRTP
                 |                |
      报文 -->  |      [20..63] -+--> 转发给DTLS
                 |                |
                 |      [64..79] -+--> 转发给TURN通道
                 |                |
                 |    [128..191] -+--> 转发给RTP/RTCP
                 +----------------+

图3：DTLS-SRTP接收方的报文多路复用算法

旧文本结束

新文本

解除复用报文的过程如下。接收方查看报文的第一个字节。如果该字节的值在0到3之间（含），则该报文为STUN。如果该值在16到19之间（含），则该报文为ZRTP。如果该值在20到63之间（含），则该报文为DTLS。如果该值在128到191之间（含），则该报文为RTP（或RTCP，如果RTCP和RTP都在同一目的端口上多路复用）。如果该值在80到127之间（含）或192到255之间（含），则该报文为QUIC。如果该值在64到79之间（含）且报文的源IP地址和端口为响应的TURN服务器，则该报文为TURN通道；如果源IP地址和端口不是响应的TURN服务器，则该报文为QUIC。

如果该值不匹配任何已知范围，则该报文必须被丢弃，并且可以记录告警。该过程总结在图3中。

注：希望解除复用QUIC的端点必须不发送grease_quic_bit传输参数，如[RFC9287]中所述。

                +----------------+
                |        [0..3] -+--> 转发给STUN
                |                |
                |       [4..15] -+--> 丢弃
                |                |
                |      [16..19] -+--> 转发给ZRTP
                |                |
      报文 -->  |      [20..63] -+--> 转发给DTLS
                |                |
                |      [64..79] -+--> 转发给TURN通道（如果来自TURN服务器），否则为QUIC
                |                |
                |     [80..127] -+--> 转发给QUIC
                |                |
                |    [128..191] -+--> 转发给RTP/RTCP
                |                |
                |    [192..255] -+--> 转发给QUIC
                +----------------+

图3：接收方的报文解除复用算法

新文本结束

4. 安全性考虑

本文讨论的解决方案可能会引入一些超出RFC7983中描述的额外安全问题。这些额外的考虑事项描述如下。

为了支持QUIC的多路复用，本文向RFC7983中定义的方案添加了逻辑。如果实现不当，该逻辑可能会错误分类报文，使协议处理程序暴露于意外输入。

当QUIC仅用于数据交换时，QUIC内的TLS交换RFC9001推导的密钥仅用于保护QUIC数据报文。如果正确实现，这不应该影响SRTP的传输或通过DTLS-SRTP推导SRTP密钥。然而，如果未来的规范定义使用QUIC内的TLS交换来推导SRTP密钥，那么传输和SRTP密钥推导都可能受到QUIC实现中漏洞的不利影响。

5. IANA考虑

在"TLS ContentType"注册表中，IANA已将对RFC7983的引用替换为对本文的引用。

6. 参考文献

6.1. 规范性参考文献

[RFC2119] RFC文档中用于指出要求级别的关键字

Bradner, S., “Key words for use in RFCs to Indicate Requirement Levels”, BCP 14, RFC 2119, DOI 10.17487/RFC2119, March 1997, <https://www.rfc-editor.org/info/rfc2119>.

[RFC3550]

Schulzrinne, H., Casner, S., Frederick, R., and V. Jacobson, “RTP: A Transport Protocol for Real-time Applications”, STD 64, RFC 3550, DOI 10.17487/RFC3550, July 2003, <https://www.rfc-editor.org/info/rfc3550>.

[RFC3711]

Baugher, M., McGrew, D., Naslund, M., Carrara, E., and K. Norrman, “The Secure Real-time Transport Protocol (SRTP)”, RFC 3711, DOI 10.17487/RFC3711, March 2004, <https://www.rfc-editor.org/info/rfc3711>.

[RFC5764]

McGrew, D. and E. Rescorla, “Datagram Transport Layer Security (DTLS) Extension to Establish Keys for the Secure Real-time Transport Protocol (SRTP)”, RFC 5764, DOI 10.17487/RFC5764, May 2010, <https://www.rfc-editor.org/info/rfc5764>.

[RFC7983]

Petit-Huguenin, M. and G. Salgueiro, “Multiplexing Scheme Updates for Secure Real-time Transport Protocol (SRTP) Extension for Datagram Transport Layer Security (DTLS)”, RFC 7983, DOI 10.17487/RFC7983, September 2016, <https://www.rfc-editor.org/info/rfc7983>.

[RFC8174] RFC2119中关键字大写与小写的歧义

Leiba, B., “Ambiguity of Uppercase vs Lowercase in RFC 2119 Key Words”, BCP 14, RFC 8174, DOI 10.17487/RFC8174, May 2017, <https://www.rfc-editor.org/info/rfc8174>.

[RFC8489]

Petit-Huguenin, M., Salgueiro, G., Rosenberg, J., Wing, D., Mahy, R., and P. Matthews, “Session Traversal Utilities for NAT (STUN)”, RFC 8489, DOI 10.17487/RFC8489, February 2020, <https://www.rfc-editor.org/info/rfc8489>.

[RFC8656]

Reddy, T., Ed., Johnston, A., Ed., Matthews, P., and J. Rosenberg, “Traversal Using Relays around NAT (TURN): Relay Extensions to Session Traversal Utilities for NAT (STUN)”, RFC 8656, DOI 10.17487/RFC8656, February 2020, <https://www.rfc-editor.org/info/rfc8656>.

[RFC9000]

Iyengar, J., Ed. and M. Thomson, Ed., “QUIC: A UDP-Based Multiplexed and Secure Transport”, RFC 9000, DOI 10.17487/RFC9000, May 2021, <https://www.rfc-editor.org/info/rfc9000>.

[RFC9001]

Thomson, M., Ed. and S. Turner, Ed., “Using TLS to Secure QUIC”, RFC 9001, DOI 10.17487/RFC9001, May 2021, <https://www.rfc-editor.org/info/rfc9001>.

[RFC9147]

Rescorla, E., Tschofenig, H., and N. Modadugu, “The Datagram Transport Layer Security (DTLS) Protocol Version 1.3”, RFC 9147, DOI 10.17487/RFC9147, April 2022, <https://www.rfc-editor.org/info/rfc9147>.

[RFC9287]

Thomson, M., “Greasing the QUIC Bit”, RFC 9287, DOI 10.17487/RFC9287, August 2022, <https://www.rfc-editor.org/info/rfc9287>.

6.2. 资料性参考文献

[P2P-QUIC]

Thatcher, P., Aboba, B., and R. Raymond, “QUIC API For Peer-to-Peer Connections”, W3C Community Group Draft Report, commit 50d79c0, 20 May 2023, <https://www.w3.org/p2p-webtransport/>.

[P2P-QUIC-TRIAL]

Hampson, S., “RTCQuicTransport Coming to an Origin Trial Near You (Chrome 73)”, January 2019, <https://developer.chrome.com/blog/rtcquictransport-api/>.

[RFC6189]

Zimmermann, P., Johnston, A., Ed., and J. Callas, “ZRTP: Media Path Key Agreement for Unicast Secure RTP”, RFC 6189, DOI 10.17487/RFC6189, April 2011, <https://www.rfc-editor.org/info/rfc6189>.

[RFC9369]

Duke, M., “QUIC Version 2”, RFC 9369, DOI 10.17487/RFC9369, May 2023, <https://www.rfc-editor.org/info/rfc9369>.

[RTP-OVER-QUIC]

Ott, J., Engelbart, M., and S. Dawkins, “RTP over QUIC”, Work in Progress, Internet-Draft, draft-ietf-avtcore-rtp-over-quic-04, 10 July 2023, <https://datatracker.ietf.org/doc/html/draft-ietf-avtcore-rtp-over-quic-04>.

联系作者

Bernard Aboba

Microsoft Corporation

One Microsoft Way

Redmond, WA 98052

United States of America

Email: bernard.aboba@gmail.com

Gonzalo Salgueiro

Cisco Systems

7200-12 Kit Creek Road

Research Triangle Park, NC 27709

United States of America

Email: gsalguei@cisco.com

Colin Perkins

School of Computing Science

University of Glasgow

Glasgow

G12 8QQ

United Kingdom

Email: csp@csperkins.org

RFC9443中文：QUIC多路复用