idnits 2.17.1 draft-aboba-avtcore-quic-multiplexing-04.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- No issues found here. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year == The document doesn't use any RFC 2119 keywords, yet seems to have RFC 2119 boilerplate text. -- The document date (28 January 2020) is 1550 days in the past. Is this intentional? Checking references for intended status: Informational ---------------------------------------------------------------------------- == Outdated reference: A later version (-34) exists of draft-ietf-quic-tls-25 == Outdated reference: A later version (-34) exists of draft-ietf-quic-transport-25 -- Obsolete informational reference (is this intentional?): RFC 5245 (Obsoleted by RFC 8445, RFC 8839) -- Obsolete informational reference (is this intentional?): RFC 5389 (Obsoleted by RFC 8489) -- Obsolete informational reference (is this intentional?): RFC 5766 (Obsoleted by RFC 8656) -- Obsolete informational reference (is this intentional?): RFC 6347 (Obsoleted by RFC 9147) -- Obsolete informational reference (is this intentional?): RFC 7540 (Obsoleted by RFC 9113) Summary: 0 errors (**), 0 flaws (~~), 4 warnings (==), 6 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 AVTCORE Working Group B. Aboba 3 INTERNET-DRAFT Microsoft Corporation 4 Category: Informational P. Thatcher 5 Expires: July 28, 2020 Google 6 C. Perkins 7 University of Glasgow 8 28 January 2020 10 QUIC Multiplexing 11 draft-aboba-avtcore-quic-multiplexing-04.txt 13 Abstract 15 If QUIC is to be used for peer-to-peer data transport with NAT 16 traversal, then it is necessary to be able to demultiplex QUIC and 17 other protocols used in WebRTC on a single UDP port. This memo 18 discusses a proposed scheme for demultiplexing. 20 Status of This Memo 22 This Internet-Draft is submitted in full conformance with the 23 provisions of BCP 78 and BCP 79. 25 Internet-Drafts are working documents of the Internet Engineering 26 Task Force (IETF). Note that other groups may also distribute 27 working documents as Internet-Drafts. The list of current Internet- 28 Drafts is at http://datatracker.ietf.org/drafts/current/. 30 Internet-Drafts are draft documents valid for a maximum of six months 31 and may be updated, replaced, or obsoleted by other documents at any 32 time. It is inappropriate to use Internet-Drafts as reference 33 material or to cite them other than as "work in progress." 35 This Internet-Draft will expire on 28 July 2020. 37 Copyright Notice 39 Copyright (c) 2020 IETF Trust and the persons identified as the 40 document authors. All rights reserved. 42 This document is subject to BCP 78 and the IETF Trust's Legal 43 Provisions Relating to IETF Documents 44 (http://trustee.ietf.org/license-info) in effect on the date of 45 publication of this document. Please review these documents 46 carefully, as they describe your rights and restrictions with respect 47 to this document. Code Components extracted from this document must 48 include Simplified BSD License text as described in Section 4.e of 49 the Trust Legal Provisions and are provided without warranty as 50 described in the Simplified BSD License. 52 Table of Contents 54 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 2 55 1.1. Terminology . . . . . . . . . . . . . . . . . . . . . . . 3 56 2. Solution . . . . . . . . . . . . . . . . . . . . . . . . . . . 3 57 3. Security Considerations . . . . . . . . . . . . . . . . . . . 4 58 4. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 5 59 5. References . . . . . . . . . . . . . . . . . . . . . . . . . . 5 60 5.1. Informative references . . . . . . . . . . . . . . . . . . 5 61 Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . . . 7 62 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 7 64 1. Introduction 66 QUIC [I-D.ietf-quic-transport] is a new network transport protocol. 67 While it is initially intended as a replacement for TCP in order to 68 better support HTTP/2 [RFC7540], with the introduction of datagram 69 support [I-D.pauly-quic-datagram] it will also support unreliable as 70 well as reliable transport. HTTP is an asymmetric client-server 71 protocol, but other uses of QUIC support peer-to-peer operation and 72 so will need effective NAT traversal using ICE [RFC5245], which which 73 makes use of STUN [RFC5389] and TURN [RFC5766] to discover NAT 74 bindings. Therefore for QUIC to be utilized for peer-to-peer data 75 transport, QUIC and STUN must be able to multiplex on the same port. 77 In a WebRTC scenario where RTP is used to transport audio and video 78 and QUIC is used for data exchange, SRTP [RFC3711] is keyed using 79 DTLS-SRTP [RFC5764] and therefore SRTP/SRTCP [RFC3550], STUN, TURN, 80 DTLS [RFC6347] and QUIC will need to be multiplexed on the same port. 82 Within the W3C, a Javascript API for the use of QUIC for peer-to-peer 83 data exchange [WEBRTC-QUIC] is under development within the ORTC 84 Community Group, and an Origin Trial [WEBRTC-QUIC-TRIAL] implementing 85 an early version of this API shipped in the Chrome and Edge browsers. 86 Due to lack of demultiplexing support, the Origin Trial could only 87 support peer-to-peer use of QUIC over a standalone ICE transport, as 88 defined in [WEBRTC-ICE]. 90 As noted in [RFC7983] Figure 3, protocol demultiplexing currently 91 relies upon differentiation based on the first octet, as follows: 93 +----------------+ 94 | [0..3] -+--> forward to STUN 95 | | 96 | [16..19] -+--> forward to ZRTP 97 | | 98 packet --> | [20..63] -+--> forward to DTLS 99 | | 100 | [64..79] -+--> forward to TURN Channel 101 | | 102 | [128..191] -+--> forward to RTP/RTCP 103 +----------------+ 105 Figure 1: RFC 7983 packet demultiplexing algorithm. 107 As noted by Colin Perkins and Lars Eggert in [QUIC-Issue][QUIC-MULTI] 108 this created a potential conflict with the design of the QUIC headers 109 described in versions of [I-D.ietf-quic-transport] prior to -08. 111 1.1. Terminology 113 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 114 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 115 document are to be interpreted as described in [RFC2119]. 117 2. Solution 119 As of draft 18, the QUIC Long Header packet type field defined in [I- 120 D.ietf-quic-transport] Section 17.2 appears as follows: 122 +-+-+-+-+-+-+-+-+ 123 |1|1|T T|X|X|X|X| 124 +-+-+-+-+-+-+-+-+ 126 Where: 128 T = Long Packet Type (0x0 - 0x3) 129 X = Type-Specific Bits. 131 This potentially produces values of the first octet in the ranges 132 192-255. 134 The QUIC Short Header packet type field defined in [I-D.ietf-quic- 135 transport] Section 17.3 appears as follows: 137 +-+-+-+-+-+-+-+-+ 138 |0|1|S|R|R|K|P P| 139 +-+-+-+-+-+-+-+-+ 141 Where: 143 S = Spin Bit 144 R = Reserved bits 145 K = Key Phase bit 146 P = Packet Number Length. 148 This potentially produces values of the first octet in the ranges 149 64-127 (assuming that the reserved bits may not always be set to 150 zero). 152 As a result, the multiplexing scheme supported in -18 operates as 153 follows: 155 +----------------+ 156 | [0..3] -+--> forward to STUN 157 | | 158 | [16..19] -+--> forward to ZRTP 159 | | 160 packet --> | [20..63] -+--> forward to DTLS 161 | | 162 | [64..79] -+--> forward to TURN Channel 163 | [64..127] -+--> forward to QUIC (Short Header) 164 | | 165 | [128..191] -+--> forward to RTP/RTCP 166 | [192..255] +--> forward to QUIC (Long Header) 167 +----------------+ 169 Figure 3: Packet demultiplexing algorithm in Draft 18. 171 Note that while the above diagram has a potential conflict between 172 packets sent in TURN Channels and the QUIC short header, this 173 conflict is not considered serious for WebRTC where TURN Channels are 174 rarely used. 176 3. Security Considerations 178 The solution discussed in this document could potentially introduce 179 some additional security considerations beyond those detailed in 180 [RFC7983]. 182 Due to the additional logic required, if mis-implemented, heuristics 183 have the potential to mis-classify packets. 185 When QUIC is used for only for data exchange, the TLS-within-QUIC 186 exchange [I-D.ietf-quic-tls] derives keys used solely to protect the 187 QUIC data packets. If properly implemented, this should not affect 188 the transport of SRTP nor the derivation of SRTP keys via DTLS-SRTP, 189 but if badly implemented, both transport and key derivation could be 190 adversely impacted. 192 4. IANA Considerations 194 This document does not require actions by IANA. 196 5. References 198 5.1. Informative References 200 [I-D.ietf-quic-tls] 201 Thomson, M. and S. Turner, "Using Transport Layer Security 202 (TLS) to Secure QUIC", draft-ietf-quic-tls-25 (work in 203 progress), January 22, 2020. 205 [I-D.ietf-quic-transport] 206 Iyengar, J. and M. Thomson, "QUIC: A UDP-Based Multiplexed 207 and Secure Transport", draft-ietf-quic-transport-25 (work 208 in progress), January 22, 2020. 210 [I-D.pauly-quic-datagram] 211 Pauly, T., Kinnear, E. and D. Schinazi, "An Unreliable 212 Datagram Extension to QUIC", draft-pauly-quic-datagram-05 213 (work in progress), November 04, 2019. 215 [QUIC-Issue] Perkins, C., "QUIC header format/demultiplexing", 216 https://github.com/quicwg/base-drafts/issues/426, March, 217 2017. 219 [QUIC-MULTI] Perkins, C., "QUIC Multiplexing and Peer-to-Peer", 220 presentation to IETF AVTCORE WG at IETF 100, 221 , November 223 2017. 225 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 226 Requirement Levels", BCP 14, RFC 2119, DOI 227 10.17487/RFC2119, March 1997, . 230 [RFC3550] Schulzrinne, H., Casner, S., Frederick, R., and V. 231 Jacobson, "RTP: A Transport Protocol for Real-Time 232 Applications", STD 64, RFC 3550, DOI 10.17487/RFC3550, July 233 2003, . 235 [RFC3711] Baugher, M., McGrew, D., Naslund, M., Carrara, E., and K. 236 Norrman, "The Secure Real-time Transport Protocol (SRTP)", 237 RFC 3711, DOI 10.17487/RFC3711, March 2004, 238 . 240 [RFC5245] Rosenberg, J., "Interactive Connectivity Establishment 241 (ICE): A Protocol for Network Address Translator (NAT) 242 Traversal for Offer/Answer Protocols", RFC 5245, DOI 243 10.17487/RFC5245, April 2010, . 246 [RFC5389] Rosenberg, J., Mahy, R., Matthews, P., and D. Wing, 247 "Session Traversal Utilities for NAT (STUN)", RFC 5389, DOI 248 10.17487/RFC5389, October 2008, . 251 [RFC5764] McGrew, D. and E. Rescorla, "Datagram Transport Layer 252 Security (DTLS) Extension to Establish Keys for the Secure 253 Real-time Transport Protocol (SRTP)", RFC 5764, DOI 254 10.17487/RFC5764, May 2010, . 257 [RFC5766] Mahy, R., Matthews, P., and J. Rosenberg, "Traversal Using 258 Relays around NAT (TURN): Relay Extensions to Session 259 Traversal Utilities for NAT (STUN)", RFC 5766, DOI 260 10.17487/RFC5766, April 2010, . 263 [RFC6347] Rescorla, E. and N. Modadugu, "Datagram Transport Layer 264 Security Version 1.2", RFC 6347, DOI 10.17487/RFC6347, 265 January 2012, . 267 [RFC7540] Belshe, M., Peon, R., and M. Thomson, Ed., "Hypertext 268 Transfer Protocol Version 2 (HTTP/2)", RFC 7540, DOI 269 10.17487/RFC7540, May 2015, . 272 [RFC7983] Petit-Huguenin, M. and G. Salgueiro, "Multiplexing Scheme 273 Updates for Secure Real-time Transport Protocol (SRTP) 274 Extension for Datagram Transport Layer Security (DTLS)", 275 RFC 7983, DOI 10.17487/RFC7983, September 2016, 276 . 278 [WEBRTC-ICE] Thatcher, P. and B. Aboba, "ICE Transport Extensions for 279 WebRTC", W3C Editor's Draft (work in progress), January 280 2020, 282 [WEBRTC-QUIC] 283 Thatcher, P. and B. Aboba, "QUIC API For Peer-to-Peer 284 Connections", W3C Community Group Draft (work in progress), 285 January 2020, 287 [WEBRTC-QUIC-TRIAL] 288 Hampson, S., "RTCQuicTransport Coming to an Origin Trial 289 Near You (Chrome 73)", January 2019, 290 293 Acknowledgments 295 We would like to thank Martin Thomson, Roni Even and other 296 participants in the IETF QUIC and AVTCORE working groups for their 297 discussion of the QUIC multiplexing issue, and their input relating 298 to potential solutions. 300 Authors' Addresses 302 Bernard Aboba 303 Microsoft Corporation 304 One Microsoft Way 305 Redmond, WA 98052 306 USA 308 Email: bernard.aboba@gmail.com 310 Peter Thatcher 311 Google 312 747 6th St S 313 Kirkland, WA 98033 314 USA 316 Email: pthatcher@google.com 318 Colin Perkins 319 School of Computing Science 320 University of Glasgow 321 Glasgow G12 8QQ 322 United Kingdom 324 Email: csp@csperkins.org