draft-ietf-avtcore-rfc7983bis-07.txt   draft-ietf-avtcore-rfc7983bis-08.txt 
AVTCORE Working Group B. Aboba AVTCORE Working Group B. Aboba
INTERNET-DRAFT Microsoft Corporation INTERNET-DRAFT Microsoft Corporation
Updates: 7983, 5764 G. Salgueiro Updates: 7983, 5764 G. Salgueiro
Category: Standards Track Cisco Systems Category: Standards Track Cisco Systems
Expires: June 28, 2023 C. Perkins Expires: July 30, 2023 C. Perkins
University of Glasgow University of Glasgow
29 December 2022 28 January 2023
Multiplexing Scheme Updates for QUIC Multiplexing Scheme Updates for QUIC
draft-ietf-avtcore-rfc7983bis-07.txt draft-ietf-avtcore-rfc7983bis-08.txt
Abstract Abstract
This document defines how QUIC, Datagram Transport Layer Security RFC 7983 defines a scheme for a Real-time Transport Protocol (RTP)
(DTLS), Real-time Transport Protocol (RTP), RTP Control Protocol receiver to demultiplex Datagram Transport Layer Security (DTLS),
(RTCP), Session Traversal Utilities for NAT (STUN), Traversal Using Session Traversal Utilities for NAT (STUN), Secure Real-time
Relays around NAT (TURN), and ZRTP packets are multiplexed on a 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. single receiving socket.
This document updates RFC 7983 and RFC 5764.
Status of This Memo Status of This Memo
This Internet-Draft is submitted in full conformance with the This Internet-Draft is submitted in full conformance with the
provisions of BCP 78 and BCP 79. provisions of BCP 78 and BCP 79.
Internet-Drafts are working documents of the Internet Engineering Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF). Note that other groups may also distribute Task Force (IETF). Note that other groups may also distribute
working documents as Internet-Drafts. The list of current Internet- working documents as Internet-Drafts. The list of current Internet-
Drafts is at http://datatracker.ietf.org/drafts/current/. Drafts is at http://datatracker.ietf.org/drafts/current/.
Internet-Drafts are draft documents valid for a maximum of six months Internet-Drafts are draft documents valid for a maximum of six months
and may be updated, replaced, or obsoleted by other documents at any and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress." material or to cite them other than as "work in progress."
This Internet-Draft will expire on June 28, 2023. This Internet-Draft will expire on July 30, 2023.
Copyright Notice Copyright Notice
Copyright (c) 2022 IETF Trust and the persons identified as the Copyright (c) 2022 IETF Trust and the persons identified as the
document authors. All rights reserved. document authors. All rights reserved.
This document is subject to BCP 78 and the IETF Trust's Legal This document is subject to BCP 78 and the IETF Trust's Legal
Provisions Relating to IETF Documents Provisions Relating to IETF Documents
(http://trustee.ietf.org/license-info) in effect on the date of (http://trustee.ietf.org/license-info) in effect on the date of
publication of this document. Please review these documents publication of this document. Please review these documents
skipping to change at page 3, line 23 skipping to change at page 3, line 23
[RFC3711], ZRTP [RFC6189] and TURN Channel packets arriving on a [RFC3711], ZRTP [RFC6189] and TURN Channel packets arriving on a
single port. This document updates [RFC7983] and [RFC5764] to also single port. This document updates [RFC7983] and [RFC5764] to also
allow QUIC [RFC9000] to be multiplexed on the same port. allow QUIC [RFC9000] to be multiplexed on the same port.
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. Peer-to-peer QUIC in WebRTC scenarios, described in
[P2P-QUIC] [P2P-QUIC-TRIAL], transports audio and video over SRTP, [P2P-QUIC] [P2P-QUIC-TRIAL], transports audio and video over SRTP,
alongside QUIC, used for data exchange. For this use case, SRTP alongside QUIC, used for data exchange. For this use case, SRTP
[RFC3711] is keyed using DTLS-SRTP [RFC5764] and therefore SRTP/SRTCP [RFC3711] is keyed using DTLS-SRTP [RFC5764] and therefore SRTP/SRTCP
[RFC3550], STUN, TURN, DTLS and QUIC need to be multiplexed on the [RFC3550], STUN, TURN, DTLS and QUIC need to be multiplexed on the
same port. Were SRTP to be keyed using QUIC-SRTP, SRTP/SRTCP, STUN, same port. Were SRTP to be keyed using QUIC-SRTP (not yet specified),
TURN and QUIC would need to be multiplexed on the same port. Where SRTP/SRTCP, STUN, TURN and QUIC would need to be multiplexed on the
QUIC is used for peer-to-peer transport of data as well as RTP/RTCP same port. Where QUIC is used for peer-to-peer transport of data as well as RTP/RTCP
[I-D.ietf-avtcore-rtp-over-quic] STUN, TURN and QUIC need to be [I-D.ietf-avtcore-rtp-over-quic] STUN, TURN and QUIC need to be
multiplexed on the same port. multiplexed on the same port.
While the scheme described in this document is compatible with QUIC While the scheme described in this document is compatible with QUIC
version 2 [I-D.ietf-quic-v2], it is not compatible with QUIC bit version 2 [I-D.ietf-quic-v2], it is not compatible with QUIC bit
greasing [RFC9287]. As a result, endpoints that wish to use greasing [RFC9287]. As a result, endpoints that wish to use
multiplexing on their socket MUST NOT send the grease_quic_bit multiplexing on their socket MUST NOT send the grease_quic_bit
transport parameter. transport parameter.
1.1. Terminology 1.1. Terminology
skipping to change at page 6, line 27 skipping to change at page 6, line 27
is TURN channel; if the source IP address and port is not that of is TURN channel; if the source IP address and port is not that of
a responding TURN server, then the packet is QUIC. a responding TURN server, then the packet is QUIC.
If the value does not match any known range, then the packet MUST 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 be dropped and an alert MAY be logged. This process is summarized
in Figure 3. in Figure 3.
+----------------+ +----------------+
| [0..3] -+--> forward to STUN | [0..3] -+--> forward to STUN
| | | |
| [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
| | | |
skipping to change at page 7, line 8 skipping to change at page 7, line 8
Note: Endpoints that wish to demultiplex QUIC MUST NOT send the Note: Endpoints that wish to demultiplex QUIC MUST NOT send the
grease_quic_bit transport parameter, described in grease_quic_bit transport parameter, described in
[RFC9287]. [RFC9287].
END NEW TEXT END NEW TEXT
4. Security Considerations 4. Security Considerations
The solution discussed in this document could potentially introduce The solution discussed in this document could potentially introduce
some additional security considerations beyond those detailed in some additional security issues beyond those described in [RFC7983].
[RFC7983]. Due to the additional logic required, if mis-implemented, These additional concerns are described below.
heuristics have the potential to mis-classify packets.
When QUIC is used only for data exchange, the TLS-within-QUIC In order to support multiplexing of QUIC, this document adds logic to
exchange [RFC9001] derives keys used solely to protect the QUIC data the scheme defined in [RFC7983]. If mis-implemented, the logic could
potentially mis-classify packets, exposing protocol handlers to
unexpected input.
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 packets. If properly implemented, this should not affect the
transport of SRTP nor the derivation of SRTP keys via DTLS-SRTP. transport of SRTP nor the derivation of SRTP keys via DTLS-SRTP.
However, were the TLS-within-QUIC exchange to be used to derive SRTP However, if a future specification were to define use of the TLS-
keys, both transport and SRTP key derivation could be aversely within-QUIC exchange to derive SRTP keys, both transport and SRTP key
impacted by a vulnerability in the QUIC implementation. derivation could be aversely impacted by a vulnerability in the QUIC
implementation.
5. IANA Considerations 5. IANA Considerations
This document does not require actions by IANA. This document does not require actions by IANA.
6. References 6. References
6.1. Normative References 6.1. Normative References
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
skipping to change at page 9, line 30 skipping to change at page 9, line 34
other participants in the IETF QUIC and AVTCORE working groups for 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. relating to potential solutions.
Authors' Addresses Authors' Addresses
Bernard Aboba Bernard Aboba
Microsoft Corporation Microsoft Corporation
One Microsoft Way One Microsoft Way
Redmond, WA 98052 Redmond, WA 98052
USA United States of America
Email: bernard.aboba@gmail.com Email: bernard.aboba@gmail.com
Gonzalo Salgueiro Gonzalo Salgueiro
Cisco Systems Cisco Systems
7200-12 Kit Creek Road 7200-12 Kit Creek Road
Research Triangle Park, NC 27709 Research Triangle Park, NC 27709
United States of America United States of America
Email: gsalguei@cisco.com Email: gsalguei@cisco.com
 End of changes. 12 change blocks. 
22 lines changed or deleted 30 lines changed or added

This html diff was produced by rfcdiff 1.46. The latest version is available from http://tools.ietf.org/tools/rfcdiff/