rfc9443xml2.original.xml   rfc9443.xml 
<?xml version='1.0' encoding='utf-8'?> <?xml version="1.0" encoding="UTF-8"?>
<!DOCTYPE rfc SYSTEM "rfc2629.dtd" [
<!ENTITY RFC2119 SYSTEM "https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RF
C.2119.xml">
<!ENTITY RFC3550 SYSTEM "https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RF
C.3550.xml">
<!ENTITY RFC3711 SYSTEM "https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RF
C.3711.xml">
<!ENTITY RFC5764 SYSTEM "https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RF
C.5764.xml">
<!ENTITY RFC7983 SYSTEM "https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RF
C.7983.xml">
<!ENTITY RFC8174 SYSTEM "https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RF
C.8174.xml">
<!ENTITY RFC8489 SYSTEM "https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RF
C.8489.xml">
<!ENTITY RFC8656 SYSTEM "https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RF
C.8656.xml">
<!ENTITY RFC9000 SYSTEM "https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RF
C.9000.xml">
<!ENTITY RFC9001 SYSTEM "https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RF
C.9001.xml">
<!ENTITY RFC9147 SYSTEM "https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RF
C.9147.xml">
<!ENTITY RFC9287 SYSTEM "https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RF
C.9287.xml">
<!ENTITY I-D.ietf-avtcore-rtp-over-quic SYSTEM "https://xml2rfc.ietf.org/public/
rfc/bibxml3/reference.I-D.ietf-avtcore-rtp-over-quic.xml">
<!ENTITY I-D.ietf-quic-v2 SYSTEM "https://xml2rfc.ietf.org/public/rfc/bibxml3/re
ference.I-D.ietf-quic-v2.xml">
<!ENTITY RFC6189 SYSTEM "https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RF
C.6189.xml">
]>
<rfc submissionType="IETF" docName="draft-ietf-avtcore-rfc7983bis-09" category="
std" updates="7983, 5764" ipr="trust200902">
<!-- Generated by id2xml 1.5.0 on 2023-04-04T22:59:18Z -->
<?rfc strict="yes"?>
<?rfc compact="yes"?>
<?rfc subcompact="no"?>
<?rfc symrefs="yes"?>
<?rfc sortrefs="yes"?>
<?rfc text-list-symbols="o*+-"?>
<?rfc toc="yes"?>
<front>
<title>Multiplexing Scheme Updates for QUIC</title>
<author initials="B." surname="Aboba" fullname="Bernard Aboba">
<organization>Microsoft Corporation</organization>
<address><postal><street>One Microsoft Way</street>
<city>Redmond</city>
<region>WA</region>
<code>98052</code>
<country>United States of America</country>
</postal>
<email>bernard.aboba@gmail.com</email>
</address>
</author>
<author initials="G." surname="Salgueiro" fullname="Gonzalo Salgueiro"> <!DOCTYPE rfc [
<organization>Cisco Systems</organization> <!ENTITY nbsp "&#160;">
<address><postal><street>7200-12 Kit Creek Road</street> <!ENTITY zwsp "&#8203;">
<city>Research Triangle Park</city> <!ENTITY nbhy "&#8209;">
<region>NC</region> <!ENTITY wj "&#8288;">
<code>27709</code> ]>
<country>United States of America</country>
</postal>
<email>gsalguei@cisco.com</email>
</address>
</author>
<author initials="C." surname="Perkins" fullname="Colin Perkins"> <rfc xmlns:xi="http://www.w3.org/2001/XInclude" submissionType="IETF" category="
<organization abbrev="University of Glasgow">School of Computing Science< std" consensus="true" docName="draft-ietf-avtcore-rfc7983bis-09" number="9443" u
/organization> pdates="5764, 7983" ipr="trust200902" obsoletes="" xml:lang="en" symRefs="true"
<address><postal><street>University of Glasgow</street> sortRefs="true" tocInclude="true" version="3">
<city>Glasgow</city>
<code>G12 8QQ</code>
<country>United Kingdom</country>
</postal>
<email>csp@csperkins.org</email>
</address>
</author>
<date year="2023" month="April"/>
<area>art</area>
<workgroup>avtcore</workgroup>
<!-- [rfced] Please insert any keywords (beyond those that appear in the title) <!-- xml2rfc v2v3 conversion 3.17.0 -->
for use on https://www.rfc-editor.org/search. --> <!-- Generated by id2xml 1.5.0 on 2023-04-04T22:59:18Z -->
<front>
<title>Multiplexing Scheme Updates for QUIC</title>
<seriesInfo name="RFC" value="9443"/>
<author initials="B." surname="Aboba" fullname="Bernard Aboba">
<organization>Microsoft Corporation</organization>
<address>
<postal>
<street>One Microsoft Way</street>
<city>Redmond</city>
<region>WA</region>
<code>98052</code>
<country>United States of America</country>
</postal>
<email>bernard.aboba@gmail.com</email>
</address>
</author>
<author initials="G." surname="Salgueiro" fullname="Gonzalo Salgueiro">
<organization>Cisco Systems</organization>
<address>
<postal>
<street>7200-12 Kit Creek Road</street>
<city>Research Triangle Park</city>
<region>NC</region>
<code>27709</code>
<country>United States of America</country>
</postal>
<email>gsalguei@cisco.com</email>
</address>
</author>
<author initials="C." surname="Perkins" fullname="Colin Perkins">
<organization abbrev="University of Glasgow">School of Computing Science</
organization>
<address>
<postal>
<street>University of Glasgow</street>
<city>Glasgow</city>
<code>G12 8QQ</code>
<country>United Kingdom</country>
</postal>
<email>csp@csperkins.org</email>
</address>
</author>
<date year="2023" month="July"/>
<area>art</area>
<workgroup>avtcore</workgroup>
<keyword>example</keyword> <keyword>RTP</keyword>
<keyword>ZRTP</keyword>
<keyword>STUN</keyword>
<keyword>TURN</keyword>
<keyword>DTLS</keyword>
<abstract><t> <abstract>
<t>
RFC 7983 defines a scheme for a Real-time Transport Protocol (RTP) RFC 7983 defines a scheme for a Real-time Transport Protocol (RTP)
receiver to demultiplex Datagram Transport Layer Security (DTLS), receiver to demultiplex Datagram Transport Layer Security (DTLS),
Session Traversal Utilities for NAT (STUN), Secure Real-time Session Traversal Utilities for NAT (STUN), Secure Real-time
Transport Protocol (SRTP) / Secure Real-time Transport Control Transport Protocol (SRTP) / Secure Real-time Transport Control
Protocol (SRTCP), ZRTP and Traversal Using Relays around NAT (TURN) Protocol (SRTCP), ZRTP, and Traversal Using Relays around NAT (TURN)
Channel packets arriving on a single port. This document updates RFC 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 7983 and RFC 5764 to also allow QUIC packets to be multiplexed on a
single receiving socket.</t> single receiving socket.</t>
</abstract>
</abstract> </front>
</front> <middle>
<section anchor="sect-1" numbered="true" toc="default">
<middle> <name>Introduction</name>
<section title="Introduction" anchor="sect-1"><t> <t>
"Multiplexing Scheme Updates for Secure Real-time Transport Protocol (SRTP) E xtension for Datagram Transport Layer Security (DTLS)" "Multiplexing Scheme Updates for Secure Real-time Transport Protocol (SRTP) E xtension for Datagram Transport Layer Security (DTLS)"
<xref target="RFC7983"/> defines a scheme for a Real-time Transport Protocol <xref target="RFC7983" format="default"/> defines a scheme for a Real-time Tr
(RTP) ansport Protocol (RTP)
<xref target="RFC3550"/> receiver to demultiplex DTLS <xref target="RFC9147"/ <xref target="RFC3550" format="default"/> receiver to demultiplex DTLS <xref
>, Session Traversal target="RFC9147" format="default"/>, Session Traversal
Utilities for NAT (STUN) <xref target="RFC8489"/>, Secure Real-time Transport Utilities for NAT (STUN) <xref target="RFC8489" format="default"/>, Secure Re
al-time Transport
Protocol (SRTP) / Secure Real-time Transport Control Protocol (SRTCP) Protocol (SRTP) / Secure Real-time Transport Control Protocol (SRTCP)
<xref target="RFC3711"/>, ZRTP <xref target="RFC6189"/> and Traversal Using R <xref target="RFC3711" format="default"/>, ZRTP <xref target="RFC6189" format
elays around NAT ="default"/>, and Traversal Using Relays around NAT
(TURN) Channel packets arriving on a single port. This document (TURN) channel packets arriving on a single port. This document
updates <xref target="RFC7983"/> and "Datagram Transport Layer Security (DTLS updates <xref target="RFC7983" format="default"/> and "Datagram Transport Lay
) Extension to Establish Keys for the Secure Real-time Transport Protocol (SRTP) er Security (DTLS) Extension to Establish Keys for the Secure Real-time Transpor
" <xref target="RFC5764"/> to also allow QUIC <xref target="RFC9000"/> to be t Protocol (SRTP)" <xref target="RFC5764" format="default"/> to also allow QUIC
<xref target="RFC9000" format="default"/> to be
multiplexed on the same port.</t> multiplexed on the same port.</t>
<t> <t>
The multiplexing scheme described in this document supports multiple The multiplexing scheme described in this document supports multiple
use cases. Peer-to-peer QUIC in WebRTC scenarios, described in use cases. In the WebRTC scenarios described in <xref target="P2P-QUIC" forma
<xref target="P2P-QUIC"/> <xref target="P2P-QUIC-TRIAL"/>, transports audio a t="default"/> and <xref target="P2P-QUIC-TRIAL" format="default"/>, SRTP transpo
nd video over SRTP, rts audio and video while peer-to-peer QUIC is used for data exchange.
alongside QUIC, used for data exchange. For this use case, SRTP For this use case, SRTP
<xref target="RFC3711"/> is keyed using DTLS-SRTP <xref target="RFC5764"/> an <xref target="RFC3711" format="default"/> is keyed using DTLS-SRTP <xref targ
d therefore SRTP/SRTCP et="RFC5764" format="default"/>; therefore, SRTP/SRTCP
<xref target="RFC3550"/>, STUN, TURN, DTLS and QUIC need to be multiplexed on <xref target="RFC3550" format="default"/>, STUN, TURN, DTLS, and QUIC need to
the be multiplexed on the
same port. Were SRTP to be keyed using QUIC-SRTP (not yet same port. Were SRTP to be keyed using QUIC-SRTP (not yet
specified), SRTP/SRTCP, STUN, TURN and QUIC would need to be specified), SRTP/SRTCP, STUN, TURN, and QUIC would need to be
multiplexed on the same port. Where QUIC is used for peer-to-peer multiplexed on the same port. Where QUIC is used for peer-to-peer
transport of data as well as RTP/RTCP <xref target="I-D.ietf-avtcore-rtp-over transport of data as well as RTP/RTCP <xref target="I-D.ietf-avtcore-rtp-over
-quic"/> -quic" format="default"/>,
STUN, TURN and QUIC need to be multiplexed on the same port.</t> STUN, TURN, and QUIC need to be multiplexed on the same port.</t>
<t>
<t>
While the scheme described in this document is compatible with QUIC While the scheme described in this document is compatible with QUIC
version 2 <xref target="I-D.ietf-quic-v2"/>, it is not compatible with QUIC b version 2 <xref target="RFC9369" format="default"/>, it is not compatible wit
it h QUIC bit
greasing <xref target="RFC9287"/>. As a result, endpoints that wish to use greasing <xref target="RFC9287" format="default"/>. As a result, endpoints t
multiplexing on their socket MUST NOT send the grease_quic_bit hat wish to use
multiplexing on their socket <bcp14>MUST NOT</bcp14> send the grease_quic_bit
transport parameter.</t> transport parameter.</t>
<section anchor="sect-1.1" numbered="true" toc="default">
<section title="Terminology" anchor="sect-1.1"><t> <name>Terminology</name>
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", <t>
"SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and The key words "<bcp14>MUST</bcp14>", "<bcp14>MUST NOT</bcp14>",
"OPTIONAL" in this document are to be interpreted as described in BCP "<bcp14>REQUIRED</bcp14>", "<bcp14>SHALL</bcp14>", "<bcp14>SHALL NOT</bcp14>
14 <xref target="RFC2119"/> <xref target="RFC8174"/> when, and only when, the ",
y appear in all "<bcp14>SHOULD</bcp14>", "<bcp14>SHOULD NOT</bcp14>",
capitals, as shown here.</t> "<bcp14>RECOMMENDED</bcp14>", "<bcp14>NOT RECOMMENDED</bcp14>",
"<bcp14>MAY</bcp14>", and "<bcp14>OPTIONAL</bcp14>" in this document are to
</section> be
interpreted as described in BCP&nbsp;14 <xref target="RFC2119"/> <xref
</section> target="RFC8174"/> when, and only when, they appear in all capitals, as
shown here.
<section title="Multiplexing of TURN Channels" anchor="sect-2"><t> </t>
</section>
</section>
<section anchor="sect-2" numbered="true" toc="default">
<name>Multiplexing of TURN Channels</name>
<t>
TURN channels are an optimization where data packets are exchanged TURN channels are an optimization where data packets are exchanged
with a 4-byte prefix instead of the standard 36-byte STUN overhead with a 4-byte prefix instead of the standard 36-byte STUN overhead
(see Section 3.5 of <xref target="RFC8656"/>). <xref target="RFC7983"/> allo cates the values from (see <xref target="RFC8656" sectionFormat="of" section="3.5"/>). <xref targe t="RFC7983" format="default"/> allocates the values from
64 to 79 in order to allow TURN channels to be demultiplexed when the 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 TURN client does the channel binding request in combination with the
demultiplexing scheme described in <xref target="RFC7983"/>.</t> demultiplexing scheme described in <xref target="RFC7983" format="default"/>.
</t>
<t> <t>
In the absence of QUIC bit greasing, the first octet of a QUIC packet 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 (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 64 to 127, thereby overlapping with the allocated range for TURN
channels of 64 to 79. However, in practice this overlap does not channels of 64 to 79. However, in practice this overlap does not
represent a problem. TURN channel packets will only be received from represent a problem. TURN channel packets will only be received from
a TURN server to which TURN allocation and channel-binding requests a TURN server to which TURN allocation and channel-binding requests
have been sent. Therefore, a TURN client receiving packets from the have been sent. Therefore, a TURN client receiving packets from the
source IP address and port of a TURN server only needs to source IP address and port of a TURN server only needs to
disambiguate STUN (i.e. regular TURN) packets from TURN channel disambiguate STUN (i.e., regular TURN) packets from TURN channel
packets; (S)RTP, (S)RTCP, ZRTP, DTLS or QUIC packets will not be sent 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 from a source IP address and port that had previously responded to
TURN allocation or channel-binding requests.</t> TURN allocation or channel-binding requests.</t>
<t>
<t> As a result, if the source IP address and port of a packet do not
As a result, if the source IP address and port of a packet does not
match that of a responding TURN server, a packet with a first octet match that of a responding TURN server, a packet with a first octet
of 64 to 127 can be unambiguously demultiplexed as QUIC.</t> of 64 to 127 can be unambiguously demultiplexed as QUIC.</t>
</section>
</section> <section anchor="sect-3" numbered="true" toc="default">
<name>Updates to RFC 7983</name>
<section title="Updates to RFC 7983" anchor="sect-3"><t> <t>
This document updates the text in Section 7 of <xref target="RFC7983"/> (whic This document updates the text in <xref target="RFC7983" sectionFormat="of" s
h in ection="7"/> (which in
turn updates <xref target="RFC5764"/>) as follows:</t> turn updates <xref target="RFC5764" format="default"/>) as follows:</t>
<t>
<t>
OLD TEXT</t> OLD TEXT</t>
<blockquote>
<t> <t>
The process for demultiplexing a packet is as follows. The receiver 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 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 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 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. 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 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), 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 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 multiplexed over the same destination port). If the value does not
match any known range, then the packet MUST be dropped and an alert match any known range, then the packet <bcp14>MUST</bcp14> be dropped
MAY be logged. This process is summarized in Figure 3.</t> and an alert <bcp14>MAY</bcp14> be logged. This process is summarized
in Figure 3.</t>
<figure title="The DTLS-SRTP receiver's packet demultiplexing algorithm." <artwork name="" type="" align="left" alt=""><![CDATA[
anchor="fig-1"><artwork><![CDATA[
+----------------+ +----------------+
| [0..3] -+--> forward to STUN | [0..3] -+--> forward to STUN
| | | |
| [16..19] -+--> forward to ZRTP | [16..19] -+--> forward to ZRTP
| | | |
packet --> | [20..63] -+--> forward to DTLS packet --> | [20..63] -+--> forward to DTLS
| | | |
| [64..79] -+--> forward to TURN Channel | [64..79] -+--> forward to TURN Channel
| | | |
| [128..191] -+--> forward to RTP/RTCP | [128..191] -+--> forward to RTP/RTCP
+----------------+ +----------------+
]]></artwork>
</figure>
<t>END OLD TEXT</t> Figure 3: The DTLS-SRTP receiver's packet demultiplexing algorithm.
<t>NEW TEXT </t>
<t> ]]></artwork>
</blockquote>
<t>END OLD TEXT</t>
<t>NEW TEXT </t>
<blockquote>
<t>
The process for demultiplexing a packet is as follows. The receiver 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 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 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 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 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 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 (or RTCP, if both RTCP and RTP are being multiplexed over the same
destination port). If the value is between 80 and 127 (inclusive) destination port). If the value is between 80 and 127 (inclusive)
or between 192 and 255 (inclusive) then the packet is QUIC. If the 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 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 IP address and port of a responding TURN server, then the packet
is TURN channel; if the source IP address and port is not that of is TURN channel; if the source IP address and port are not that of
a responding TURN server, then the packet is QUIC.</t> a responding TURN server, then the packet is QUIC.</t>
<t>
<t> If the value does not match any known range, then the packet <bcp14>MUST</bcp
If the value does not match any known range, then the packet MUST 14>
be dropped and an alert MAY be logged. This process is summarized be dropped and an alert <bcp14>MAY</bcp14> be logged. This process is summari
zed
in Figure 3.</t> in Figure 3.</t>
<artwork name="" type="" align="left" alt=""><![CDATA[
<figure title="The receiver's packet demultiplexing algorithm." anchor="f
ig-2"><artwork><![CDATA[
+----------------+ +----------------+
| [0..3] -+--> forward to STUN | [0..3] -+--> forward to STUN
| | | |
| [4..15] -+--> DROP | [4..15] -+--> DROP
| | | |
| [16..19] -+--> forward to ZRTP | [16..19] -+--> forward to ZRTP
| | | |
packet --> | [20..63] -+--> forward to DTLS packet --> | [20..63] -+--> forward to DTLS
| | | |
| [64..79] -+--> forward to TURN Channel | [64..79] -+--> forward to TURN Channel
| | (if from TURN server), else QUIC | | (if from TURN server), else QUIC
| [80..127] -+--> forward to QUIC | [80..127] -+--> forward to QUIC
| | | |
| [128..191] -+--> forward to RTP/RTCP | [128..191] -+--> forward to RTP/RTCP
| | | |
| [192..255] -+--> forward to QUIC | [192..255] -+--> forward to QUIC
+----------------+ +----------------+
]]></artwork>
</figure>
<t>Note: Endpoints that wish to demultiplex QUIC MUST NOT send the Figure 3: The receiver's packet demultiplexing algorithm.
grease_quic_bit transport parameter, described in [RFC9287].</t> ]]></artwork>
<t>Note: Endpoints that wish to demultiplex QUIC <bcp14>MUST NOT</bcp14> s
<t>END NEW TEXT</t> end the
grease_quic_bit transport parameter, as described in <xref target="RFC9287"/>
</section> .</t>
</blockquote>
<section title="Security Considerations" anchor="sect-4"><t> <t>END NEW TEXT</t>
</section>
<section anchor="sect-4" numbered="true" toc="default">
<name>Security Considerations</name>
<t>
The solution discussed in this document could potentially introduce The solution discussed in this document could potentially introduce
some additional security issues beyond those described in <xref target="RFC79 83"/>. some additional security issues beyond those described in <xref target="RFC79 83" format="default"/>.
These additional concerns are described below.</t> These additional concerns are described below.</t>
<t>
<t>
In order to support multiplexing of QUIC, this document adds logic to In order to support multiplexing of QUIC, this document adds logic to
the scheme defined in <xref target="RFC7983"/>. If mis-implemented, the logic the scheme defined in <xref target="RFC7983" format="default"/>. If misimplem
could ented, the logic could
potentially mis-classify packets, exposing protocol handlers to potentially misclassify packets, exposing protocol handlers to
unexpected input.</t> unexpected input.</t>
<t>
<t>
When QUIC is used solely for data exchange, the TLS-within-QUIC When QUIC is used solely for data exchange, the TLS-within-QUIC
exchange <xref target="RFC9001"/> derives keys used solely to protect QUIC da ta exchange <xref target="RFC9001" format="default"/> derives keys used solely t o protect QUIC data
packets. If properly implemented, this should not affect the packets. If properly implemented, this should not affect the
transport of SRTP nor the derivation of SRTP keys via DTLS-SRTP. transport of SRTP or the derivation of SRTP keys via DTLS-SRTP.
However, if a future specification were to define use of the TLS- However, if a future specification were to define use of the TLS-
within-QUIC exchange to derive SRTP keys, both transport and SRTP key within-QUIC exchange to derive SRTP keys, both transport and SRTP key
derivation could be adversely impacted by a vulnerability in the QUIC derivation could be adversely impacted by a vulnerability in the QUIC
implementation.</t> implementation.</t>
</section>
<section anchor="sect-5" numbered="true" toc="default">
<name>IANA Considerations</name>
<t>
In the "TLS ContentType" registry, IANA replaced references to <xref target="
RFC7983"/> with references to this document.</t>
</section>
</middle>
<back>
</section> <displayreference target="I-D.ietf-avtcore-rtp-over-quic" to="RTP-OVER-QUIC"/>
<section title="IANA Considerations" anchor="sect-5"><t> <references>
In the TLS ContentType registry, IANA will replace references to RFC <name>References</name>
7983 with references to this document.</t> <references>
<name>Normative References</name>
<xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.2
119.xml"/>
<xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.3
550.xml"/>
<xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.3
711.xml"/>
<xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.5
764.xml"/>
<xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.7
983.xml"/>
<xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.8
174.xml"/>
<xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.8
489.xml"/>
<xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.8
656.xml"/>
<xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.9
000.xml"/>
<xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.9
001.xml"/>
<xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.9
147.xml"/>
<xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.9
287.xml"/>
</references>
<references>
<name>Informative References</name>
</section> <!-- [I-D.ietf-avtcore-rtp-over-quic] IESG state I-D Exists -->
<xi:include href="https://bib.ietf.org/public/rfc/bibxml3/reference.I-D.
ietf-avtcore-rtp-over-quic.xml"/>
</middle> <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.9369.xml"
/>
<xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.6
189.xml"/>
<back> <reference anchor="P2P-QUIC" target="https://www.w3.org/p2p-webtransport
<references title="Normative References"> /">
&RFC2119; <front>
&RFC3550; <title>QUIC API For Peer-to-Peer Connections</title>
&RFC3711; <author initials="P." surname="Thatcher" fullname="P. Thatcher">
&RFC5764;
&RFC7983;
&RFC8174;
&RFC8489;
&RFC8656;
&RFC9000;
&RFC9001;
&RFC9147;
&RFC9287;
</references>
<references title="Informative References">
&I-D.ietf-avtcore-rtp-over-quic;
&I-D.ietf-quic-v2;
&RFC6189;
<reference anchor="P2P-QUIC" target="https://github.com/w3c/p2p-webtransp
ort"><front>
<title>QUIC API For Peer-to-Peer Connections</title>
<author initials="P." surname="Thatcher" fullname="P. Thatcher">
</author> </author>
<author initials="B." surname="Aboba" fullname="B. Aboba">
<author initials="B." surname="Aboba" fullname="B. Aboba">
</author> </author>
<author initials="R." surname="Raymond" fullname="R. Raymond">
<author initials="R." surname="Raymond" fullname="R. Raymond">
</author> </author>
<date day="20" month="May" year="2023" />
</front>
<refcontent>W3C Community Group Draft Report</refcontent>
<refcontent>commit 50d79c0</refcontent>
</reference>
<date month="23" year="May 2021"/> <reference anchor="P2P-QUIC-TRIAL" target="https://developer.chrome.com/
</front> blog/rtcquictransport-api/">
<front>
<seriesInfo name="W3C" value="ORTC Community Group Draft (work in progres <title>RTCQuicTransport Coming to an Origin Trial Near You (Chrome 7
s)"/> 3)</title>
</reference> <author initials="S." surname="Hampson" fullname="S. Hampson">
<reference anchor="P2P-QUIC-TRIAL" target="https://developers.google.com/
web/updates/2019/01/rtcquictransport-api"><front>
<title>RTCQuicTransport Coming to an Origin Trial Near You (Chrome 73)</t
itle>
<author initials="S." surname="Hampson" fullname="S. Hampson">
</author> </author>
<date month="January" year="2019"/>
<date month="January" year="2019"/> </front>
</front> </reference>
</references>
</reference> </references>
</references> <section numbered="false" anchor="acknowledgments" toc="default">
<section title="Acknowledgments" numbered="no" anchor="acknowledgments">< <name>Acknowledgments</name>
t> <t>
We would like to thank Martin Thomson, Roni Even, Jonathan Lennox and We would like to thank <contact fullname="Martin Thomson"/>, <contact fullnam
other participants in the IETF QUIC and AVTCORE working groups for e="Roni Even"/>, <contact fullname="Jonathan Lennox"/>, and
other participants in the IETF QUIC and AVTCORE Working Groups for
their discussion of the QUIC multiplexing issue, and their input their discussion of the QUIC multiplexing issue, and their input
relating to potential solutions.</t> relating to potential solutions.</t>
</section>
</section> </back>
</rfc>
</back>
</rfc>
 End of changes. 51 change blocks. 
252 lines changed or deleted 259 lines changed or added

This html diff was produced by rfcdiff 1.48.