idnits 2.17.1 draft-aboba-avtcore-rfc7983bis-00.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 (Using the creation date from RFC5764, updated by this document, for RFC5378 checks: 2007-07-03) -- The document seems to lack a disclaimer for pre-RFC5378 work, but may have content which was first submitted before 10 November 2008. If you have contacted all the original authors and they are all willing to grant the BCP78 rights to the IETF Trust, then this is fine, and you can ignore this comment. If not, you may need to add the pre-RFC5378 disclaimer. (See the Legal Provisions document at https://trustee.ietf.org/license-info for more information.) -- The document date (5 March 2020) is 1511 days in the past. Is this intentional? Checking references for intended status: Proposed Standard ---------------------------------------------------------------------------- (See RFCs 3967 and 4897 for information about using normative references to lower-maturity documents in RFCs) == Unused Reference: 'I-D.ietf-quic-transport' is defined on line 225, but no explicit reference was found in the text == Outdated reference: A later version (-34) exists of draft-ietf-quic-tls-27 == Outdated reference: A later version (-34) exists of draft-ietf-quic-transport-27 ** Obsolete normative reference: RFC 5389 (Obsoleted by RFC 8489) ** Obsolete normative reference: RFC 5766 (Obsoleted by RFC 8656) -- Obsolete informational reference (is this intentional?): RFC 6347 (Obsoleted by RFC 9147) Summary: 2 errors (**), 0 flaws (~~), 4 warnings (==), 3 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 Updates: 7983, 5764 G. Salgueiro 5 Category: Standards Track Cisco Systems 6 Expires: September 5, 2020 C. Perkins 7 University of Glasgow 8 5 March 2020 10 Multiplexing Scheme Updates for QUIC 11 draft-aboba-avtcore-rfc7983bis-00.txt 13 Abstract 15 This document defines how QUIC, Datagram Transport Layer Security 16 (DTLS), Real-time Transport Protocol (RTP), RTP Control Protocol 17 (RTCP), Session Traversal Utilities for NAT (STUN), Traversal Using 18 Relays around NAT (TURN), and ZRTP packets are multiplexed on a 19 single receiving socket. 21 This document updates RFC 7983 and RFC 5764. 23 Status of This Memo 25 This Internet-Draft is submitted in full conformance with the 26 provisions of BCP 78 and BCP 79. 28 Internet-Drafts are working documents of the Internet Engineering 29 Task Force (IETF). Note that other groups may also distribute 30 working documents as Internet-Drafts. The list of current Internet- 31 Drafts is at http://datatracker.ietf.org/drafts/current/. 33 Internet-Drafts are draft documents valid for a maximum of six months 34 and may be updated, replaced, or obsoleted by other documents at any 35 time. It is inappropriate to use Internet-Drafts as reference 36 material or to cite them other than as "work in progress." 38 This Internet-Draft will expire on September 5, 2020. 40 Copyright Notice 42 Copyright (c) 2020 IETF Trust and the persons identified as the 43 document authors. All rights reserved. 45 This document is subject to BCP 78 and the IETF Trust's Legal 46 Provisions Relating to IETF Documents 47 (http://trustee.ietf.org/license-info) in effect on the date of 48 publication of this document. Please review these documents 49 carefully, as they describe your rights and restrictions with respect 50 to this document. Code Components extracted from this document must 51 include Simplified BSD License text as described in Section 4.e of 52 the Trust Legal Provisions and are provided without warranty as 53 described in the Simplified BSD License. 55 Table of Contents 57 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3 58 1.1. Terminology . . . . . . . . . . . . . . . . . . . . . . . 3 59 2. Multiplexing of TURN Channels . . . . . . . . . . . . . . . . 3 60 3. Updates to RFC 7983 . . . . . . . . . . . . . . . . . . . . . 4 61 4. Security Considerations . . . . . . . . . . . . . . . . . . . 5 62 5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 6 63 6. References . . . . . . . . . . . . . . . . . . . . . . . . . . 6 64 6.1. Normative References . . . . . . . . . . . . . . . . . . 6 65 6.2. Informative References . . . . . . . . . . . . . . . . . 7 66 Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . . 7 67 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 8 69 1. Introduction 71 "Multiplexing Scheme Updates for Secure Real-time Transport Protocol 72 (SRTP) Extension for Datagram Transport Layer Security (DTLS)" 73 [RFC7983] defines a scheme for a Real-time Transport Protocol (RTP) 74 [RFC3550] receiver to demultiplex DTLS [RFC6347], Session Traversal 75 Utilities for NAT (STUN) [RFC5389], Secure Real-time Transport 76 Protocol (SRTP) / Secure Real-time Transport Control Protocol (SRTCP) 77 [RFC3711], ZRTP [RFC6189] and TURN Channel packets arriving on a 78 single port. 80 This document updates [RFC7983] and [RFC5764] to also allow QUIC [I- 81 D.ietf-quic-transport] to be multiplexed on the same port. For peer- 82 to-peer operation in WebRTC scenarios as described in [WEBRTC- 83 QUIC][WEBRTC-QUIC-TRIAL], RTP is used to transport audio and video 84 and QUIC is used for data exchange, SRTP [RFC3711] is keyed using 85 DTLS-SRTP [RFC5764] and therefore SRTP/SRTCP [RFC3550], STUN, TURN, 86 DTLS [RFC6347] and QUIC need to be multiplexed on the same port. 88 Since new versions of QUIC are allowed to change aspects of the wire 89 image, there is no guarantee that future versions of QUIC beyond 90 version 1 will adhere to the multiplexing scheme described in this 91 document. 93 1.1. Terminology 95 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 96 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 97 document are to be interpreted as described in [RFC2119]. 99 2. Multiplexing of TURN Channels 101 TURN channels are an optimization where data packets are exchanged 102 with a 4-byte prefix instead of the standard 36-byte STUN overhead 103 (see Section 2.5 of [RFC5766]). [RFC7983] allocated the values from 104 64 to 79 in order to allow TURN channels to be demultiplexed when the 105 TURN Client does the channel binding request in combination with the 106 demultiplexing scheme described in [RFC7983]. 108 As noted in [I-D.aboba-avtcore-quic-multiplexing], the first octet of 109 a QUIC short header packet falls in the range 64 to 127, thereby 110 overlapping with the allocated range for TURN channels of 64 to 79. 112 The first octet of QUIC long header packets fall in the range 192 to 113 255. Since QUIC long header packets preceed QUIC short header 114 packets, if no packets with a first octet in the range of 192 to 255 115 have been received, a packet whose first octet is in the range of 64 116 to 79 can be demultplexed unambiguously as TURN Channel traffic. 118 Since WebRTC implementations supporting QUIC data exchange do not 119 utilize TURN Channels, once packets with a first octet in the range 120 of 192 to 255 have been received, a packet whose first octet is in 121 the range of 64 to 127 can be demultiplexed as QUIC traffic. 123 3. Updates to RFC 7983 125 This document updates the text in Section 7 of [RFC7983] (which in 126 turn updates [RFC5764]) as follows: 128 OLD TEXT 130 The process for demultiplexing a packet is as follows. The receiver 131 looks at the first byte of the packet. If the value of this byte is 132 in between 0 and 3 (inclusive), then the packet is STUN. If the 133 value is between 16 and 19 (inclusive), then the packet is ZRTP. If 134 the value is between 20 and 63 (inclusive), then the packet is DTLS. 135 If the value is between 64 and 79 (inclusive), then the packet is 136 TURN Channel. If the value is in between 128 and 191 (inclusive), 137 then the packet is RTP (or RTCP, if both RTCP and RTP are being 138 multiplexed over the same destination port). If the value does not 139 match any known range, then the packet MUST be dropped and an alert 140 MAY be logged. This process is summarized in Figure 3. 142 +----------------+ 143 | [0..3] -+--> forward to STUN 144 | | 145 | [16..19] -+--> forward to ZRTP 146 | | 147 packet --> | [20..63] -+--> forward to DTLS 148 | | 149 | [64..79] -+--> forward to TURN Channel 150 | | 151 | [128..191] -+--> forward to RTP/RTCP 152 +----------------+ 154 Figure 3: The DTLS-SRTP receiver's packet demultiplexing algorithm. 156 END OLD TEXT 158 NEW TEXT 160 The process for demultiplexing a packet is as follows. The receiver 161 looks at the first byte of the packet. If the value of this byte is 162 in between 0 and 3 (inclusive), then the packet is STUN. If the 163 value is between 16 and 19 (inclusive), then the packet is ZRTP. If 164 the value is between 20 and 63 (inclusive), then the packet is DTLS. 165 If the value is in between 128 and 191 (inclusive) then the packet is 166 RTP (or RTCP, if both RTCP and RTP are being multiplexed over the 167 same destination port). If the value is between 80 and 127 or between 168 192 and 255 (inclusive) then the packet is QUIC. If the value is 169 between 64 and 79 inclusive, then if a packet has been previously 170 forwarded that is in the range of 192 and 255, then the packet is 171 QUIC, otherwise it is TURN Channel. 173 If the value does not match any known range, then the packet MUST be 174 dropped and an alert MAY be logged. This process is summarized in 175 Figure 3. 177 +----------------+ 178 | [0..3] -+--> forward to STUN 179 | | 180 | [16..19] -+--> forward to ZRTP 181 | | 182 packet --> | [20..63] -+--> forward to DTLS 183 | | 184 | [64..79] -+--> forward to TURN Channel 185 | [64..127] -+--> forward to QUIC 186 | | (Short Header) 187 | [128..191] -+--> forward to RTP/RTCP 188 | | 189 | [192..255] -+--> forward to QUIC 190 +----------------+ (Long Header) 192 Figure 3: The receiver's packet demultiplexing algorithm. 194 END NEW TEXT 196 4. Security Considerations 198 The solution discussed in this document could potentially introduce 199 some additional security considerations beyond those detailed in 200 [RFC7983]. 202 Due to the additional logic required, if mis-implemented, heuristics 203 have the potential to mis-classify packets. 205 When QUIC is used for only for data exchange, the TLS-within-QUIC 206 exchange [I-D.ietf-quic-tls] derives keys used solely to protect the 207 QUIC data packets. If properly implemented, this should not affect 208 the transport of SRTP nor the derivation of SRTP keys via DTLS-SRTP, 209 but if badly implemented, both transport and key derivation could be 210 adversely impacted. 212 5. IANA Considerations 214 This document does not require actions by IANA. 216 6. References 218 6.1. Normative References 220 [I-D.ietf-quic-tls] 221 Thomson, M. and S. Turner, "Using Transport Layer Security 222 (TLS) to Secure QUIC", draft-ietf-quic-tls-27 (work in 223 progress), February 21, 2020. 225 [I-D.ietf-quic-transport] 226 Iyengar, J. and M. Thomson, "QUIC: A UDP-Based Multiplexed 227 and Secure Transport", draft-ietf-quic-transport-27 (work 228 in progress), February 21, 2020. 230 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 231 Requirement Levels", BCP 14, RFC 2119, DOI 232 10.17487/RFC2119, March 1997, . 235 [RFC3550] Schulzrinne, H., Casner, S., Frederick, R., and V. 236 Jacobson, "RTP: A Transport Protocol for Real-Time 237 Applications", STD 64, RFC 3550, DOI 10.17487/RFC3550, July 238 2003, . 240 [RFC3711] Baugher, M., McGrew, D., Naslund, M., Carrara, E., and K. 241 Norrman, "The Secure Real-time Transport Protocol (SRTP)", 242 RFC 3711, DOI 10.17487/RFC3711, March 2004, 243 . 245 [RFC5389] Rosenberg, J., Mahy, R., Matthews, P., and D. Wing, 246 "Session Traversal Utilities for NAT (STUN)", RFC 5389, DOI 247 10.17487/RFC5389, October 2008, . 250 [RFC5764] McGrew, D. and E. Rescorla, "Datagram Transport Layer 251 Security (DTLS) Extension to Establish Keys for the Secure 252 Real-time Transport Protocol (SRTP)", RFC 5764, DOI 253 10.17487/RFC5764, May 2010, . 256 [RFC5766] Mahy, R., Matthews, P., and J. Rosenberg, "Traversal Using 257 Relays around NAT (TURN): Relay Extensions to Session 258 Traversal Utilities for NAT (STUN)", RFC 5766, DOI 259 10.17487/RFC5766, April 2010, . 262 [RFC7983] Petit-Huguenin, M. and G. Salgueiro, "Multiplexing Scheme 263 Updates for Secure Real-time Transport Protocol (SRTP) 264 Extension for Datagram Transport Layer Security (DTLS)", 265 RFC 7983, DOI 10.17487/RFC7983, September 2016, 266 . 268 6.2. Informative References 270 [I-D.aboba-avtcore-quic-multiplexing] 271 Aboba, B., Thatcher, P. and C. Perkins, "QUIC 272 Multiplexing", draft-aboba-avtcore-quic-multiplexing-04 273 (work in progress), January 28, 2020. 275 [RFC6189] Zimmermann, P., Johnston, A., Ed., and J. Callas, "ZRTP: 276 Media Path Key Agreement for Unicast Secure RTP", RFC 6189, 277 DOI 10.17487/RFC6189, April 2011, . 280 [RFC6347] Rescorla, E. and N. Modadugu, "Datagram Transport Layer 281 Security Version 1.2", RFC 6347, DOI 10.17487/RFC6347, 282 January 2012, . 284 [WEBRTC-QUIC] 285 Thatcher, P. and B. Aboba, "QUIC API For Peer-to-Peer 286 Connections", W3C Community Group Draft (work in progress), 287 January 2020, 289 [WEBRTC-QUIC-TRIAL] 290 Hampson, S., "RTCQuicTransport Coming to an Origin Trial 291 Near You (Chrome 73)", January 2019, 292 295 Acknowledgments 297 We would like to thank Martin Thomson, Roni Even and other 298 participants in the IETF QUIC and AVTCORE working groups for their 299 discussion of the QUIC multiplexing issue, and their input relating 300 to potential solutions. 302 Authors' Addresses 304 Bernard Aboba 305 Microsoft Corporation 306 One Microsoft Way 307 Redmond, WA 98052 308 USA 310 Email: bernard.aboba@gmail.com 312 Gonzalo Salgueiro 313 Cisco Systems 314 7200-12 Kit Creek Road 315 Research Triangle Park, NC 27709 316 United States of America 318 Email: gsalguei@cisco.com 320 Colin Perkins 321 School of Computing Science 322 University of Glasgow 323 Glasgow G12 8QQ 324 United Kingdom 326 Email: csp@csperkins.org