Audio/Video Transport Core Maintenance P. Thatcher Internet-Draft Microsoft Intended status: Standards Track 10 July 2023 Expires: 11 January 2024 P2P QUIC draft-thatcher-p2p-quic-00 Abstract This document describes how to combine ICE and QUIC to do p2p QUIC. Status of This Memo This Internet-Draft is submitted in full conformance with the provisions of BCP 78 and BCP 79. Internet-Drafts are working documents of the Internet Engineering Task Force (IETF). Note that other groups may also distribute working documents as Internet-Drafts. The list of current Internet- Drafts is at https://datatracker.ietf.org/drafts/current/. Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as "work in progress." This Internet-Draft will expire on 11 January 2024. Copyright Notice Copyright (c) 2023 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. Thatcher Expires 11 January 2024 [Page 1] Internet-Draft P2P QUIC July 2023 Table of Contents 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 2. Terminology and Notation . . . . . . . . . . . . . . . . . . 2 3. ALPN . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2 4. (De)multiplexing ICE and QUIC . . . . . . . . . . . . . . . . 2 5. Signaling . . . . . . . . . . . . . . . . . . . . . . . . . . 3 6. Certificate verification . . . . . . . . . . . . . . . . . . 3 7. Grease bit . . . . . . . . . . . . . . . . . . . . . . . . . 3 8. Multipath . . . . . . . . . . . . . . . . . . . . . . . . . . 3 9. QUIC datagrams . . . . . . . . . . . . . . . . . . . . . . . 3 10. Congestion control . . . . . . . . . . . . . . . . . . . . . 3 11. QUIC Pings . . . . . . . . . . . . . . . . . . . . . . . . . 3 12. Network Migration . . . . . . . . . . . . . . . . . . . . . . 4 13. MultiplexingID . . . . . . . . . . . . . . . . . . . . . . . 4 14. SDP . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4 15. Security Considerations . . . . . . . . . . . . . . . . . . . 5 16. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 5 17. Normative References . . . . . . . . . . . . . . . . . . . . 5 Author's Address . . . . . . . . . . . . . . . . . . . . . . . . 6 1. Introduction ICE [RFC8445] is a protocol for establishing peer-to-peer (p2p) connections. It can be combined with client-server protocols such as DTLS [RFC9147] for p2p versions of those protocols. This document describes how to use ICE with QUIC [RFC9000] for p2p QUIC connections. 2. Terminology and Notation 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. 3. ALPN The QUIC ALPN MUST be "q2q". 4. (De)multiplexing ICE and QUIC QUIC packets MUST be sent using the ICE selected candidate pair. Thatcher Expires 11 January 2024 [Page 2] Internet-Draft P2P QUIC July 2023 ICE and QUIC packets are demultiplexed using the STUN magic cookie. If a packet contains a STUN magic cookied, it MUST treated as an ICE packet. If it does not contain a STUN magic cookie, it SHOULD be treated as a QUIC packet (but further demultiplexing between QUIC and other protocols is possible). 5. Signaling In addition to all signaling necessary for ICE (ICE parameters and candidates), the following information MUST be signaled or otherwise negotiated between the peers: - Which side will take on the active (client) or passive (server) role. - Certificate fingerprint(s) - Whether or not to enable the grease bit - Whether or not to the MuliplexingID is used 6. Certificate verification Peers MAY use self-signed certificates. Each peer MUST verify the certificate, meaning a QUIC implementation MUST support a server verifying a client certificate. 7. Grease bit Peers SHOULD enable and use the grease bit if only multiplexing ICE and QUIC. When multiplexing other protocols that conflict with the grease bit, peers SHOULD NOT use the grease bit. 8. Multipath QUIC multipath SHOULD NOT be used unless it is known that one of the peers is a server. 9. QUIC datagrams QUIC datagrams SHOULD be supported. 10. Congestion control A real-time congestion control algorithm SHOULD be used, which may require extensions to QUIC (such as additional timestamps in feedback messages) and additional signaling. 11. QUIC Pings ACKed QUIC PING frames MAY be treated the same as a succesful ICE check, such that a peer may choose to send QUIC PING frames instead of ICE checks once an ICE candidate pair has had at least one successful ICE check. Thatcher Expires 11 January 2024 [Page 3] Internet-Draft P2P QUIC July 2023 12. Network Migration Network migration SHOULD be done using ICE, not QUIC. But ICE migrates between candidate pairs, QUIC should change behavior (such as congestion control) as if it had done a network migration, but it SHOULD NOT change the connection ID due to ICE migration. 13. MultiplexingID Because it is often difficult to obtain an ICE connection, it is often advantageous to multiplex many uses over a single ICE connection. For example, one may wish to send control data, real- time audio and video, and real-time data altogether over the same ICE connection. If all of these uses are done using QUIC, there must be a way to distinguish multiple uses of QUIC within the same QUIC connection, both for streams and for datagrams. The MultiplexingID is an optional, variable-length integer at the beginning of every QUIC datagram and stream. If it is negotiated to be used, it MUST be included on every datagram and stream. If it is not negotiated to be used, it MUST NOT be included on any datagram or stream. The variable-length encoding is the same as used by QUIC, as defined in section 16. 14. SDP If SDP is used for signaling, the media type may be "audio", "video", or "application". The transport protocol MUST begin with "UDP/QUIC". The transport protocol suffix combined with the media format may be any values which describe the protocol used on top of QUIC, either defined by other specifications or by applications. The media format MAY be the value "generic". The ICE parameters and candidates are signaled as defined by ICE ("a=ice-ufrag", "a=ice-pwd", "a=ice- options", "a=candidate"). The QUIC role and fingerprints are signaled using the same attributes as DTLS ("a=setup", and "a=fingerprint"). QUIC options are negotiated the same as ICE options but with an "a=quic-options" field. The grease bit defaults to off unless a QUIC option of "grease" is included. The MultiplexingID is signaled using an "a=mid" line, and the value MUST be a base-10 integer. If any "a=mid" is specified in any QUIC m-section in a BUNDLE group, then all QUIC m-sections in the same BUNDLE group MUST have an "a=mid" specified. For example: Thatcher Expires 11 January 2024 [Page 4] Internet-Draft P2P QUIC July 2023 v=0 o=- 4962303333179871722 1 IN IP4 0.0.0.0 s=- t=0 0 a=ice-ufrag:7sFv a=ice-pwd:dOTZKZNVlO9RSGsEGM63JXT2 a=ice-options:trickle a=quic-options:grease a=fingerprint:sha-256 7B:8B:F0:65:5F:78:E2:51:3B:AC:6F:F3:3F:46:1B:35: DC:B8:5F:64:1A:24:C2:43:F0:A1:58:D0:A1:2C:19:08 a=setup:active a=group:BUNDLE 1 2 3 m=audio 9 UDP/QUIC/RTP/AVPF 99 a=mid:1 a=sendrecv a=rtpmap:99 OPUS/4800/2 m=video 9 UDP/QUIC/RTP/AVPF 100 a=mid:2 a=sendrecv a=rtpmap:100 VP8/90000 a=rtcp-fb:100 ccm fir m=application 9 UDP/QUIC generic a=mid:3 15. Security Considerations This document is subject to the security considerations of ICE and QUIC. 16. IANA Considerations The ALPN "q2q" should be registered. 17. Normative References [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, DOI 10.17487/RFC2119, March 1997, . [RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, May 2017, . Thatcher Expires 11 January 2024 [Page 5] Internet-Draft P2P QUIC July 2023 [RFC8445] Keranen, A., Holmberg, C., and J. Rosenberg, "Interactive Connectivity Establishment (ICE): A Protocol for Network Address Translator (NAT) Traversal", RFC 8445, DOI 10.17487/RFC8445, July 2018, . [RFC9000] Iyengar, J., Ed. and M. Thomson, Ed., "QUIC: A UDP-Based Multiplexed and Secure Transport", RFC 9000, DOI 10.17487/RFC9000, May 2021, . [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, . Author's Address Peter Thatcher Microsoft Email: pthatcher@microsoft.com Thatcher Expires 11 January 2024 [Page 6]