[要約] RFC 9443 は、RTP 受信者が複数のプロトコルを1つのポートで受信するためのスキームを更新し、QUIC パケットの受信を可能にすることを目的としています。
Internet Engineering Task Force (IETF) B. Aboba
Request for Comments: 9443 Microsoft Corporation
Updates: 5764, 7983 G. Salgueiro
Category: Standards Track Cisco Systems
ISSN: 2070-1721 C. Perkins
University of Glasgow
July 2023
RFC 7983 defines a scheme for a Real-time Transport Protocol (RTP) receiver to demultiplex Datagram Transport Layer Security (DTLS), Session Traversal Utilities for NAT (STUN), Secure Real-time Transport Protocol (SRTP) / Secure Real-time Transport Control Protocol (SRTCP), ZRTP, and Traversal Using Relays around NAT (TURN) channel packets arriving on a single port. This document updates RFC 7983 and RFC 5764 to also allow QUIC packets to be multiplexed on a single receiving socket.
RFC 7983は、リアルタイムトランスポートプロトコル（RTP）レシーバーのスキームを定義します。データグラム輸送層セキュリティ（DTLS）、NAT（STUN）のセッショントラバーサルユーティリティ、セキュアリアルタイムトランスポートプロトコル（SRTP） /セキュアリアルタイムトランスポート単一のポートに到着するNAT（ターン）チャネルパケットの周りのリレーを使用して、コントロールプロトコル（SRTCP）、ZRTP、およびトラバーサル。このドキュメントは、RFC 7983とRFC 5764を更新して、QUICパケットを単一の受信ソケットで多重化することもできます。
This is an Internet Standards Track document.
これは、インターネット標準トラックドキュメントです。
This document is a product of the Internet Engineering Task Force (IETF). It represents the consensus of the IETF community. It has received public review and has been approved for publication by the Internet Engineering Steering Group (IESG). Further information on Internet Standards is available in Section 2 of RFC 7841.
このドキュメントは、インターネットエンジニアリングタスクフォース（IETF）の製品です。IETFコミュニティのコンセンサスを表しています。公開レビューを受けており、インターネットエンジニアリングステアリンググループ（IESG）からの出版が承認されています。インターネット標準の詳細については、RFC 7841のセクション2で入手できます。
Information about the current status of this document, any errata, and how to provide feedback on it may be obtained at https://www.rfc-editor.org/info/rfc9443.
このドキュメントの現在のステータス、任意のERRATA、およびそのフィードバックを提供する方法に関する情報は、https：//www.rfc-editor.org/info/rfc9443で取得できます。
Copyright (c) 2023 IETF Trust and the persons identified as the document authors. All rights reserved.
著作権（c）2023 IETF Trustおよび文書著者として特定された人。無断転載を禁じます。
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.
このドキュメントは、BCP 78およびIETFドキュメント（https://trustee.ietf.org/license-info）に関連するIETF Trustの法的規定の対象となります。この文書に関するあなたの権利と制限を説明するので、これらの文書を注意深く確認してください。このドキュメントから抽出されたコードコンポーネントには、セクション4.Eで説明されている法的規定のセクション4.Eで説明されており、改訂されたBSDライセンスで説明されている保証なしで提供されるように、改訂されたBSDライセンステキストを含める必要があります。
1. Introduction
1.1. Terminology
2. Multiplexing of TURN Channels
3. Updates to RFC 7983
4. Security Considerations
5. IANA Considerations
6. References
6.1. Normative References
6.2. Informative References
Acknowledgments
Authors' Addresses
"Multiplexing Scheme Updates for Secure Real-time Transport Protocol (SRTP) Extension for Datagram Transport Layer Security (DTLS)" [RFC7983] defines a scheme for a Real-time Transport Protocol (RTP) [RFC3550] receiver to demultiplex DTLS [RFC9147], Session Traversal Utilities for NAT (STUN) [RFC8489], Secure Real-time Transport Protocol (SRTP) / Secure Real-time Transport Control Protocol (SRTCP) [RFC3711], ZRTP [RFC6189], and Traversal Using Relays around NAT (TURN) channel packets arriving on a single port. This document updates [RFC7983] and "Datagram Transport Layer Security (DTLS) Extension to Establish Keys for the Secure Real-time Transport Protocol (SRTP)" [RFC5764] to also allow QUIC [RFC9000] to be multiplexed on the same port.
「Datagram Transport Layer Security（DTLS）のセキュアリアルタイム輸送プロトコル（SRTP）拡張のためのマルチプレックススキーム更新」[RFC7983]は、リアルタイムトランスポートプロトコル（RTP）[RFC3550]レシーバーのスキームを定義します。、NAT（STUN）[RFC8489]のセッショントラバーサルユーティリティ、セキュアリアルタイム輸送プロトコル（SRTP） /セキュアリアルタイムトランスポートコントロールプロトコル（SRTCP）[RFC3711]、ZRTP [RFC6189]、およびNATの周りのリレーを使用したトラバーサル）単一のポートに到着するチャネルパケット。このドキュメントは、[RFC7983]と「データグラム輸送層セキュリティ（DTLS）拡張機能を更新し、安全なリアルタイムトランスポートプロトコル（SRTP）のキーを確立します」[RFC5764]を使用して、同じポートでQUIC [RFC9000]を多重化することもできます。
The multiplexing scheme described in this document supports multiple use cases. In the WebRTC scenarios described in [P2P-QUIC] and [P2P-QUIC-TRIAL], SRTP transports audio and video while peer-to-peer QUIC is used for data exchange. For this use case, SRTP [RFC3711] is keyed using DTLS-SRTP [RFC5764]; therefore, SRTP/SRTCP [RFC3550], STUN, TURN, DTLS, and QUIC need to be multiplexed on the same port. Were SRTP to be keyed using QUIC-SRTP (not yet specified), SRTP/ SRTCP, STUN, TURN, and QUIC would need to be multiplexed on the same port. Where QUIC is used for peer-to-peer transport of data as well as RTP/RTCP [RTP-OVER-QUIC], STUN, TURN, and QUIC need to be multiplexed on the same port.
このドキュメントで説明されている多重化スキームは、複数のユースケースをサポートしています。[P2P-Quic]および[P2P-Quic-Trial]で説明されているWeBRTCシナリオでは、SRTPはオーディオとビデオをトランスポートし、ピアツーピアのQUICはデータ交換に使用されます。このユースケースでは、SRTP [RFC3711]はDTLS-SRTP [RFC5764]を使用してキー化されています。したがって、SRTP/SRTCP [RFC3550]、スタン、ターン、DTLS、およびQUICを同じポートで多重化する必要があります。QUIC-SRTP（まだ指定されていない）を使用してSRTPをキー化する場合、SRTP/ SRTCP、STUN、ターン、およびQUICを同じポートで多重化する必要があります。データのピアツーピア輸送とRTP/RTCP [rtp-over-quic]にquicが使用されている場合、同じポートでマルチプレックスする必要があります。
While the scheme described in this document is compatible with QUIC version 2 [RFC9369], it is not compatible with QUIC bit greasing [RFC9287]. As a result, endpoints that wish to use multiplexing on their socket MUST NOT send the grease_quic_bit transport parameter.
このドキュメントで説明されているスキームは、QUICバージョン2 [RFC9369]と互換性がありますが、QUICビットグリース[RFC9287]と互換性はありません。その結果、ソケットでマルチプレックスを使用したいエンドポイントは、Grease_Quic_bit Transportパラメーターを送信してはなりません。
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in BCP 14 [RFC2119] [RFC8174] when, and only when, they appear in all capitals, as shown here.
この文書のキーワード "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", および "OPTIONAL" はBCP 14 [RFC2119] [RFC8174]で説明されているように、すべて大文字の場合にのみ解釈されます。
TURN channels are an optimization where data packets are exchanged with a 4-byte prefix instead of the standard 36-byte STUN overhead (see Section 3.5 of [RFC8656]). [RFC7983] allocates the values from 64 to 79 in order to allow TURN channels to be demultiplexed when the TURN client does the channel binding request in combination with the demultiplexing scheme described in [RFC7983].
ターンチャネルは、標準の36バイトスタンオーバーヘッドの代わりに、データパケットが4バイトプレフィックスと交換される最適化です（[RFC8656]のセクション3.5を参照）。[RFC7983]は、[RFC7983]に記載されている非拡張スキームと組み合わせてチャネルバインディング要求を行うと、ターンチャネルを非難することを許可するために、64から79の値を割り当てます。
In the absence of QUIC bit greasing, the first octet of a QUIC packet (e.g. a short header packet in QUIC v1 or v2) may fall in the range 64 to 127, thereby overlapping with the allocated range for TURN channels of 64 to 79. However, in practice this overlap does not represent a problem. TURN channel packets will only be received from a TURN server to which TURN allocation and channel-binding requests have been sent. Therefore, a TURN client receiving packets from the source IP address and port of a TURN server only needs to disambiguate STUN (i.e., regular TURN) packets from TURN channel packets; (S)RTP, (S)RTCP, ZRTP, DTLS, or QUIC packets will not be sent from a source IP address and port that had previously responded to TURN allocation or channel-binding requests.
QUICビットグリースがない場合、QUICパケットの最初のオクテット（たとえば、QUIC V1またはV2の短いヘッダーパケット）は64〜127の範囲に落ちる可能性があり、それにより64〜79のターンチャネルの割り当てられた範囲と重なります。ただし、実際には、この重複は問題を表していません。ターンチャネルパケットは、ターン割り当てとチャネルバインディングリクエストが送信されたターンサーバーからのみ受信されます。したがって、ソースIPアドレスからパケットを受信しているターンクライアントとターンサーバーのポートは、ターンチャネルパケットからスタン（つまり、通常のターン）パケットを明確にする必要があります。（S）RTP、（S）RTCP、ZRTP、DTLS、またはQUICパケットは、以前に配分またはチャネルバインディングリクエストを回すために応答したソースIPアドレスとポートから送信されません。
As a result, if the source IP address and port of a packet do not match that of a responding TURN server, a packet with a first octet of 64 to 127 can be unambiguously demultiplexed as QUIC.
その結果、パケットのソースIPアドレスとポートが応答性のあるターンサーバーのアドレスと一致しない場合、64〜127の最初のオクテットを持つパケットは、QUICとして明確に逆流します。
This document updates the text in Section 7 of [RFC7983] (which in turn updates [RFC5764]) as follows:
このドキュメントは、[RFC7983]のセクション7（次の[RFC5764]を更新する）のテキストを次のように更新します。
OLD TEXT
古いテキスト
The process for demultiplexing a packet is as follows. The receiver looks at the first byte of the packet. If the value of this byte is in between 0 and 3 (inclusive), then the packet is STUN. If the value is between 16 and 19 (inclusive), then the packet is ZRTP. If the value is between 20 and 63 (inclusive), then the packet is DTLS. If the value is between 64 and 79 (inclusive), then the packet is TURN Channel. If the value is in between 128 and 191 (inclusive), then the packet is RTP (or RTCP, if both RTCP and RTP are being multiplexed over the same destination port). If the value does not match any known range, then the packet MUST be dropped and an alert MAY be logged. This process is summarized in Figure 3.
パケットを逆プレックスするプロセスは次のとおりです。受信者は、パケットの最初のバイトを見ます。このバイトの値が0〜3（包括的）の間にある場合、パケットはスタンします。値が16〜19（包括的）の場合、パケットはzrtpです。値が20〜63（包括的）の場合、パケットはDTLSです。値が64〜79（包括的）の場合、パケットはターンチャネルです。値が128から191（包括的）の間にある場合、パケットはRTP（またはRTCP、RTCPとRTPの両方が同じ宛先ポートで多重化されている場合）です。値が既知の範囲と一致しない場合、パケットをドロップし、アラートを記録する必要があります。このプロセスを図3にまとめます。
+----------------+
| [0..3] -+--> forward to STUN
| |
| [16..19] -+--> forward to ZRTP
| |
packet --> | [20..63] -+--> forward to DTLS
| |
| [64..79] -+--> forward to TURN Channel
| |
| [128..191] -+--> forward to RTP/RTCP
+----------------+
Figure 3: The DTLS-SRTP receiver's packet demultiplexing algorithm.
END OLD TEXT
古いテキストを終了します
NEW TEXT
新しいテキスト
The process for demultiplexing a packet is as follows. The receiver looks at the first byte of the packet. If the value of this byte is between 0 and 3 (inclusive), then the packet is STUN. If the value is between 16 and 19 (inclusive), then the packet is ZRTP. If the value is between 20 and 63 (inclusive), then the packet is DTLS. If the value is between 128 and 191 (inclusive), then the packet is RTP (or RTCP, if both RTCP and RTP are being multiplexed over the same destination port). If the value is between 80 and 127 (inclusive) or between 192 and 255 (inclusive), then the packet is QUIC. If the value is between 64 and 79 (inclusive) and the packet has a source IP address and port of a responding TURN server, then the packet is TURN channel; if the source IP address and port are not that of a responding TURN server, then the packet is QUIC.
パケットを逆プレックスするプロセスは次のとおりです。受信者は、パケットの最初のバイトを見ます。このバイトの値が0〜3（包括的）の場合、パケットはスタンです。値が16〜19（包括的）の場合、パケットはzrtpです。値が20〜63（包括的）の場合、パケットはDTLSです。値が128〜191（包括的）の場合、パケットはRTPです（またはRTCPとRTPの両方が同じ宛先ポートで多重化されている場合）。値が80〜127（包括的）または192〜255（包括的）の間、パケットはQUICです。値が64〜79（包括的）の間で、パケットに応答するターンサーバーのソースIPアドレスとポートがある場合、パケットはターンチャネルです。ソースIPアドレスとポートが応答するターンサーバーのアドレスではない場合、パケットはQUICです。
If the value does not match any known range, then the packet MUST be dropped and an alert MAY be logged. This process is summarized in Figure 3.
値が既知の範囲と一致しない場合、パケットをドロップし、アラートを記録する必要があります。このプロセスを図3にまとめます。
+----------------+
| [0..3] -+--> forward to STUN
| |
| [4..15] -+--> DROP
| |
| [16..19] -+--> forward to ZRTP
| |
packet --> | [20..63] -+--> forward to DTLS
| |
| [64..79] -+--> forward to TURN Channel
| | (if from TURN server), else QUIC
| [80..127] -+--> forward to QUIC
| |
| [128..191] -+--> forward to RTP/RTCP
| |
| [192..255] -+--> forward to QUIC
+----------------+
Figure 3: The receiver's packet demultiplexing algorithm.
Note: Endpoints that wish to demultiplex QUIC MUST NOT send the grease_quic_bit transport parameter, as described in [RFC9287].
注：[RFC9287]で説明されているように、Demultiplex Quicを希望するエンドポイントは、Grease_Quic_bit Transportパラメーターを送信してはなりません。
END NEW TEXT
新しいテキストを終了します
The solution discussed in this document could potentially introduce some additional security issues beyond those described in [RFC7983]. These additional concerns are described below.
このドキュメントで説明されているソリューションは、[RFC7983]に記載されているものを超えて、いくつかの追加のセキュリティ問題を導入する可能性があります。これらの追加の懸念を以下に説明します。
In order to support multiplexing of QUIC, this document adds logic to the scheme defined in [RFC7983]. If misimplemented, the logic could potentially misclassify packets, exposing protocol handlers to unexpected input.
QUICの多重化をサポートするために、このドキュメントは[RFC7983]で定義されているスキームにロジックを追加します。誤ったとおりになった場合、ロジックはパケットを誤分類し、プロトコルハンドラーを予期しない入力に公開する可能性があります。
When QUIC is used solely for data exchange, the TLS-within-QUIC exchange [RFC9001] derives keys used solely to protect QUIC data packets. If properly implemented, this should not affect the transport of SRTP or the derivation of SRTP keys via DTLS-SRTP. However, if a future specification were to define use of the TLS-within-QUIC exchange to derive SRTP keys, both transport and SRTP key derivation could be adversely impacted by a vulnerability in the QUIC implementation.
QUICがデータ交換のみに使用される場合、TLS-within-quic Exchange [RFC9001]は、QUICデータパケットのみを保護するために使用されるキーを導き出します。適切に実装されている場合、これはSRTPの輸送またはDTLS-SRTPを介したSRTPキーの導出に影響しないはずです。ただし、将来の仕様がSRTPキーを導出するためにTLS-QUICエクスチェンジの使用を定義する場合、輸送とSRTPキーの両方の派生の両方が、QUIC実装の脆弱性によって悪影響を受ける可能性があります。
In the "TLS ContentType" registry, IANA replaced references to [RFC7983] with references to this document.
「TLS ContentType」レジストリでは、IANAは[RFC7983]への参照をこのドキュメントへの参照に置き換えました。
[RFC2119] 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] 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>.
[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>.
We would like to thank Martin Thomson, Roni Even, Jonathan Lennox, and other participants in the IETF QUIC and AVTCORE Working Groups for their discussion of the QUIC multiplexing issue, and their input relating to potential solutions.
Martin Thomson、Roni Even、Jonathan Lennox、およびIETF QUICおよびAVTCoreワーキンググループの他の参加者に、QUIC多重化の問題についての議論について、および潜在的なソリューションに関連する入力に感謝します。
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