idnits 2.17.00 (12 Aug 2021) /tmp/idnits41174/draft-pardue-quic-http-mcast-09.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 : ---------------------------------------------------------------------------- == There are 1 instance of lines with multicast IPv4 addresses in the document. If these are generic example addresses, they should be changed to use the 233.252.0.x range defined in RFC 5771 Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year == The document seems to lack the recommended RFC 2119 boilerplate, even if it appears to use RFC 2119 keywords -- however, there's a paragraph with a matching beginning. Boilerplate error? (The document does seem to have the reference to RFC 2119 which the ID-Checklist requires). -- The document date (13 August 2021) is 274 days in the past. Is this intentional? Checking references for intended status: Experimental ---------------------------------------------------------------------------- -- Obsolete informational reference (is this intentional?): RFC 4566 (Obsoleted by RFC 8866) Summary: 0 errors (**), 0 flaws (~~), 3 warnings (==), 2 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Network Working Group L. Pardue 3 Internet-Draft 4 Intended status: Experimental R. Bradbury 5 Expires: 14 February 2022 S. Hurst 6 BBC Research & Development 7 13 August 2021 9 Hypertext Transfer Protocol (HTTP) over multicast QUIC 10 draft-pardue-quic-http-mcast-09 12 Abstract 14 This document specifies a profile of the QUIC protocol and the HTTP/3 15 mapping that facilitates the transfer of HTTP resources over 16 multicast IP using the QUIC transport as its framing and 17 packetisation layer. Compatibility with the QUIC protocol's syntax 18 and semantics is maintained as far as practical and additional 19 features are specified where this is not possible. 21 Status of This Memo 23 This Internet-Draft is submitted in full conformance with the 24 provisions of BCP 78 and BCP 79. 26 Internet-Drafts are working documents of the Internet Engineering 27 Task Force (IETF). Note that other groups may also distribute 28 working documents as Internet-Drafts. The list of current Internet- 29 Drafts is at https://datatracker.ietf.org/drafts/current/. 31 Internet-Drafts are draft documents valid for a maximum of six months 32 and may be updated, replaced, or obsoleted by other documents at any 33 time. It is inappropriate to use Internet-Drafts as reference 34 material or to cite them other than as "work in progress." 36 This Internet-Draft will expire on 14 February 2022. 38 Copyright Notice 40 Copyright (c) 2021 IETF Trust and the persons identified as the 41 document authors. All rights reserved. 43 This document is subject to BCP 78 and the IETF Trust's Legal 44 Provisions Relating to IETF Documents (https://trustee.ietf.org/ 45 license-info) in effect on the date of publication of this document. 46 Please review these documents carefully, as they describe your rights 47 and restrictions with respect to this document. Code Components 48 extracted from this document must include Simplified BSD License text 49 as described in Section 4.e of the Trust Legal Provisions and are 50 provided without warranty as described in the Simplified BSD License. 52 Table of Contents 54 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 5 55 1.1. Notational Conventions . . . . . . . . . . . . . . . . . 6 56 1.2. Definitions . . . . . . . . . . . . . . . . . . . . . . . 6 57 2. Multicast QUIC Sessions . . . . . . . . . . . . . . . . . . . 7 58 2.1. Session States . . . . . . . . . . . . . . . . . . . . . 8 59 2.1.1. Session Establishment . . . . . . . . . . . . . . . . 9 60 2.1.2. Session Termination . . . . . . . . . . . . . . . . . 9 61 2.1.3. Session Migration . . . . . . . . . . . . . . . . . . 9 62 2.2. Session Parameters . . . . . . . . . . . . . . . . . . . 10 63 2.3. Session Identification . . . . . . . . . . . . . . . . . 10 64 2.4. Session Security . . . . . . . . . . . . . . . . . . . . 11 65 3. Session Advertisement . . . . . . . . . . . . . . . . . . . . 12 66 3.1. Security Context . . . . . . . . . . . . . . . . . . . . 12 67 3.1.1. Cipher Suite . . . . . . . . . . . . . . . . . . . . 13 68 3.1.2. Key Exchange . . . . . . . . . . . . . . . . . . . . 13 69 3.1.3. Initialization Vector . . . . . . . . . . . . . . . . 13 70 3.2. Session Identification . . . . . . . . . . . . . . . . . 13 71 3.3. Session Idle Timeout . . . . . . . . . . . . . . . . . . 14 72 3.4. Session Peak Flow Rate . . . . . . . . . . . . . . . . . 14 73 3.5. Resource Concurrency . . . . . . . . . . . . . . . . . . 15 74 3.6. Additional TransportParameter Considerations . . . . . . 16 75 3.7. Digest Algorithm . . . . . . . . . . . . . . . . . . . . 16 76 3.8. Signature Algorithm . . . . . . . . . . . . . . . . . . . 17 77 4. QUIC Profile . . . . . . . . . . . . . . . . . . . . . . . . 18 78 4.1. Packet Size . . . . . . . . . . . . . . . . . . . . . . . 19 79 4.2. Packet Format . . . . . . . . . . . . . . . . . . . . . . 19 80 4.2.1. Packet Numbers . . . . . . . . . . . . . . . . . . . 19 81 4.2.2. Spin Bit . . . . . . . . . . . . . . . . . . . . . . 19 82 4.3. Connection Identifier . . . . . . . . . . . . . . . . . . 20 83 4.4. Stream Identifier . . . . . . . . . . . . . . . . . . . . 20 84 4.5. Flow Control . . . . . . . . . . . . . . . . . . . . . . 20 85 4.6. Stream Termination . . . . . . . . . . . . . . . . . . . 20 86 4.7. Connection Shutdown . . . . . . . . . . . . . . . . . . . 21 87 4.8. Connection Migration . . . . . . . . . . . . . . . . . . 21 88 4.9. Explicit Congestion Notification . . . . . . . . . . . . 21 89 4.10. Session Keep-alive . . . . . . . . . . . . . . . . . . . 22 90 4.11. Loss Detection and Recovery . . . . . . . . . . . . . . . 22 91 4.12. Prohibited QUIC Frames and Packets . . . . . . . . . . . 22 92 5. HTTP/3 Profile . . . . . . . . . . . . . . . . . . . . . . . 23 93 5.1. HTTP Connection Settings . . . . . . . . . . . . . . . . 23 94 5.2. Server Push . . . . . . . . . . . . . . . . . . . . . . . 23 95 5.3. Metadata Compression . . . . . . . . . . . . . . . . . . 24 96 5.4. Session Tear-down . . . . . . . . . . . . . . . . . . . . 24 97 5.5. Effects of Packet Loss . . . . . . . . . . . . . . . . . 25 98 5.6. HTTP/3 Extension frames . . . . . . . . . . . . . . . . . 26 99 5.7. Prohibited HTTP/3 Frames . . . . . . . . . . . . . . . . 26 100 6. Application-Layer Security . . . . . . . . . . . . . . . . . 26 101 6.1. Content Integrity . . . . . . . . . . . . . . . . . . . . 26 102 6.2. Content Authenticity . . . . . . . . . . . . . . . . . . 27 103 6.3. Content Confidentiality . . . . . . . . . . . . . . . . . 28 104 7. Loss Recovery . . . . . . . . . . . . . . . . . . . . . . . . 28 105 7.1. Forward Error Correction . . . . . . . . . . . . . . . . 28 106 7.2. Unicast Repair . . . . . . . . . . . . . . . . . . . . . 29 107 8. Transmission of Partial Content . . . . . . . . . . . . . . . 29 108 9. Protocol Identifier . . . . . . . . . . . . . . . . . . . . . 30 109 9.1. Draft Version Identification . . . . . . . . . . . . . . 30 110 10. Discovery of Multicast QUIC Sessions . . . . . . . . . . . . 30 111 10.1. Source-specific Multicast Advertisement . . . . . . . . 31 112 10.2. Session Parameter Advertisement . . . . . . . . . . . . 32 113 10.2.1. Cipher Suite . . . . . . . . . . . . . . . . . . . . 32 114 10.2.2. Session Key . . . . . . . . . . . . . . . . . . . . 32 115 10.2.3. Session Cipher Initialization Vector . . . . . . . . 32 116 10.2.4. Session Identification . . . . . . . . . . . . . . . 33 117 10.2.5. Session Idle Timeout Period . . . . . . . . . . . . 33 118 10.2.6. Resource Concurrency . . . . . . . . . . . . . . . . 34 119 10.2.7. Session Peak Flow Rate . . . . . . . . . . . . . . . 34 120 10.2.8. Digest Algorithm . . . . . . . . . . . . . . . . . . 34 121 10.2.9. Signature Algorithm . . . . . . . . . . . . . . . . 35 122 10.2.10. Extensions . . . . . . . . . . . . . . . . . . . . . 35 123 11. Security Considerations . . . . . . . . . . . . . . . . . . . 36 124 11.1. Pervasive Monitoring . . . . . . . . . . . . . . . . . . 36 125 11.1.1. Large-scale Data Gathering and Correlation . . . . . 36 126 11.1.2. Changing Content . . . . . . . . . . . . . . . . . . 37 127 11.2. Protection of Discovery Mechanism . . . . . . . . . . . 37 128 11.3. Spoofing . . . . . . . . . . . . . . . . . . . . . . . . 37 129 11.3.1. Sender Spoofing . . . . . . . . . . . . . . . . . . 37 130 11.4. Replay Attacks . . . . . . . . . . . . . . . . . . . . . 38 131 11.5. Message Deletion . . . . . . . . . . . . . . . . . . . . 38 132 11.6. Denial of Service . . . . . . . . . . . . . . . . . . . 38 133 11.6.1. Unprotected Frames and Packets . . . . . . . . . . . 38 134 11.6.2. Network Performance Degradation . . . . . . . . . . 39 135 11.6.3. Unicast Repair Stampeding Herd . . . . . . . . . . . 39 136 11.7. Receiver Resource Usage . . . . . . . . . . . . . . . . 39 137 11.8. Unicast Repair Information Leakage . . . . . . . . . . . 39 138 12. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 40 139 12.1. Registration of Protocol Identification String . . . . . 40 140 12.2. Registration of Alt-Svc parameters . . . . . . . . . . . 40 141 12.2.1. Source Address . . . . . . . . . . . . . . . . . . . 40 142 12.2.2. Cipher Suite . . . . . . . . . . . . . . . . . . . . 40 143 12.2.3. Key . . . . . . . . . . . . . . . . . . . . . . . . 41 144 12.2.4. Initialization Vector . . . . . . . . . . . . . . . 41 145 12.2.5. Session Identifier . . . . . . . . . . . . . . . . . 41 146 12.2.6. Session Idle Timeout . . . . . . . . . . . . . . . . 41 147 12.2.7. Maximum Concurrent Resources . . . . . . . . . . . . 41 148 12.2.8. Peak Flow Rate . . . . . . . . . . . . . . . . . . . 41 149 12.2.9. Digest Algorithm . . . . . . . . . . . . . . . . . . 41 150 12.2.10. Signature Algorithm . . . . . . . . . . . . . . . . 41 151 12.2.11. Extension . . . . . . . . . . . . . . . . . . . . . 42 152 13. References . . . . . . . . . . . . . . . . . . . . . . . . . 42 153 13.1. Normative References . . . . . . . . . . . . . . . . . . 42 154 13.2. Informative References . . . . . . . . . . . . . . . . . 44 155 Appendix A. Acknowledgements . . . . . . . . . . . . . . . . . . 46 156 Appendix B. Examples . . . . . . . . . . . . . . . . . . . . . . 46 157 B.1. Session Advertisement . . . . . . . . . . . . . . . . . . 46 158 B.1.1. Source-specific Multicast QUIC Session . . . . . . . 46 159 B.1.2. Source-specific Multicast QUIC Session with Transport 160 Encryption using a Symmetric Key . . . . . . . . . . 47 161 B.1.3. Source-specific Multicast QUIC Session with Transport 162 Encryption, Content Integrity and Authenticity . . . 47 163 B.2. Resource Transfer . . . . . . . . . . . . . . . . . . . . 48 164 B.2.1. Transfer without Content Integrity or Authenticity . 48 165 B.2.2. Transfer of Partial Content without Content Integrity 166 or Authenticity . . . . . . . . . . . . . . . . . . . 48 167 B.2.3. Transfer with Content Integrity and without 168 Authenticity . . . . . . . . . . . . . . . . . . . . 49 169 B.2.4. Partial Transfer with Content Integrity and without 170 Authenticity . . . . . . . . . . . . . . . . . . . . 49 171 B.2.5. Transfer with Content Integrity and Authenticity . . 50 172 B.2.6. Partial Transfer with Content Integrity and 173 Authenticity . . . . . . . . . . . . . . . . . . . . 51 174 Appendix C. Summary of differences from unicast QUIC and 175 HTTP/3 . . . . . . . . . . . . . . . . . . . . . . . . . 52 176 Appendix D. Changelog . . . . . . . . . . . . . . . . . . . . . 63 177 D.1. Since draft-pardue-quic-http-mcast-08 . . . . . . . . . . 63 178 D.2. Since draft-pardue-quic-http-mcast-07 . . . . . . . . . . 64 179 D.3. Since draft-pardue-quic-http-mcast-06 . . . . . . . . . . 64 180 D.4. Since draft-pardue-quic-http-mcast-05 . . . . . . . . . . 64 181 D.5. Since draft-pardue-quic-http-mcast-04 . . . . . . . . . . 65 182 D.6. Since draft-pardue-quic-http-mcast-03 . . . . . . . . . . 66 183 D.7. Since draft-pardue-quic-http-mcast-02 . . . . . . . . . . 66 184 D.8. Since draft-pardue-quic-http-mcast-01 . . . . . . . . . . 66 185 D.9. Since draft-pardue-quic-http-mcast-00 . . . . . . . . . . 67 186 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 67 188 1. Introduction 190 The means to bulk transfer resources over multicast IP [RFC1112] 191 using HTTP semantics presents an opportunity to more efficiently 192 deliver services at scale, while leveraging the wealth of existing 193 HTTP-related standards, tools and applications. Audio-visual 194 segmented media, in particular, would benefit from this mode of 195 transmission. 197 The carriage of HTTP over multicast IP may be satisfied using 198 existing technologies, for example the Real-time Transport Protocol 199 (RTP) [RFC3550], File Delivery over Unidirectional Transport (FLUTE) 200 [RFC6726], and NACK-Oriented Reliable Multicast (NORM) [RFC5740]. 201 However, such protocols typically require the translation or 202 encapsulation of HTTP. This introduces concerns for providers of 203 services, such as defining the translation, additional workload, 204 complication of workflows, manageability issues, versioning issues, 205 and so on. 207 In contrast, this document describes a simpler and more direct 208 expression of HTTP semantics over multicast IP. HTTP over multicast 209 QUIC is a profile of the QUIC protocol [RFC9000] (Section 4) and the 210 HTTP/3 mapping [QUIC-HTTP] (Section 5). This includes the 211 repurposing of certain QUIC packet fields and changes to some 212 protocol procedures (e.g. prohibition of the usage of certain frame 213 types) which, in turn, change the behavioural expectations of 214 endpoints. However, the profile purposely limits the scope of change 215 in order to preserve maximum syntactic and semantic compatibility 216 with conventional QUIC. For the reader's convenience, the 217 differences between this specification and conventional QUIC are 218 summarised in Appendix C. 220 This profile prohibits the transmission of QUIC packets from receiver 221 to sender via multicast IP. The use of side-channel or out-of-band 222 feedback mechanisms is not prohibited by this specification, but is 223 out of scope and these are not considered further by the present 224 document. 226 Experience indicates that a generally available multicast deployment 227 is difficult to achieve on the Internet notwithstanding the 228 improvements that IPv6 [RFC8200] makes in this area. There is 229 evidence that discretely referenced multicast "islands" can more 230 pragmatically be deployed. Discovery of such islands by receivers, 231 as they become available, is typically difficult, however. To 232 address the problem, this document describes an HTTP-based discovery 233 mechanism that uses HTTP Alternative Services [RFC7838] to advertise 234 the existence of multicast QUIC sessions (Section 3). This provides 235 the means for multicast-capable endpoints to learn about and make use 236 of them in an opportunistic and user-imperceptible manner. This 237 mechanism results in a common HTTP application layer for both the 238 discovery and delivery of services across unicast and multicast 239 networks. This provides support for users and devices accessing 240 services over a heterogeneous network. This is a departure from 241 conventional multicast discovery technologies such as SDP [RFC8866] 242 and SAP [RFC2974]. 244 The discovery mechanism also addresses some of the issues related to 245 using QUIC over a unidirectional network association by replacing 246 connection establishment aspects that depend on a bidirectional 247 transport. 249 The present document includes a number of optional features. It is 250 anticipated that further specifications will define interoperability 251 profiles suited to particular application domains. 253 1.1. Notational Conventions 255 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 256 "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and 257 "OPTIONAL" in this document are to be interpreted as described in BCP 258 14 [RFC2119] [RFC8174] when, and only when, they appear in all 259 captials, as shown here. 261 This document uses the Augmented BNF defined in [RFC5234] and updated 262 by [RFC7405] along with the "#rule" extension defined in Section 7 of 263 [RFC7230]. The rules below are defined in [RFC5234], [RFC7230], and 264 [RFC7234]: 266 * quoted-string = 268 * token = 270 * uri-host = 272 1.2. Definitions 274 Definitions of terms that are used in this document: 276 * endpoint: A host capable of being a participant in a multicast 277 QUIC session. 279 * multicast QUIC session: A logical unidirectional flow of metadata 280 and data over multicast IP, framed according to this 281 specification. The lifetime of a session is independent of any 282 endpoint. 284 * participant: A sender or receiver that is taking part in a 285 multicast QUIC session. 287 * sender: A participant sending multicast traffic according to this 288 specification. 290 * receiver: A participant receiving multicast traffic according to 291 this specification. 293 * session: See multicast QUIC session. 295 * session ID: The identifier for a multicast QUIC session. 297 * session parameter: Characteristic of a multicast QUIC session. 299 2. Multicast QUIC Sessions 301 A QUIC connection [RFC9000] carried over bidirectional unicast is 302 defined as a conversation between two QUIC endpoints that multiplexes 303 several logical streams within a single encryption context. This is 304 a one-to-one relationship. Furthermore, QUIC connections achieve 305 decoupling from the underlying network (IP and port) by means of a 306 set of Connection IDs, with each endpoint generating these IDs and 307 using them to identify the direction of flow. Use of a consistent 308 connection identifier allows QUIC connections to survive changes to 309 the network connectivity. The establishment of a QUIC connection 310 relies upon an up-front, in-band exchange (and possible negotiation) 311 of cryptographic and transport parameters (conveyed in QUIC handshake 312 messages). 314 The mapping of HTTP semantics over the QUIC transport protocol 315 [QUIC-HTTP] facilitates the transfer of hypermedia over QUIC 316 connections. The establishment of a HTTP/3 connection relies upon 317 all the requirements stipulated for the transport, as well as 318 communication of HTTP-specific settings (conveyed in HTTP/3 319 "SETTINGS" frames). Such parameters may be required or optional and 320 may be used by either endpoint to control the characteristics of 321 connection usage. 323 This concept of a connection does not suit the carriage of HTTP/3 324 over unidirectional network associations such as multicast IP. In 325 fact, there is no requirement for either endpoint (multicast sender 326 or receiver) to be in existence in order for the other to start or 327 join this one-sided conversation. The term "connection" is 328 misleading in this context; therefore we introduce an alternative 329 term "multicast QUIC session" or simply "session", which is defined 330 as the logical entity describing the characteristics of the 331 anticipated unidirectional flow of metadata and data. Such 332 characteristics are expressed as "session parameters", described in 333 Section 2.2. Advertisement of multicast QUIC sessions, specified in 334 Section 3, allows for the senders and receivers to discover a session 335 and to form multicast IP network associations that permit traffic 336 flow. 338 2.1. Session States 340 The lifecycle of a multicast QUIC session is decoupled from the 341 lifecycle of any particular endpoint. Multicast receivers or senders 342 that take part in a session are called participants. The state of a 343 session is influenced by the actions of participants. The loose 344 coupling of participants means that they are unlikely to have a 345 consistent shared view of the current state of a session. There is 346 no requirement for a participant to know the session state and the 347 present document does not define a method to explicitly determine it. 348 The definitions of session states provided below are intended to 349 assist higher-level operational treatment of sessions: 351 * Quiescent: the session has no participants and is ready to accept 352 them. 354 * Half-established: the session has a participant. 356 * Fully-established: the session has a sender and at least one 357 receiver participant. 359 * Finished: the session has ended, and there are no participants. 361 Permitted states transitions are shown in Figure 1 below. 363 The transmission of QUIC packets is expected to occur only during the 364 Half-Established and Fully-Established states. 366 +-----------+ +------------------+ +-------------------+ 367 | |-------->| |------->| | 368 | Quiescent | | Half-Established | | Fully-Established | 369 | |<--------| |<-------| | 370 +-----------+ +------------------+ +-------------------+ 371 | | 372 | v 373 | +----------+ 374 | | | 375 +------------------>| Finished | 376 | | 377 +----------+ 379 Figure 1: Multicast QUIC session states 381 2.1.1. Session Establishment 383 A session begins in the Quiescent state. A typical session 384 establishment sequence would see the transition from Quiescent to 385 Half-Established when a sender joins the session. The transition 386 from Half-Established to Fully-Established occurs when at least one 387 receiver joins the session. 389 It is equally valid for a receiver to join a session in the Quiescent 390 state, triggering the transition to Half-Established. In this case, 391 the transition to Fully-Established takes place only when a sender 392 joins the session. 394 2.1.2. Session Termination 396 Participants MAY leave a session at any time. A session enters the 397 Finished state when all participants have left it. Senders MAY 398 signal their intent to leave using explicit session tear-down 399 (Section 5.4). Receivers can detect that a sender has left via idle 400 timeout (Section 3.3) and take that as a signal to leave, or 401 receivers may leave as part of session migration (described in the 402 next section). 404 In a typical case, a session that is in the Fully-Established state 405 would be closed in two stages. In the first stage the sender sends 406 explicit shutdown messages to the multicast group and subsequently 407 stops transmitting packets. This causes the session to transition 408 from Fully-Established to Half-Established. In the second stage, 409 receivers that have received explicit shutdown messages leave the 410 multicast group. Once all receivers have left the session it 411 transitions from Half-Established to Finished. 413 The transition from Quiescent to Finished could also occur in 414 response to out-of-band actions, for example the availability of a 415 session being withdrawn without any participants having made use of 416 it. 418 2.1.3. Session Migration 420 Endpoints MAY migrate between multicast QUIC sessions (for example, 421 to make use of alternate session parameters that are preferred). 422 Session migration requires participants to leave the current session 423 and join the new session. These actions affect the state of the 424 respective sessions as explained above. 426 The discovery of multicast QUIC sessions is described in Section 3. 428 2.2. Session Parameters 430 The characteristics of multicast QUIC sessions are expressed as 431 session parameters, which cover cryptographic and transport 432 parameters, HTTP-specific settings and multicast-specific 433 configuration. 435 Session parameter exchange over IP multicast is difficult: 437 * In-band exchanges are one-way, and so the client does not have the 438 means to send session parameters. 440 * The lifecycle of any multicast sender is independent of the 441 multicast receiver. It is therefore unlikely that all receivers 442 will have joined a session in time to receive parameters sent at 443 the start of a multicast session. 445 A range of strategies exists to mitigate these points. However, each 446 has the possibility to add complexity to deployment and 447 manageability, transmission overhead, or other such concerns. This 448 document defines a solution that relies on the one-way announcement 449 of session parameters in advance of session establishment. This is 450 achieved using HTTP Alternative Services [RFC7838] and is explained 451 in Section 3. Other advertisement solutions are not prohibited but 452 are not explored in this document. 454 Session parameters MUST NOT change during the lifetime of a session. 455 This restriction also applies to HTTP-level settings (see 456 Section 5.1). 458 2.3. Session Identification 460 This document defines an optional session identifier used to identify 461 a session. This "Session ID" affords independence from multicast IP, 462 creating the possibility for a session to span multiple multicast 463 groups, or to migrate a session to a different multicast group. 464 Assignment of Session ID is considered out of this document's scope. 466 The Session ID is carried in the Destination Connection ID field of 467 the QUIC packet (see Section 4.3). Source Connection IDs are not 468 used. 470 The maximum size of a Session ID is 160 bits. The size of the 471 Destination Connection ID field used to convey the Session ID SHALL 472 be the smallest number of full bytes required to represent the full 473 Session ID value advertised in the "session-id" session parameter 474 (Section 10.2.4). If no "session-id" parameter is advertised, then 475 this session has a zero-length session ID, and the Destination 476 Connection ID field SHALL be omitted from all QUIC packets related to 477 the session. 479 A multicast sender participating in a session with an advertised 480 "session-id" session parameter MUST send QUIC packets with a matching 481 Session ID. Conversely, a multicast sender participating in a 482 session without an advertised "session-id" session parameter MUST NOT 483 send QUIC packets with a non-zero-length Destination Connection ID 484 field. 486 A multicast receiver participating in a session with an advertised 487 "session-id" session parameter MUST validate that the Session ID of 488 received QUIC packets matches that advertised in the session 489 parameters (Section 10.2.4) before any HTTP-level processing is done. 490 In the case of validation failure, the receiver SHOULD ignore the 491 packet in order to protect itself from denial-of-service attacks. 493 2.4. Session Security 495 *Authors' Note:* Security handshake (as described in WG documents) 496 is in flux. This section will track developments and will be 497 updated accordingly. 499 The QUIC cryptographic handshake ([RFC9000] and [RFC9001]) sets out 500 methods to achieve the goals of authenticated key exchange and QUIC 501 packet protection between two endpoints forming a QUIC connection. 502 The design facilitates low-latency connection; 1-RTT or 0-RTT. This 503 specification replaces the in-band security handshake, achieving 504 similar goals through the use of session parameters described in 505 Section 3.1. 507 Integrity and authenticity concerns are addressed in Section 6.1 and 508 Section 6.2 respectively. In order to protect themselves from attack 509 vectors, endpoints SHOULD NOT participate in sessions for which they 510 cannot establish reasonable confidence over the cipher suite or key 511 in use for that session. Participants MAY leave any session that 512 fails to successfully match anticipated security characteristics. 514 3. Session Advertisement 516 In this specification, connection negotiation is replaced with a 517 session advertisement mechanism based on HTTP Alternative Services 518 (Alt-Svc) [RFC7838]. This document specifies how the parameters of a 519 multicast QUIC session are expressed as Alt-Svc parameters. The 520 following sections provide a high-level view of these; further 521 details are provided in Section 10.2, with examples provided in 522 Appendix B.1. QUIC connection parameters not defined as, or related 523 to, Alt-Svc parameters are not used. 525 The definition of a session (including the session ID and its 526 parameters) is not the responsibility of any endpoint. Rather, 527 endpoints SHOULD use session advertisements to determine if they are 528 capable of participating in a given session. This document does not 529 specify which party is responsible for defining and/or advertising 530 multicast QUIC sessions. 532 Endpoints SHOULD NOT become participants in sessions where the 533 advertisement requirements set out in the present document are 534 unfulfilled. 536 The freshness of Alt-Svc multicast QUIC session advertisements is as 537 described in section 2.2 of [RFC7838]. 539 It is RECOMMENDED that session advertisements are carried over a 540 secure transport (such as HTTPS) which can guarantee the authenticity 541 and integrity of the Alt-Svc information. This addresses some of the 542 concerns around the protection of session establishment described in 543 Section 11.2. 545 *Authors' Note:* We invite review comments on mandating the use of 546 a secure transport for advertising sessions. 548 Senders MAY also advertise the availability of alternative sessions 549 by carrying Alt-Svc in a multicast QUIC session. 551 3.1. Security Context 553 *Authors' Note:* Security handshake (as described in WG documents) 554 is in flux. This section will track developments and will be 555 updated accordingly. 557 This specification replaces the in-band security handshake. The 558 session parameters "cipher suite", "key" and "iv" (described below) 559 allow for the establishment of a security context. In order to 560 protect themselves, endpoints SHOULD NOT participate in sessions for 561 which they cannot establish reasonable confidence over the cipher 562 suite, key, or IV in use for that session. Endpoints SHOULD leave 563 any sessions which fail to successfully match anticipated security 564 characteristics. 566 3.1.1. Cipher Suite 568 Cipher suite negotiation is replaced with a "cipher suite" session 569 parameter, which is advertised as the Alt-Svc parameter "cipher- 570 suite" (Section 10.2.1). 572 The Alt-Svc "cipher-suite" parameter is OPTIONAL. If present, this 573 parameter MUST contain only one value that corresponds to an entry in 574 the TLS Cipher Suite Registry (see http://www.iana.org/assignments/ 575 tls-parameters/tls-parameters.xhtml#tls-parameters-4). Session 576 advertisements that omit this parameter imply that the session is 577 operating with cipher suite 0x00,0x00 (NULL_WITH_NULL_NULL). 579 3.1.2. Key Exchange 581 Key exchange is replaced with a "key" session parameter, which is 582 advertised as the Alt-Svc parameter "key" (Section 10.2.2). The 583 parameter carries a variable-length hex-encoded key for use with the 584 session cipher suite. 586 The Alt-Svc "key" parameter is OPTIONAL. Session advertisements that 587 omit this parameter imply that the key may be available via an out- 588 of-band method not described in this document. 590 3.1.3. Initialization Vector 592 Initialization Vector (IV) exchange is replaced with an "iv" session 593 parameter, which is advertised as the Alt-Svc parameter "iv" 594 (Section 10.2.3). The parameter carries a variable-length hex- 595 encoded IV for use with the session cipher suite and key. 597 The Alt-Svc "iv" parameter is OPTIONAL. Session advertisements that 598 omit this parameter imply that the IV may be available via an out-of- 599 band method not described in this document. 601 3.2. Session Identification 603 [RFC9000] specifies how the QUIC connection identifiers are used, in 604 particular the independent selection of these identifiers by each 605 endpoint for its peer. In a unidirectional multicast environment, 606 there is no meaningful way for an endpoint to generate a connection 607 identifier for its peer to use. This document defines a "session 608 identifier" session parameter, which is advertised as the Alt-Svc 609 parameter "session-id" (Section 10.2.4). The requirements for the 610 usage of session identifiers have already been described in 611 Section 2.3. 613 The Alt-Svc "session-id" parameter is optional. Session 614 advertisements MAY contain at most one instance of a "session-id" 615 parameter. Session advertisements that identify the same Any Source 616 Multicast group {G} or Source Specific Multicast group {S,G} indicate 617 that multiple sessions are multiplexed in the same multicast group 618 and each such advertisement must carry a unique "session-id". 620 3.3. Session Idle Timeout 622 Conventional QUIC connections may be implicitly terminated following 623 a period of idleness (lack of network activity). The optional QUIC 624 TransportParameter "max_idle_timeout" provides a means for endpoints 625 to specify the timeout period. This document defines a "session idle 626 timeout" session parameter, which is advertised as the Alt-Svc 627 parameter "session-idle-timeout" (Section 10.2.5). This session 628 parameter mimics the behaviour of "max_idle_timeout", providing a 629 means for multicast QUIC sessions to define their own idle timeout 630 periods. 632 Session idle timeout may be prevented by keep-alive strategies 633 Section 4.10. 635 The Alt-Svc "session-idle-timeout" parameter is optional. Session 636 advertisements MAY contain zero or more instances of this parameter. 637 If it is repeated, the first occurrence MUST be used and subsequent 638 occurrences MUST be ignored. Session advertisements that omit the 639 "session-idle-timeout" parameter, or set it to zero never time out. 641 Receiving participants SHOULD leave multicast QUIC sessions when the 642 session idle timeout period has elapsed (Section 4.7). Leaving 643 participants MUST use the silent close method, in which no QUIC 644 "CONNECTION_CLOSE" frame is sent. 646 3.4. Session Peak Flow Rate 648 [RFC9000] specifies a credit-based stream- and connection-level flow 649 control scheme which prevents a fast sender from overwhelming a slow 650 receiver at the stream level, as well as an aggregate level of all 651 streams. Window size connection parameters are exchanged on 652 connection establishment using the required QUIC TransportParameters 653 "initial_max_data", "initial_max_stream_data_bidi_local", 654 "initial_max_stream_data_bidi_remote" and 655 "initial_max_stream_data_uni". In a unidirectional multicast 656 environment, such a scheme is infeasible. 658 This document defines a "peak flow rate" session parameter, expressed 659 in units of bits per second, which is advertised as the Alt-Svc 660 parameter "peak-flow-rate" (Section 10.2.7). This completely 661 replaces the transport parameters listed above, instead indicating 662 the maximum bit rate of QUIC payloads transmitted on all multicast 663 groups comprising the session. It applies at the aggregate level, 664 and is not specific to any single stream. 666 The Alt-Svc "peak-flow-rate" parameter is OPTIONAL. If the parameter 667 is repeated the first occurrence MUST be used and subsequent 668 occurrences MUST be ignored. Session advertisements that omit the 669 parameter imply that the flow rate is unlimited. 671 A multicast sender SHOULD NOT cause the advertised peak flow rate of 672 a session to be exceeded. A receiver MAY leave any session where the 673 advertised peak flow rate is exceeded. 675 3.5. Resource Concurrency 677 [RFC9000] considers concurrency in terms of the number of active 678 incoming streams, which is varied by the receiving endpoint adjusting 679 the maximum Stream ID. The initial value of maximum Stream ID is 680 controlled by the relevant required QUIC TransportParameters 681 "initial_max_streams_bidi" and "initial_max_streams_uni". They are 682 increased during the lifetime of a QUIC connection by the QUIC 683 "MAX_STREAMS" frame. In a unidirectional multicast environment, 684 there is no way for a receiver to specify an initial limit nor to 685 increase it. Therefore in multicast QUIC, the maximum Stream ID 686 (initial and always) is 2^62. This mechanism is not used to manage 687 concurrency in multicast QUIC. 689 Due to the profiling of maximum Stream ID, there is no role for the 690 QUIC "STREAMS_BLOCKED" frame and it is prohibited. Participants MUST 691 NOT send this frame type. Reception of this frame type MUST be 692 handled as described in Section 4.12. 694 This document specifies a "maximum concurrent resources" session 695 parameter, which is advertised as the Alt-Svc parameter "max- 696 concurrent-resources" (Section 10.2.6). This parameter replaces 697 "initial_max_stream_id_bidi" and "initial_max_stream_id_uni". It 698 advertises the maximum number of concurrent active resources 699 generated by a sender in a given multicast QUIC session. 701 The Alt-Svc "max-concurrent-resources" parameter is OPTIONAL. If the 702 parameter is repeated the first occurrence MUST be used and 703 subsequent occurrences MUST be ignored. Session advertisements that 704 omit the parameter imply that the maximum concurrency is unlimited. 706 A multicast sender participating in a session MUST NOT cause the 707 advertised "max-concurrent-resources" to be exceeded. A receiver MAY 708 leave any session where the advertised limit is exceeded, in order to 709 protect itself from denial-of-service attacks. 711 3.6. Additional TransportParameter Considerations 713 *Authors' Note:* This section will consider TransportParameters 714 that have not already been addressed, as required. It will track 715 developments and issues that may arise. 717 Section 19.21 of [RFC9000] defines a mechanism for endpoints to show 718 willingness to receive one or more extension frame types. It is not 719 possible for multicast QUIC receivers to signal this information to 720 senders. 722 This document defines an "extensions" session parameter, which is 723 advertised as the Alt-Svc parameter "extensions" Section 10.2.10 and 724 replaces the transport parameter exchange detailed above. The Alt- 725 Svc "extensions" parameter is optional. Session advertisements MAY 726 contain zero or more instances of this parameter. The parameter 727 lists transport parameter values present in the QUIC Transport 728 Parameter Registry as specified in Section 22.3 of [RFC9000]. 730 Only transport parameters which expressly reference Multicast QUIC 731 are considered valid extension parameters. 733 *Authors' Note:* The authors welcome suggestions for how to map 734 these extension types more cleanly into this document. 736 Participants SHOULD NOT join sessions advertising extensions that 737 they do not support, as QUIC frames are not self-describing. 739 3.7. Digest Algorithm 741 A method to provide content integrity is described in Section 6.1. 742 This specifies the means to convey a value computed by a particular 743 digest algorithm. The identity of the selected algorithm is also 744 indicated. Valid digest algorithms are collected in the IANA HTTP 745 Digest Algorithm Values registry (http://www.iana.org/assignments/ 746 http-dig-alg/http-dig-alg.xhtml#http-dig-alg-1). 748 This document specifies a "digest algorithm" session parameter, which 749 is advertised as the Alt-Svc parameter "digest-algorithm" 750 (Section 10.2.8). 752 *Authors' Note:* Section 6.1 contains an author's note on the 753 potential for content integrity to become mandatory. This section 754 will be updated in line with the outcome of that decision. 756 The Alt-Svc "digest-algorithm" parameter is OPTIONAL. Repetition of 757 the "digest algorithm" parameter in a single advertisement describes 758 an algorithm set that MAY be used across the session. Session 759 advertisements that omit the Alt-Svc parameter "digest-algorithm" 760 imply that either: 762 * the session does not use the content integrity mechanism, or 764 * the algorithm set is unrestricted, i.e. a sender may vary the 765 algorithm as it so chooses. This may lead to undesirable results 766 if receivers do not support a chosen algorithm. 768 Advertising the algorithm set for a session gives receivers the 769 opportunity to selectively join sessions where the algorithms are 770 known to be supported. This may help to mitigate latency issues in 771 the receiver resulting from joining a session only to discover some 772 of its parameters are not supported. 774 A multicast sender participating in a session MUST NOT use algorithms 775 outside the signalled digest algorithm set. A receiver MAY leave any 776 session where an algorithm outside the digest algorithm set is used. 778 3.8. Signature Algorithm 780 A method to provide content authenticity is described in Section 6.2. 781 This specifies the means to convey a value computed by a particular 782 signature algorithm. The identity of the selected algorithm is also 783 indicated. Valid signature algorithms are collected in the IANA 784 Signature Algorithms registry (http://www.iana.org/assignments/ 785 signature-algorithms). 787 This document specifies a "signature algorithm" session parameter, 788 which is advertised as the Alt-Svc parameter "signature-algorithm" 789 (Section 10.2.9). 791 *Authors' Note:* Section 6.2 contains an author's note on the 792 potential for content authenticity to become mandatory. This 793 section will be updated in line with the outcome of that decision. 795 The Alt-Svc "signature-algorithm" parameter is OPTIONAL. Repetition 796 of the "signature algorithm" parameter in a single advertisement 797 describes an algorithm set that MAY be used across the session. 798 Session advertisements that omit the Alt-Svc parameter "signature- 799 algorithm" imply that either: 801 * the session does not use the content authenticity mechanism, or 803 * the algorithm set is unrestricted i.e. a sender may vary the 804 algorithm as it so chooses. This may lead to undesirable results 805 if receivers do not support a chosen algorithm. 807 Advertising the algorithm set for a session gives receivers the 808 opportunity to selectively join sessions where the algorithms are 809 known to be supported. This may help to mitigate latency issues in 810 the receiver resulting from joining a session only to discover some 811 of its parameters are not supported. 813 A multicast sender participating in a session MUST NOT use algorithms 814 outside the signalled signature algorithm set. A receiver MAY leave 815 any session where an algorithm outside the signature algorithm set is 816 used. 818 4. QUIC Profile 820 *Authors' Note:* The QUIC transport document is subject to change. 821 This section is based on our best understanding of draft-ietf- 822 quic-transport-29. The authors will track developments and will 823 update this section accordingly. 825 The profile of [RFC9000] is presented in this section. In order to 826 preserve compatibility with conventional QUIC, the specification 827 works with a limited scope of change. However, the nature of 828 unidirectional multicast communications means that some protocol 829 procedures or behaviours need to be modified. 831 Section 5.3 of [RFC9000] defines a set of required actions that a 832 QUIC server and QUIC client must be able to perform. Due to the 833 limitations of this profile, all of the requirements in Section 5.3 834 of [RFC9000] are removed except for: 836 * Configuring the minimum and total number of permitted streams of 837 each type is described in Section 3.5. 839 * Multicast QUIC senders may still send "PING" frames to stop a 840 session from expiring as described in Section 4.10. 842 4.1. Packet Size 844 The means for determining an appropriate size for QUIC packets are 845 described in Section 14 of [RFC9000]. Implementations of this 846 specification SHOULD bear in mind that the Path Maximum Transmission 847 Unit (PMTU) may be affected by multicast IP technologies such as 848 Automatic Multicast Tunneling (AMT) [RFC7450]. Additionally, 849 consideration should be given toward the applicability of maximum 850 transmission unit discovery methods (such as PLPMTUD [RFC4821] and 851 PMTUD [RFC1191]) to multicast IP. 853 4.2. Packet Format 855 Endpoints implementing this specification MUST only send QUIC packets 856 with the short header form. As short header packets do not include a 857 length, senders MUST NOT attempt to coalesce any QUIC packets in the 858 same UDP datagram. Therefore, all UDP datagrams sent by senders 859 conforming to this profile contain exactly one QUIC packet. 861 4.2.1. Packet Numbers 863 All packets for this profile SHALL be numbered in the application 864 data packet number space. The initial and handshake packet number 865 spaces are not used by this profile, as the handshake is replaced by 866 an out-of-band mechanism (see Section 2.4). 868 The encoding of packet numbers in QUIC packets is described in 869 Section 17.1 of [RFC9000]. Senders must always use the same number 870 of bytes to represent the packet number for all packets sent to a 871 session. Because a receiver may join a session after the sender has 872 already sent several packets, it MUST NOT assume that the first 873 packet number will be 0. 875 4.2.2. Spin Bit 877 [RFC9000] specifies a bit in the 1-RTT packet header as the latency 878 spin bit that may be used to measure network round trip latency 879 between a client and a server. This mechanism is not usable in a 880 unidirectional multicast packet flow. Senders SHALL set the spin bit 881 to zero in all packets. Receivers SHOULD ignore the spin bit. 883 *Authors' Note:* The authors welcome suggestions for the use of 884 the spin bit in a multicast context. 886 4.3. Connection Identifier 888 The Destination Connection ID field MUST be non-zero-length in every 889 QUIC packet if the session was advertised with a "session-id" session 890 parameter (Section 10.2.4). If the multicast QUIC session 891 advertisement does not carry a "session identifier" session 892 parameter, then the Destination Connection ID MUST be zero-length in 893 any QUIC packet for that session. In the case where multiple 894 sessions are multiplexed on the same 5-tuple network association, the 895 Destination Connection ID field MUST be non-zero-length in every QUIC 896 packet and must be distinct for each session. 898 4.4. Stream Identifier 900 The maximum Stream ID of a multicast QUIC session is 2^62, as 901 explained in Section 3.5. With the exception of the first client- 902 initiated request Stream ID, which is reserved as described in 903 Section 5.2, all Stream ID values SHALL be of the server-initiated 904 unidirectional stream type. 906 4.5. Flow Control 908 Conventional QUIC provides stream- and connection-level flow control, 909 and endpoints manage this by sending QUIC "MAX_DATA" or 910 "MAX_STREAM_DATA" frames as required. When a sender is blocked from 911 sending flow-controlled frames, it sends an informational QUIC 912 "DATA_BLOCKED" or "STREAM_DATA_BLOCKED" frame. 914 In a unidirectional environment, the sender never has a receive 915 window and the receiver cannot send in-band updates. Therefore, the 916 management of flow-control windows and transmission of blockage 917 information is not supported by this profile. The QUIC "MAX_DATA", 918 "MAX_STREAM_DATA", "DATA_BLOCKED" and "STREAM_DATA_BLOCKED" frames 919 are prohibited by this profile. Participants MUST NOT send these 920 frame types. Reception of these frame types MUST be handled as 921 described in Section 4.12. 923 4.6. Stream Termination 925 A sender MAY prematurely terminate the transmission on any unreserved 926 QUIC Stream ID by setting the "FIN" bit of a QUIC "STREAM" frame, or 927 by sending a QUIC "RESET_STREAM" frame (as specified in [RFC9000] and 928 [QUIC-HTTP]). 930 Receiving participants MUST NOT make any attempt to send QUIC 931 "RESET_STREAM" frames to the multicast group. 933 4.7. Connection Shutdown 935 Explicit shutdown of a multicast QUIC session using QUIC methods is 936 not supported by this profile. 938 The QUIC "CONNECTION_CLOSE" frames and the Stateless Reset packet are 939 prohibited. Participants MUST NOT send these and reception MUST be 940 handled as described in Section 4.12. 942 Explicit session tear-down using HTTP semantics is allowed, as 943 described in Section 5.4. 945 Implicit shutdown by means of silent close is also supported, as 946 described in Section 3.3. 948 4.8. Connection Migration 950 [RFC9000] has a connection migration feature that allows a connection 951 to survive changes to endpoint addresses. This profile does not 952 currently support connection migration, and as such the QUIC 953 "NEW_CONNECTION_ID" and "RETIRE_CONNECTION_ID" frames are prohibited. 954 Similarly, the QUIC "PATH_CHALLENGE" and "PATH_RESPONSE" frames are 955 also prohibited, but additionally because they require bidirectional 956 capability that this profile does not provide. 958 Endpoints participating in a session conforming to this profile MUST 959 only use a single session ID for the duration of the session, and as 960 such there is no mapping for the "active_connection_id_limit" 961 transport parameter specified in section 5.1.1 of [RFC9000] in this 962 profile. 964 *Author's Note*: Seamless migration from one multicast QUIC 965 session to another is described in Section 2.1.3. 967 4.9. Explicit Congestion Notification 969 [RFC9000] specifies that clients may use Explicit Congestion 970 Notification (ECN) [RFC3168]. ECN allows receivers to inform senders 971 of impending congestion before packets are dropped, and the sender 972 may then reduce its transmission rate. As ECN requires bidirectional 973 communication for the receiver to inform the sender of the 974 congestion, the use of ECN for this profile is prohibited. 976 *Author's Note*: It is the responsibility of a receiver to 977 determine whether network conditions permit the uncongested 978 reception of a given session based on the advertised "peak-flow- 979 rate" parameter. 981 4.10. Session Keep-alive 983 The flow of traffic in a multicast QUIC session is driven by a 984 sender. There may be periods where the sender has no application 985 data to send for a period longer than the session idle timeout. This 986 profile repurposes the QUIC "PING" frame to act as a unidirectional 987 keep-alive message that may be sent in order to inform receivers that 988 the session should remain in the Fully-established state. [RFC9000] 989 contains guidance on the sending frequency of QUIC "PING" frames. 991 Senders MAY send a QUIC "PING" frame at any time in order to inform 992 receivers that the session traffic flow has not fallen idle. This 993 frame MUST NOT be acknowledged. Indeed, QUIC "ACK" frames are 994 prohibited by this profile (Section 4.11). 996 Receiving participants MUST NOT make any attempt to send QUIC "PING" 997 frames. 999 4.11. Loss Detection and Recovery 1001 Receivers implementing this profile MUST NOT make any attempt to 1002 acknowledge the reception of QUIC packets. The QUIC "ACK" frame is 1003 prohibited for both senders and receivers. Reception of this frame 1004 MUST be handled as described in Section 4.12. 1006 Section 7 specifies alternative strategies for loss recovery. 1008 4.12. Prohibited QUIC Frames and Packets 1010 The following QUIC packets MUST NOT be transmitted by participants: 1011 Any packets with a long header (Initial, 0-RTT Protected, Handshake, 1012 Retry), Version Negotiation, Stateless Reset. 1014 The following QUIC frames MUST NOT be transmitted by participants: 1015 "ACK", "CONNECTION_CLOSE", "CRYPTO", "DATA_BLOCKED", 1016 "HANDSHAKE_DONE", "MAX_DATA", "MAX_STREAM_DATA", "MAX_STREAMS", 1017 "NEW_CONNECTION_ID", "NEW_TOKEN", "PATH_CHALLENGE", "PATH_RESPONSE", 1018 "RETIRE_CONNECTION_ID", "STOP_SENDING", "STREAM_DATA_BLOCKED", 1019 "STREAMS_BLOCKED". 1021 In addition, any QUIC extension frames not advertised in the session 1022 advertisement Section 3.6 MUST NOT be transmitted by participants. 1024 The following QUIC frames MUST NOT be transmitted by receivers: 1025 "PING", "RESET_STREAM". 1027 Reception of a prohibited or non-advertised QUIC frame or packet is a 1028 protocol error. Receivers MUST ignore all prohibited QUIC frames and 1029 packets. 1031 5. HTTP/3 Profile 1033 *Authors' Note:* The HTTP/3 mapping document is subject to change. 1034 This section is based on our best understanding of draft-ietf- 1035 quic-http-29. The authors will track developments and will update 1036 this section accordingly. 1038 HTTP over multicast QUIC depends on HTTP server push, as described in 1039 Section 4.4 of [QUIC-HTTP]. Section 5.2 below applies an additional 1040 constraint on the use of server push. A multicast sender 1041 participating in a session pushes resources as a series of QUIC 1042 "STREAM" frames carrying HTTP/3 "PUSH_PROMISE", "HEADERS" and "DATA" 1043 frames. Examples of this are provided in Appendix B.2. Senders MUST 1044 comply with the requirements of the session parameters, as described 1045 earlier in Section 3. 1047 The profile of HTTP/3 specified in this section places additional 1048 constraints on the use of metadata compression (Section 5.3). 1050 5.1. HTTP Connection Settings 1052 The HTTP/3 "SETTINGS" frame is prohibited by this profile. 1053 Participants MUST NOT make any attempt to send this frame type. 1054 Reception of this frame MUST be handled as described in Section 5.7. 1056 5.2. Server Push 1058 Server push is, by default, disabled for HTTP/3 connections. A 1059 conventional HTTP/3 client enables and manages server push by 1060 controlling the maximum Push ID ([QUIC-HTTP], Section 7.2.7), 1061 achieved by sending the HTTP/3 "MAX_PUSH_ID" frame. 1063 This profile mandates the use of server push, and specifies no means 1064 to disable it. The maximum Push ID for multicast QUIC sessions 1065 (initial and always) is 2^62. Values of Push ID SHALL be allocated 1066 in accordance with [QUIC-HTTP]. 1068 Server push concurrency in multicast QUIC is described in 1069 Section 3.5. There is no role for the HTTP/3 "MAX_PUSH_ID" frame and 1070 it is prohibited. Participants MUST NOT send this frame type. 1071 Reception of this frame type MUST be handled as described in 1072 Section 5.7. 1074 For this profile, the Stream Type for any new server-initiated 1075 unidirectional stream MUST be Server Push ("0x01"). 1077 The HTTP/3 "CANCEL_PUSH" frame MAY be used by sending participants to 1078 abort sending a response for the identified server push. Usage of 1079 this frame SHALL follow the guidance for servers in [QUIC-HTTP]. 1081 Receiving participants MUST NOT make any attempt to send HTTP/3 1082 "CANCEL_PUSH" frames to the multicast group. 1084 Receiving participants SHOULD ignore all frames on server-initiated 1085 unidirectional streams for which the packet containing the Push ID 1086 has not been received. Receiving participants SHOULD ignore all 1087 frames on server-initiated unidirectional streams carrying a Push ID 1088 that was not previously promised to the receiver. 1090 Conventionally, pushed responses are associated with an explicit 1091 request from a client. This is not possible when using a 1092 unidirectional transport such as multicast IP. This profile reserves 1093 the first client-initiated, bidirectional QUIC stream. HTTP/3 1094 "PUSH_PROMISE" frames MUST be sent on this reserved Stream ID. 1096 5.3. Metadata Compression 1098 The compression of HTTP header fields is considered in QPACK 1099 [QUIC-QPACK], which describes two methods for the compression of HTTP 1100 header fields: indexing (via static or dynamic tables) and Huffman 1101 encoding. 1103 A multicast QUIC session, as described in the present document, does 1104 not provide the assurances (receiver participation, transport 1105 reliability) required to sufficiently maintain the dynamic decoding 1106 context. Therefore, this document requires that endpoints SHALL NOT 1107 use dynamic table indexing. It is RECOMMENDED that endpoints use 1108 static table indexing and/or Huffman encoding in order to benefit 1109 from the remaining compression methods available. 1111 5.4. Session Tear-down 1113 A multicast QUIC session MAY be explicitly torn down by means of the 1114 "Connection: close" HTTP header described in section 6.6 of 1115 [RFC7230]. A sender intending to leave the session SHOULD include 1116 the "Connection: close" header in its response metadata. A sender 1117 SHOULD transmit all outstanding frames related to remaining request/ 1118 response exchanges before ending transmission to the multicast group. 1119 A receiver SHOULD continue to receive and process frames until all 1120 outstanding request/response exchanges are complete. 1122 The HTTP/3 "GOAWAY" frame is prohibited. Participants MUST NOT send 1123 this and reception MUST be handled as described in Section 5.7. 1125 5.5. Effects of Packet Loss 1127 Since multicast QUIC is an inherently unreliable delivery mechanism, 1128 portions of HTTP messages sent by the sender may not be received by 1129 the receiver. Conventional HTTP/3 frames assume reliable, in-order 1130 delivery by the underlying QUIC stream. HTTP/3 frames do not 1131 therefore carry any information indicating their position within the 1132 stream, because this information is instead carried in the QUIC 1133 "STREAM" frame header. 1135 In multicast QUIC, packet loss leaves gaps in the flow of a stream, 1136 and therefore gaps in the HTTP/3 frame(s) that are carried on that 1137 stream. 1139 1. Loss of an HTTP/3 "PUSH_PROMISE" frame renders the reception of 1140 an entire stream impossible, since the receiver ignores the new 1141 push stream that has not been promised as described in 1142 Section 5.2. 1144 2. Loss of a QUIC packet comprising all or part of an HTTP/3 1145 "HEADERS" frame will likely prevent the QPACK decoder from 1146 successfully parsing the received metadata, leaving the receiver 1147 unable to make use of the affected HTTP representation. 1149 3. Loss of a QUIC packet containing an HTTP/3 "DATA" frame header 1150 leaves a receiver unsure where to look for the start of the next 1151 HTTP/3 frame on the same stream. In the unlikely event that the 1152 receiver manages to resynchronise to the start of a subsequent 1153 HTTP/3 "DATA" frame, the position of the payload in the HTTP 1154 representation data is unknown because it is not explicitly 1155 signalled in the "DATA" frame header. The Offset field in the 1156 QUIC "STREAM" header describes the offset within the stream, but 1157 it is impossible for the receiver to know the size of any "DATA" 1158 frame headers that were lost. 1160 4. Loss of QUIC packets that only contain part of an HTTP/3 "DATA" 1161 frame Data field (i.e. beyond the frame header) can be recovered 1162 using the unicast repair mechanism described in Section 7.2. 1164 [H3-DATA-OFFSET] describes the "DATA_WITH_OFFSET" HTTP/3 extension 1165 frame type, which can be used to solve the third problem described 1166 above. Multicast QUIC sessions that make use of the 1167 "DATA_WITH_OFFSET" extension frame MUST advertise the session with 1168 the appropriate non-compatible experiment identifier "data-offset" in 1169 the ALPN string, as specified in Section 9.1. 1171 5.6. HTTP/3 Extension frames 1173 Except where explicitly allowed by this specification (e.g. in 1174 Section 5.5 above), HTTP/3 extension frames (e.g. "ALTSVC") are 1175 prohibited by this profile. Participants MUST NOT make any attempt 1176 to send prohibited extension frame types. Reception of these MUST be 1177 handled as described in Section 5.7. 1179 5.7. Prohibited HTTP/3 Frames 1181 The following HTTP/3 frames MUST NOT be transmitted by participants: 1182 "GOAWAY", "MAX_PUSH_ID", "SETTINGS". 1184 In addition, all HTTP/3 extension frame types MUST NOT be transmitted 1185 by participants. 1187 The following HTTP/3 frames MUST NOT be transmitted by receivers: 1188 "CANCEL_PUSH". 1190 Reception of a prohibited HTTP/3 frame is a protocol error. 1191 Receivers MUST ignore prohibited HTTP/3 frames. 1193 6. Application-Layer Security 1195 As already described in Section 3.1, the implicit cipher suite used 1196 by a multicast QUIC session makes very limited provision for security 1197 in the transport and session layers. This section profiles the use 1198 of some additional features to provide equivalent functionality at 1199 the application-layer. 1201 6.1. Content Integrity 1203 In many applications, it is important to ensure that an HTTP 1204 representation has been received intact (i.e. has not suffered from 1205 transmission loss or random bit errors) before passing the received 1206 object on to the receiving application. A mechanism is therefore 1207 specified here to provide end-to-end content integrity protection for 1208 HTTP representations in transit. The use of this content integrity 1209 mechanism is RECOMMENDED. 1211 *Authors' Note:* We invite review comments on mandating the use of 1212 this content integrity mechanism. 1214 [RFC3230] specifies an instance digest HTTP header called "Digest". 1215 A sender MAY include this header in the HTTP/3 "HEADERS" frame of any 1216 representation it transmits and a receiver MAY use this header to 1217 validate the integrity of the received representation once it has 1218 been reassembled. Where this validation fails, the receiver SHOULD 1219 discard the representation without processing it further. 1221 Note that the digest value protects a whole HTTP instance (i.e. the 1222 representation of a resource at the point of transmission as opposed 1223 to the body of a particular HTTP message). In cases where partial 1224 representations are fragmented over one or more HTTP response 1225 messages, the digest value is computed over the complete 1226 representation prior to fragmentation into partial responses. 1228 Any of the algorithms specified in the IANA registry of digest 1229 algorithms (http://www.iana.org/assignments/http-dig-alg/http-dig- 1230 alg.xhtml#http-dig-alg-1) MAY be used in conjunction with the 1231 "Digest" header. There is no requirement for participants to support 1232 the full set of algorithms. 1234 6.2. Content Authenticity 1236 In some applications, it is important for a receiver to reassure 1237 itself that an HTTP representation has been received from an 1238 authentic source. It is also sometimes useful for a receiver to know 1239 that the information has not been tampered with in transit by a 1240 malicious intermediate actor. A mechanism is therefore specified 1241 here to prove the authenticity of HTTP messages in transit. The use 1242 of this content authenticity mechanism is RECOMMENDED for senders 1243 implementing this specification. 1245 *Authors' Note:* We invite review comments on mandating the use of 1246 this content authenticity mechanism. 1248 [I-D.cavage-http-signatures] specifies a means of securely signing 1249 metadata associated with any HTTP message. The resulting digital 1250 signature is conveyed in the "Signature" header of the message 1251 itself. The "Signature" header also conveys a list of HTTP header 1252 fields over which the signature was computed. A receiver MAY verify 1253 the "Signature" header in order to validate the authenticity of 1254 received metadata. Where this validation fails, the receiver SHOULD 1255 discard or ignore any related metadata and/or data without processing 1256 it further. 1258 Note that the signature proves the authenticity of the metadata in a 1259 single HTTP message. A "Signature" header MAY be included separately 1260 in the HTTP/3 "PUSH_PROMISE" frame (protecting the request metadata) 1261 and in the final (or only) HTTP/3 "HEADERS" frame relating to a 1262 particular resource (protecting the response metadata). In order to 1263 provide an additional level of protection, however, it is RECOMMENDED 1264 that the signature be computed over the combined request metadata 1265 (from the HTTP/3 "PUSH_PROMISE" frame) and the corresponding response 1266 metadata (from the HTTP/3 "HEADERS" frames) of the same resource. 1267 This binds the request metadata and response metadata together, 1268 providing the receiver with additional reassurance of authenticity. 1269 In this latter case, the combined digital signature SHALL be conveyed 1270 in the final (or only) HTTP/3 "HEADERS" frame. 1272 In applications where the detection of replay attacks is a 1273 requirement, it is RECOMMENDED that the "Date" header be included in 1274 the scope of the signature. It is RECOMMENDED that receivers use the 1275 value of the "Date" header for replay detection using appropriate 1276 strategies (e.g. checking for freshness). The definition of such 1277 strategies is beyond the scope of this document. 1279 In applications where the authenticity and integrity of the 1280 transmission are both important, it is RECOMMENDED that the "Digest" 1281 header specified in Section 6.1 above is included in the scope of the 1282 signature. By signing the instance digest, the authenticity and 1283 integrity of the HTTP message body are also assured in addition to 1284 that of the metadata. 1286 Any of the algorithms specified in the IANA registry of signature 1287 algorithms (http://www.iana.org/assignments/signature-algorithms) MAY 1288 be used in conjunction with the "Signature" header. There is no 1289 requirement for participants to support the full set of algorithms. 1291 6.3. Content Confidentiality 1293 In applications where there is a requirement for the content itself 1294 to remain confidential, appropriate steps SHOULD be taken to protect 1295 the application payload, for example by encrypting it. This document 1296 does not preclude the use of application-level encryption, but does 1297 not specify a mechanism for the distribution of content decryption 1298 keys. 1300 7. Loss Recovery 1302 Because the acknowledgement of received packets to multicast groups 1303 is prohibited by this specification (Section 4.11) the detection of 1304 discarded or corrupted packets is the sole responsibility of the 1305 receiver, and such losses must be recovered by means other than the 1306 retransmission mechanism specified in [RFC9000] and [RFC9002]. 1308 7.1. Forward Error Correction 1309 *Authors' Note:* A simple parity-based Forward Error Correction 1310 scheme was removed from the experimental QUIC wire protocol 1311 specification in version Q032. The IETF's QUIC Working Group is 1312 chartered to specify one (or more) new FEC schemes in the future. 1313 This section will track developments in this area, and will be 1314 updated accordingly. 1316 A sender MAY make use of a suitable Forward Error Correction scheme 1317 to allow a receiver to reconstruct lost packets from those that have 1318 been successfully received. 1320 7.2. Unicast Repair 1322 In the case where a lost QUIC packet cannot be recovered using 1323 Forward Error Correction, either because the number of packets lost 1324 exceeds the scheme's threshold for reconstruction, or because FEC is 1325 not in use on the multicast QUIC session, a receiver MAY instead 1326 recover the missing payload data using conventional unicast HTTP 1327 requests to an origin server. 1329 * The total size of the resource is indicated in the "content- 1330 length" response header carried in the HTTP/3 "HEADERS" frame. 1332 * The location of the missing data can be determined by examining 1333 the Offset field in the QUIC "STREAM" frame headers of 1334 successfully received QUIC packets. 1336 Using this information, a receiver MAY compose an efficient HTTP 1337 range request [RFC7233] to the origin server indicated in the URL. 1338 Several disjoint ranges MAY be combined into a single HTTP request. 1339 A receiver MAY direct its request to an alternative server using Alt- 1340 Svc information received on the multicast QUIC session, or else 1341 received as part of a previous unicast HTTP response according to the 1342 rules in [RFC7838]. 1344 8. Transmission of Partial Content 1346 Under certain circumstances, a sender may not be in full possession 1347 of a resource body when transmission begins, or may not be able to 1348 guarantee that a transmission will complete. In such cases, the 1349 sender MAY employ the syntax of an HTTP range request [RFC7233] to 1350 indicate partial content, as specified below. All receivers SHALL 1351 implement support for such HTTP range requests. 1353 If partial content is to be transmitted: 1355 * The "range" header (Section 3.1 of [RFC7233]) SHALL be present in 1356 the HTTP/3 "PUSH_PROMISE" frame. 1358 * The corresponding HTTP/3 "HEADERS" frame SHALL indicate HTTP 1359 status code 206. 1361 - The range being transmitted SHALL be indicated in a "content- 1362 range" header field and the size of the complete resource 1363 indicated in a "content-length" header field. 1365 9. Protocol Identifier 1367 The HTTP over multicast QUIC protocol specified in this document is 1368 identified by the application-layer protocol negotiation (ALPN) 1369 [RFC7301] identifier "h3m". The IANA registration of this protocol 1370 identifier can be found in Section 12.1. This reserves the ALPN 1371 identifier space but describes a protocol that does not use TLS. The 1372 usage of the "h3m" identifier for discoverability is described in 1373 Section 10. 1375 9.1. Draft Version Identification 1377 *RFC Editor's Note:* Please remove this section prior to 1378 publication of a final version of this document. 1380 Only implementations of the final, published RFC can identify 1381 themselves as "h3m". Until such an RFC exists, implementations MUST 1382 NOT identify themselves using this string. 1384 Implementations of draft versions of the protocol MUST add the string 1385 "-" and the corresponding draft number to the identifier. For 1386 example, draft-pardue-quic-http-mcast-06 is identified using the 1387 string "h3m-06". 1389 Non-compatible experiments that are based on these draft versions 1390 MUST append the string "-" and an experiment name to the identifier. 1391 For example, an experimental implementation based on draft-pardue- 1392 quic-http-mcast-06 which uses extension features not registered with 1393 the appropriate IANA registry might identify itself as "h3m-06- 1394 extension-foo". Note that any label MUST conform to the "token" 1395 syntax defined in Section 3.2.6 of [RFC7230]. Experimenters are 1396 encouraged to coordinate their experiments. 1398 10. Discovery of Multicast QUIC Sessions 1400 The announcement and discovery of services operating over multicast 1401 IP has previously been specified by the Session Description Protocol 1402 (SDP) [RFC4566], Session Announcement Protocol [RFC2974] and Session 1403 Initiation Protocol [RFC3261]. These are typically deployed together 1404 and in conjunction with a multicast-friendly transport such as the 1405 Real-time Transport Protocol (RTP) [RFC3550]. 1407 In contrast, the present document specifies a mechanism for 1408 advertising services that is built into HTTP metadata and is 1409 consistent across unicast and multicast resource delivery modes. 1410 This means that a single application-layer can be used for service 1411 advertisement/discovery, and for bulk data transmission/reception. 1412 Specifically, the "Alt-Svc" HTTP header is specified as the means to 1413 advertise multicast services from a unicast service. A unicast HTTP 1414 response MAY be decorated with an Alt-Svc value that hints to the 1415 client about the availability of the resource via a multicast QUIC 1416 session. A client that supports such a multicast QUIC session MAY 1417 then transparently switch to it. 1419 Symmetrically, the "Alt-Svc" header can also be used to advertise the 1420 unicast service from a multicast service. A resource transmitted as 1421 part of a multicast QUIC session MAY be decorated with an Alt-Svc 1422 value that hints to the client about the availability of the resource 1423 via an alternative unicast HTTP server. A receiver MAY then use this 1424 HTTP server for unicast resource patching (Section 7.2). 1426 Where HTTP over multicast QUIC sessions are advertised using Alt-Svc, 1427 the protocol identifier SHALL be "h3m", as specified in Section 9. 1429 10.1. Source-specific Multicast Advertisement 1431 Source-specific multicast (SSM) [RFC4607] MAY be used for the 1432 delivery of multicast services. 1434 *Authors' Note:* We invite review comments on mandating the use of 1435 source-specific multicast only. 1437 This document specifies the "source-address" parameter for Alt-Svc, 1438 which is used to provide the SSM source address to endpoints. 1440 Syntax: 1442 source-address = uri-host; see RFC7230, Section 2.7 1444 For example: 1446 source-address=192.0.2.1 1448 When a multicast QUIC session is provided using SSM, the "source- 1449 address" parameter MUST be advertised. If the parameter is repeated, 1450 the first occurrence MUST be used and subsequent occurrences MUST be 1451 ignored. 1453 10.2. Session Parameter Advertisement 1455 The concept of session parameters is introduced in Section 2.2. This 1456 section details how the session parameters are expressed as Alt-Svc 1457 parameters. 1459 10.2.1. Cipher Suite 1461 This document specifies the "cipher-suite" parameter for Alt-Svc, 1462 which carries the cipher suite in use by a multicast QUIC session. 1463 "cipher-suite" MUST contain one of the values contained in the TLS 1464 Cipher Suite Registry (http://www.iana.org/assignments/tls- 1465 parameters/tls-parameters.xhtml#tls-parameters-4): 1467 Syntax: 1469 cipher-suite = 4*4 HEXDIG 1471 For example, the following specifies cipher suite 0x13,0x01 1472 ("TLS_AES_128_GCM_SHA256"): 1474 cipher-suite=1301 1476 The requirements for endpoint usage of "cipher-suite" are described 1477 in Section 3.1. 1479 10.2.2. Session Key 1481 This document specifies the "key" parameter for Alt-Svc, which 1482 carries the cryptographic key in use by the multicast QUIC session. 1484 Syntax: 1486 key = *HEXDIG 1488 For example: 1490 key=4adf1eab9c2a37fd 1492 The requirements for endpoint usage of "key" are described in 1493 Section 3.1. 1495 10.2.3. Session Cipher Initialization Vector 1497 This document specifies the "iv" parameter for Alt-Svc, which carries 1498 the cipher Initialization Vector (IV) in use by the multicast QUIC 1499 session. 1501 Syntax: 1503 iv = *HEXDIG 1505 For example: 1507 iv=4dbe593acb4d1577ad6ba7dc3189834e 1509 The requirements for endpoint usage of "iv" are described in 1510 Section 3.1. 1512 10.2.4. Session Identification 1514 This document defines the "session-id" parameter for Alt-Svc, which 1515 carries the multicast QUIC session identifier. 1517 Syntax: 1519 session-id = *HEXDIG 1521 For example, the following specifies session 101 (0x65 hexadecimal): 1523 session-id=65 1525 The requirements for endpoint usage of "session-id" are described in 1526 Section 2.3. In the above example, the Destination Connection ID 1527 field in every QUIC packet header would be one byte in size. For a 1528 session-id of BADBEEF then then Destintation Connection ID field in 1529 every QUIC packet header would be four bytes in size. 1531 10.2.5. Session Idle Timeout Period 1533 This document specifies the "session-idle-timeout" parameter for Alt- 1534 Svc, which carries the idle timeout period in milliseconds of a 1535 multicast QUIC session. 1537 Syntax: 1539 session-idle-timeout = *DIGIT ; integer milliseconds 1541 For example, the following specifies a one-minute session idle 1542 timeout period: 1544 session-idle-timeout=60 1546 The requirements for endpoint usage of "session-idle-timeout" are 1547 described in Section 3.3. 1549 10.2.6. Resource Concurrency 1551 This document specifies the "max-concurrent-resources" parameter for 1552 Alt-Svc, which expresses the maximum number of concurrent active 1553 resources from the sender in a multicast QUIC session. 1555 Syntax: 1557 max-concurrent-resources = *DIGIT ; unsigned 32-bit integer 1559 For example, the following specifies that no more than 12 (decimal) 1560 resources will be concurrently active in the session: 1562 max-concurrent-resources=12 1564 The requirements for endpoint usage of "max-concurrent-resources" are 1565 described in Section 3.5. 1567 10.2.7. Session Peak Flow Rate 1569 This document specifies the "peak-flow-rate" parameter for Alt-Svc, 1570 which expresses the expected maximum aggregate transfer rate of data 1571 from all sources of the multicast QUIC session. 1573 Syntax: 1575 peak-flow-rate = *DIGIT ; bits per second 1577 For example, the following specifies a peak flow rate of 550 kbits/s 1578 in the session: 1580 peak-flow-rate=550000 1582 The requirements for endpoint usage of "peak-flow-rate" are described 1583 in Section 3.4. 1585 10.2.8. Digest Algorithm 1587 This document specifies the "digest-algorithm" parameter for Alt-Svc, 1588 which carries the digest algorithm in use by a multicast QUIC 1589 session. "digest-algorithm" MUST contain one of the values defined in 1590 the HTTP Digest Algorithm Values registry 1591 (https://www.iana.org/assignments/http-dig-alg/http-dig- 1592 alg.xhtml#http-dig-alg-1). 1594 Syntax: 1596 digest-algorithm = token 1597 For example, the following specifies a digest algorithm of SHA-256: 1599 digest-algorithm=SHA-256 1601 The requirements for endpoint usage of "digest-algorithm" are 1602 described in Section 3.7. 1604 10.2.9. Signature Algorithm 1606 This document specifies the "signature-algorithm" parameter for Alt- 1607 Svc, which carries the signature algorithm in use by a multicast QUIC 1608 session. "signature-algorithm" MUST contain one of the values defined 1609 in the Signature Algorithms registry 1610 (http://www.iana.org/assignments/signature-algorithms). 1612 Syntax: 1614 signature-algorithm = token 1616 For example, the following specifies a signature algorithm of SHA- 1617 256: 1619 signature-algorithm=rsa-sha256 1621 The requirements for endpoint usage of "signature-algorithm" are 1622 described in Section 3.8. 1624 10.2.10. Extensions 1626 This document specifies the "extensions" parameter for Alt-Svc, which 1627 carries a list of extension types potentially in use by a multicast 1628 QUIC session. "extensions" MUST only contain values from the QUIC 1629 Transport Parameter registry ([RFC9000], section 22.3) that have 1630 explicit support for multicast QUIC. Each entry in the list consists 1631 of a key identifying the transport parameter, and an optional value. 1632 Both the key and the value are hex-encoded. 1634 Syntax: 1636 extensions = DQUOTE ext-transport-param 1637 *[ "," ext-transport-param ] DQUOTE 1638 ext-transport-param = ext-key [ "=" ext-value ] 1639 ext-key = 4*4HEXDIG; Transport Parameter key 1640 ext-value = *HEXDIG; Optional Transport Parameter value 1642 For example, the following specifies two extensions: 1644 extensions="0094,0d0d=f00" 1645 The requirements for endpoint usage of "extensions" are described in 1646 Section 3.6 1648 11. Security Considerations 1650 This document specifies a profile of QUIC and HTTP/3 that changes the 1651 security model. In order to address this, application-level security 1652 methods are described in Section 6. This document does not preclude 1653 the use of secure multicast approaches that may provide additional 1654 security assurances required for certain use cases. 1656 The use of side-channel or out-of-band technologies (potentially 1657 bidirectional interactions) to support multicast QUIC sessions are 1658 considered out of this document's scope. Services using such 1659 technologies should apply their security considerations accordingly. 1661 11.1. Pervasive Monitoring 1663 Certain multicast deployment architectures may require the use of a 1664 session decryption key shared by all participants. Furthermore, the 1665 discovery mechanism described in this document provides a means for a 1666 receiver to obtain a session decryption key without joining the 1667 session. The act of removing packet protection in order to inspect 1668 or modify application contents may, in certain deployments, be 1669 trivial. The exploration of restricting key learning or session 1670 joining to authorised participants goes beyond the scope of this 1671 document. 1673 Because in-band multicast interactions are unidirectional, the impact 1674 of Pervasive Monitoring [RFC7258] on in-band traffic flows is 1675 inherently reduced. Actors can only inspect or modify sender- 1676 initiated traffic. Additional measures for content confidentiality 1677 may mitigate the impact further. This is discussed in Section 6.3. 1679 Further Pervasive Monitoring concerns are addressed in the following 1680 sections. 1682 11.1.1. Large-scale Data Gathering and Correlation 1684 Multicast QUIC sessions decouple sending and receiving participants. 1685 Session participation is subject to operations that allow an endpoint 1686 to join or leave a multicast group, typically IGMP [RFC3376] or MLD 1687 [RFC3810]. The propagation intent of these messages travelling 1688 deeper through a network hierarchy generally leads to the 1689 anonymisation of data if implemented as specified. It may be 1690 possible to gather user-identifiable messages close to the network 1691 edge, for example a router logging such messages. However, this 1692 would require wide-ranging access across Internet Service Provider 1693 networks. Therefore, while such attacks are feasible, it can be 1694 asserted that gathering and correlating user-identifiable traffic is 1695 difficult to perform covertly and at scale. 1697 11.1.2. Changing Content 1699 Sessions that use a symmetric key for packet protection are subject 1700 to the possibility of a malicious actor modifying traffic at some 1701 point in the network between a legitimate sender and one (or more) 1702 receivers. Receiver-side validation, as specified in Section 6 of 1703 the present document, and also in [RFC9000], allows for the detection 1704 of such modification. Two approaches help mitigate the impact of 1705 modification; the first is application-level methods that protect 1706 data (Section 6.1) and metadata (Section 6.2); the second is 1707 reduction of the QUIC packet attack surface by means of removal of 1708 many frame types (Section 4.12 and Section 5.7). 1710 11.2. Protection of Discovery Mechanism 1712 Multicast QUIC session advertisements SHOULD be conveyed over a 1713 secure transport that guarantees authenticity and integrity in order 1714 to mitigate attacks related to a malicious service advertisement, for 1715 example a "man in the middle" directing endpoints to a service that 1716 may lead to other attacks or exploitations. 1718 *Authors' Note:* We invite review comments on mandating the use of 1719 a secure transport for advertising sessions. 1721 Endpoints that make use of multicast QUIC session advertisements 1722 SHOULD have reasonable assurance that the alternative service is 1723 under control of, and valid for, the whole origin, as described in 1724 Section 2.1 of [RFC7838]. Section 6.2 discusses measures that may be 1725 used to fulfil this requirement. 1727 11.3. Spoofing 1729 11.3.1. Sender Spoofing 1731 A malicious actor may be able to stage a spoof attack by sending fake 1732 QUIC packets to a multicast QUIC session. This could affect the 1733 operation or behaviour of receivers. In a multicast scenario, this 1734 form of attack has the potential to scale massively. 1736 The feasibility of spoofing a multicast sender is governed by the 1737 characteristics of the multicast deployment and network 1738 infrastructure. The use of source-specific multicast [RFC4607] may 1739 reduce the feasibility. The use of content authenticity 1740 (Section 6.2) may mitigate concerns for the application-level 1741 messages. However, there remains the possibility for transport-level 1742 messages to be spoofed. Multicast applications should consider 1743 further mitigations to address this concern. 1745 11.4. Replay Attacks 1747 Conventional QUIC strategies for protecting against replay attacks 1748 apply similarly here. 1750 Certain multicast QUIC sessions may use a shared key for transport- 1751 level encryption, which would allow an attacker to record, decrypt, 1752 repackage and replay QUIC packets. Section 6.2 discusses how the 1753 application-level contents may be protected from replay (by signing 1754 the "Date" HTTP header), which provides some mitigation to the 1755 success rate or effects of replay attacks. 1757 11.5. Message Deletion 1759 Since HTTP over multicast QUIC is designed to tolerate unreliable 1760 delivery, the impacts of message deletion attacks are presumed to be 1761 small. Deletion of packets carrying HTTP headers will cause a 1762 receiver to ignore subsequent packets carrying body data. 1763 Furthermore, the use of multicast QUIC sessions is opportunistic; 1764 disruption in service (for example, deleting packets and causing a 1765 receiver to fail in construction of a content object) is mitigated by 1766 falling back to a unicast service. Considerations for how this may 1767 affect the performance of the unicast service are given in 1768 Section 11.6.3. 1770 11.6. Denial of Service 1772 11.6.1. Unprotected Frames and Packets 1774 The profile described in the present document provides the means for 1775 a multicast sender to protect QUIC packets with a shared key, which 1776 is not a strong protection. The weak protection of QUIC packets 1777 could present a denial-of-service risk. To mitigate the impact of 1778 handling such QUIC packets, certain frames and packets are prohibited 1779 as described in (Section 4.12 and Section 5.7). 1781 The frame types that are allowed by this profile do not present a 1782 risk of denial of service. Concerns over authenticity and integrity 1783 are addressed by the application-layer protection mechanisms 1784 described in Section 6. 1786 11.6.2. Network Performance Degradation 1788 The possibility for malfunctioning or malicious participants to 1789 degrade the network is a broad issue and considered out of scope for 1790 this document. Guidelines and concerns discussed in UDP Best 1791 Practices [RFC8085] and other sources apply equally here. This 1792 specification does not preclude the use of network performance 1793 degradation mitigation solutions such as network circuit breakers. 1795 11.6.3. Unicast Repair Stampeding Herd 1797 Deployments that support the unicast repair mechanism described in 1798 Section 7.2 should be aware that a triggering of this behaviour 1799 (either deliberate, planned or unplanned) in a large population of 1800 multicast receivers may cause a stampeding herd of client requests to 1801 the unicast repair service. Service operators SHOULD mitigate the 1802 impact of stampeding herd on their deployment. 1804 11.7. Receiver Resource Usage 1806 The application of receiver-side validation, as defined in the 1807 present document and in [RFC9000], adds some protection against 1808 allocating resource to the processing of bad data. 1810 11.8. Unicast Repair Information Leakage 1812 The unicast repair mechanism may lead to the leakage of user 1813 behaviour data. An attacker could gain insight into any receiver 1814 participating in a multicast QUIC session, for example by monitoring 1815 the TCP port of the unicast alternative. This alone is no worse than 1816 current abilities to monitor unicast interactions, for example 1817 observing the SNI field contained in a TLS ClientHello. The complete 1818 protection of unicast interactions is beyond the scope of this 1819 document. However, knowledge that a user (or group of users) has 1820 participated in a session is sensitive and may be obtained by 1821 correlation between with observable multicast and unicast traffic. 1823 To give an example, a malicious "man in the middle" could purposely 1824 cause all receivers to perform a unicast repair (by disrupting the 1825 QUIC traffic flow in some way). The disruption is untargeted and may 1826 be simple to orchestrate, but the correlation of user activity data, 1827 especially across a distributed repair service (e.g. a CDN), requires 1828 resources that may reduce the attractiveness of such an attack. 1830 The ability for an attacker to disrupt multicast QUIC sessions is 1831 mitigated by this profile (mainly the prohibition of frames and 1832 packets). Application-layer security measures described in Section 6 1833 reduce the feasibility further. 1835 Multicast receivers concerned about this form of leakage can 1836 eliminate this risk completely by disabling support for unicast 1837 repair, at the potential cost of reduced service quality. 1839 12. IANA Considerations 1841 12.1. Registration of Protocol Identification String 1843 This document creates a new registration for the identification of 1844 the HTTP over multicast QUIC protocol in the "Application-Layer 1845 Protocol Negotiation (ALPN) Protocol IDs" registry established by 1846 [RFC7301]. 1848 The "h3m" string identifies HTTP semantics expressed as HTTP mapped 1849 to a QUIC layer and carried over IP multicast: 1851 Protocol: Bulk data transport using HTTP over multicast QUIC 1853 Identification Sequence: 0x68 0x33 0x6D ("h3m") 1855 Specification: This document, Section 9 1857 This entry reserves an identifier that is not allowed to appear in 1858 TLS Application-Layer Protocol Negotiation. 1860 12.2. Registration of Alt-Svc parameters 1862 This document creates seven registrations for the identification of 1863 parameters for the "Hypertext Transfer Protocol (HTTP) Alt-Svc 1864 Parameter Registry" established by [RFC7838] 1865 (http://www.iana.org/assignments/tls-extensiontype-values/tls- 1866 extensiontype-values.xhtml#alpn-protocol-ids). 1868 12.2.1. Source Address 1870 Parameter name: source-address 1872 Specification: This document, Section 10.1 1874 12.2.2. Cipher Suite 1876 Parameter name: cipher-suite 1878 Specification: This document, Section 10.2.1 1880 12.2.3. Key 1882 Parameter name: key 1884 Specification: This document, Section 10.2.2 1886 12.2.4. Initialization Vector 1888 Parameter name: iv 1890 Specification: This document, Section 10.2.3 1892 12.2.5. Session Identifier 1894 Parameter name: session-id 1896 Specification: This document, Section 10.2.4 1898 12.2.6. Session Idle Timeout 1900 Parameter name: session-idle-timeout 1902 Specification: This document, Section 10.2.5 1904 12.2.7. Maximum Concurrent Resources 1906 Parameter name: max-concurrent-resources 1908 Specification: This document, Section 10.2.6 1910 12.2.8. Peak Flow Rate 1912 Parameter name: peak-flow-rate 1914 Specification: This document, Section 10.2.7 1916 12.2.9. Digest Algorithm 1918 Parameter name: digest-algorithm 1920 Specification: This document, Section 10.2.8 1922 12.2.10. Signature Algorithm 1924 Parameter name: signature-algorithm 1926 Specification: This document, Section 10.2.9 1928 12.2.11. Extension 1930 Parameter name: extension 1932 Specification: This document, Section 10.2.10 1934 13. References 1936 13.1. Normative References 1938 [H3-DATA-OFFSET] 1939 Hurst, S., "An Offset Extension Frame For HTTP/3 Data", 1940 Work in Progress, Internet-Draft, draft-hurst-quic-http- 1941 data-offset-frame-01, 1942 . 1945 [I-D.cavage-http-signatures] 1946 Cavage, M. and M. Sporny, "Signing HTTP Messages", Work in 1947 Progress, Internet-Draft, draft-cavage-http-signatures-12, 1948 21 October 2019, . 1951 [QUIC-HTTP] 1952 Bishop, M., Ed., "Hypertext Transfer Protocol Version 3 1953 (HTTP/3)", Work in Progress, Internet-Draft, draft-ietf- 1954 quic-http-34, . 1957 [QUIC-QPACK] 1958 Krasic, C., Ed., Bishop, M., Ed., and A. Frindell, Ed., 1959 "QPACK: Header Compression for HTTP over QUIC", Work in 1960 Progress, Internet-Draft, draft-ietf-quic-qpack-21, 1961 . 1964 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 1965 Requirement Levels", BCP 14, RFC 2119, 1966 DOI 10.17487/RFC2119, March 1997, 1967 . 1969 [RFC3168] Ramakrishnan, K., Floyd, S., and D. Black, "The Addition 1970 of Explicit Congestion Notification (ECN) to IP", 1971 RFC 3168, DOI 10.17487/RFC3168, September 2001, 1972 . 1974 [RFC3230] Mogul, J. and A. Van Hoff, "Instance Digests in HTTP", 1975 RFC 3230, DOI 10.17487/RFC3230, January 2002, 1976 . 1978 [RFC4607] Holbrook, H. and B. Cain, "Source-Specific Multicast for 1979 IP", RFC 4607, DOI 10.17487/RFC4607, August 2006, 1980 . 1982 [RFC5234] Crocker, D., Ed. and P. Overell, "Augmented BNF for Syntax 1983 Specifications: ABNF", STD 68, RFC 5234, 1984 DOI 10.17487/RFC5234, January 2008, 1985 . 1987 [RFC7230] Fielding, R., Ed. and J. Reschke, Ed., "Hypertext Transfer 1988 Protocol (HTTP/1.1): Message Syntax and Routing", 1989 RFC 7230, DOI 10.17487/RFC7230, June 2014, 1990 . 1992 [RFC7233] Fielding, R., Ed., Lafon, Y., Ed., and J. Reschke, Ed., 1993 "Hypertext Transfer Protocol (HTTP/1.1): Range Requests", 1994 RFC 7233, DOI 10.17487/RFC7233, June 2014, 1995 . 1997 [RFC7234] Fielding, R., Ed., Nottingham, M., Ed., and J. Reschke, 1998 Ed., "Hypertext Transfer Protocol (HTTP/1.1): Caching", 1999 RFC 7234, DOI 10.17487/RFC7234, June 2014, 2000 . 2002 [RFC7301] Friedl, S., Popov, A., Langley, A., and E. Stephan, 2003 "Transport Layer Security (TLS) Application-Layer Protocol 2004 Negotiation Extension", RFC 7301, DOI 10.17487/RFC7301, 2005 July 2014, . 2007 [RFC7405] Kyzivat, P., "Case-Sensitive String Support in ABNF", 2008 RFC 7405, DOI 10.17487/RFC7405, December 2014, 2009 . 2011 [RFC7838] Nottingham, M., McManus, P., and J. Reschke, "HTTP 2012 Alternative Services", RFC 7838, DOI 10.17487/RFC7838, 2013 April 2016, . 2015 [RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC 2016 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, 2017 May 2017, . 2019 [RFC9000] Iyengar, J., Ed. and M. Thomson, Ed., "QUIC: A UDP-Based 2020 Multiplexed and Secure Transport", RFC 9000, 2021 DOI 10.17487/RFC9000, May 2021, 2022 . 2024 13.2. Informative References 2026 [RFC1112] Deering, S., "Host extensions for IP multicasting", STD 5, 2027 RFC 1112, DOI 10.17487/RFC1112, August 1989, 2028 . 2030 [RFC1191] Mogul, J. and S. Deering, "Path MTU discovery", RFC 1191, 2031 DOI 10.17487/RFC1191, November 1990, 2032 . 2034 [RFC2974] Handley, M., Perkins, C., and E. Whelan, "Session 2035 Announcement Protocol", RFC 2974, DOI 10.17487/RFC2974, 2036 October 2000, . 2038 [RFC3261] Rosenberg, J., Schulzrinne, H., Camarillo, G., Johnston, 2039 A., Peterson, J., Sparks, R., Handley, M., and E. 2040 Schooler, "SIP: Session Initiation Protocol", RFC 3261, 2041 DOI 10.17487/RFC3261, June 2002, 2042 . 2044 [RFC3376] Cain, B., Deering, S., Kouvelas, I., Fenner, B., and A. 2045 Thyagarajan, "Internet Group Management Protocol, Version 2046 3", RFC 3376, DOI 10.17487/RFC3376, October 2002, 2047 . 2049 [RFC3550] Schulzrinne, H., Casner, S., Frederick, R., and V. 2050 Jacobson, "RTP: A Transport Protocol for Real-Time 2051 Applications", STD 64, RFC 3550, DOI 10.17487/RFC3550, 2052 July 2003, . 2054 [RFC3810] Vida, R., Ed. and L. Costa, Ed., "Multicast Listener 2055 Discovery Version 2 (MLDv2) for IPv6", RFC 3810, 2056 DOI 10.17487/RFC3810, June 2004, 2057 . 2059 [RFC4566] Handley, M., Jacobson, V., and C. Perkins, "SDP: Session 2060 Description Protocol", RFC 4566, DOI 10.17487/RFC4566, 2061 July 2006, . 2063 [RFC4821] Mathis, M. and J. Heffner, "Packetization Layer Path MTU 2064 Discovery", RFC 4821, DOI 10.17487/RFC4821, March 2007, 2065 . 2067 [RFC5737] Arkko, J., Cotton, M., and L. Vegoda, "IPv4 Address Blocks 2068 Reserved for Documentation", RFC 5737, 2069 DOI 10.17487/RFC5737, January 2010, 2070 . 2072 [RFC5740] Adamson, B., Bormann, C., Handley, M., and J. Macker, 2073 "NACK-Oriented Reliable Multicast (NORM) Transport 2074 Protocol", RFC 5740, DOI 10.17487/RFC5740, November 2009, 2075 . 2077 [RFC6676] Venaas, S., Parekh, R., Van de Velde, G., Chown, T., and 2078 M. Eubanks, "Multicast Addresses for Documentation", 2079 RFC 6676, DOI 10.17487/RFC6676, August 2012, 2080 . 2082 [RFC6726] Paila, T., Walsh, R., Luby, M., Roca, V., and R. Lehtonen, 2083 "FLUTE - File Delivery over Unidirectional Transport", 2084 RFC 6726, DOI 10.17487/RFC6726, November 2012, 2085 . 2087 [RFC7258] Farrell, S. and H. Tschofenig, "Pervasive Monitoring Is an 2088 Attack", BCP 188, RFC 7258, DOI 10.17487/RFC7258, May 2089 2014, . 2091 [RFC7450] Bumgardner, G., "Automatic Multicast Tunneling", RFC 7450, 2092 DOI 10.17487/RFC7450, February 2015, 2093 . 2095 [RFC8085] Eggert, L., Fairhurst, G., and G. Shepherd, "UDP Usage 2096 Guidelines", BCP 145, RFC 8085, DOI 10.17487/RFC8085, 2097 March 2017, . 2099 [RFC8200] Deering, S. and R. Hinden, "Internet Protocol, Version 6 2100 (IPv6) Specification", STD 86, RFC 8200, 2101 DOI 10.17487/RFC8200, July 2017, 2102 . 2104 [RFC8866] Begen, A., Kyzivat, P., Perkins, C., and M. Handley, "SDP: 2105 Session Description Protocol", RFC 8866, 2106 DOI 10.17487/RFC8866, January 2021, 2107 . 2109 [RFC9001] Thomson, M., Ed. and S. Turner, Ed., "Using TLS to Secure 2110 QUIC", RFC 9001, DOI 10.17487/RFC9001, May 2021, 2111 . 2113 [RFC9002] Iyengar, J., Ed. and I. Swett, Ed., "QUIC Loss Detection 2114 and Congestion Control", RFC 9002, DOI 10.17487/RFC9002, 2115 May 2021, . 2117 Appendix A. Acknowledgements 2119 The authors would like to thank the following for their contributions 2120 to the design described in the present document: Brandon Butterworth, 2121 Chris Poole, Craig Taylor and David Waring. 2123 We are also grateful to Thomas Swindells and Magnus Westerlund for 2124 their helpful review comments. 2126 Appendix B. Examples 2128 This appendix contains examples of multicast QUIC session 2129 advertisement and resource transfer (with and without application- 2130 layer content security). 2132 B.1. Session Advertisement 2134 This section shows several different examples of an HTTP service 2135 advertising a multicast QUIC session. Examples are given in IPv4 2136 form, using reserved address ranges as specified in [RFC5737] and 2137 [RFC6676]. 2139 B.1.1. Source-specific Multicast QUIC Session 2141 Advertisement of a multicast QUIC session operating on the source- 2142 specific multicast group address 232.0.0.1 on port 2000 with the 2143 source address 192.0.2.1. The session ID is 16 (0x10) and the idle 2144 timeout is one minute. At most 10 resources may be concurrently 2145 active in the session and the flow rate should not exceed 10 kbits/s. 2146 The multicast transport is unencrypted. 2148 HTTP Alternative Service header field: 2150 Alt-Svc: 2151 h3m="232.0.0.1:2000"; source-address="192.0.2.1"; 2152 session-id=10; session-idle-timeout=60; 2153 max-concurrent-resources=10; peak-flow-rate=10000 2155 B.1.2. Source-specific Multicast QUIC Session with Transport Encryption 2156 using a Symmetric Key 2158 Advertisement of a multicast QUIC session operating on the IPv6 2159 globally-scoped source-specific multicast group address ff3e::1234 on 2160 port 2000 with the source address 2001:db8::1. The session ID is 16 2161 (0x10) and the idle timeout is one minute. At most 10 resources may 2162 be concurrently active in the session and the flow rate should not 2163 exceed 10 kbits/s. The multicast transport is encrypted using the 2164 AEAD cipher suite 0x13,0x01 ("TLS_AES_128_GCM_SHA256") with the 2165 shared session key and IV provided. 2167 HTTP Alternative Service header field: 2169 Alt-Svc: 2170 h3m="[ff3e::1234]:2000"; source-address="2001:db8::1"; 2171 session-id=10; session-idle-timeout=60; 2172 max-concurrent-resources=10; peak-flow-rate=10000; 2173 cipher-suite=1301; key=4adf1eab9c2a37fd; 2174 iv=4dbe593acb4d1577ad6ba7dc3189834e 2176 B.1.3. Source-specific Multicast QUIC Session with Transport 2177 Encryption, Content Integrity and Authenticity 2179 Advertisement of a multicast QUIC session operating on the IPv6 2180 globally-scoped source-specific multicast group address ff3e::1234 on 2181 port 2000 with the source address 2001:db8::1. The session ID is 16 2182 (0x10) and the idle timeout is one minute. At most 10 resources may 2183 be concurrently active in the session and the flow rate should not 2184 exceed 10 kbits/s. The multicast transport is encrypted using the 2185 AEAD cipher suite 0x13,0x01 ("TLS_AES_128_GCM_SHA256") with the 2186 shared session key and IV provided. Content integrity is in use with 2187 the digest algorithm set restricted to SHA-256. Content authenticity 2188 is in use with the signature algorithm set restricted to rsa-sha256. 2190 HTTP Alternative Service header field: 2192 Alt-Svc: 2193 h3m="[ff3e::1234]:2000"; source-address="2001:db8::1"; 2194 session-id=10; session-idle-timeout=60; 2195 max-concurrent-resources=10; peak-flow-rate=10000; 2196 cipher-suite=1301; key=4adf1eab9c2a37fd; 2197 iv=4dbe593acb4d1577ad6ba7dc3189834e; 2198 digest-algorithm=SHA-256; signature-algorithm=rsa-sha256 2200 B.2. Resource Transfer 2202 This section shows several different examples of the HTTP message 2203 patterns for a single resource. 2205 Examples that show HTTP/3 "PUSH_PROMISE" or "HEADERS" frames describe 2206 the contents of enclosed header block fragments. 2208 B.2.1. Transfer without Content Integrity or Authenticity 2210 HTTP/3 "PUSH_PROMISE" frame: 2212 :method: GET 2213 :scheme: https 2214 :path: /files/example.txt 2215 :authority: example.org 2217 HTTP/3 "HEADERS" frame: 2219 :status: 200 2220 content-length: 100 2221 content-type: text/plain 2222 date: Fri, 20 Jan 2017 10:00:00 GMT 2224 HTTP/3 "DATA" frame containing 100 bytes of response body data: 2226 ... 2228 B.2.2. Transfer of Partial Content without Content Integrity or 2229 Authenticity 2231 In this example, partial content is transferred as described in 2232 Section 8. The "Range" request header is used to indicate the 2233 sender's original intention to transfer all 100 bytes of the 2234 representation. The "Content-Range" response header indicates that 2235 only the first 50 bytes were actually sent. 2237 HTTP/3 "PUSH_PROMISE" frame: 2239 :method: GET 2240 :scheme: https 2241 :path: /files/example.txt 2242 :authority: example.org 2243 range: bytes=0-* 2245 HTTP/3 "HEADERS" frame: 2247 :status: 206 2248 content-length: 100 2249 content-range: bytes 0-49/100 2250 content-type: text/plain 2251 date: Fri, 20 Jan 2017 10:00:00 GMT 2253 HTTP/3 "DATA" frame containing 50 bytes of response body data: 2255 ... 2257 B.2.3. Transfer with Content Integrity and without Authenticity 2259 In this example, content integrity is assured by the inclusion of the 2260 "Digest" response header, as described in Section 6.1. 2262 HTTP/3 "PUSH_PROMISE" frame: 2264 :method: GET 2265 :scheme: https 2266 :path: /files/example.txt 2267 :authority: example.org 2269 HTTP/3 "HEADERS" frame including the "Digest" header: 2271 :status: 200 2272 content-length: 100 2273 content-type: text/plain 2274 date: Fri, 20 Jan 2017 10:00:00 GMT 2275 digest: SHA-256=DieQ9zfRaDdyAilTVCvmBePuxMm+B6cNocP+QCrNSqo= 2277 HTTP/3 "DATA" frame containing 100 bytes of response body data: 2279 ... 2281 B.2.4. Partial Transfer with Content Integrity and without Authenticity 2283 In this example, partial content is transferred as described in 2284 Section 8. The "Range" request header is used to indicate the 2285 sender's intention to transfer all 100 bytes of the representation. 2286 The "Content-Range" response header indicates that only the first 50 2287 bytes were actually sent. Content integrity is assured by the 2288 inclusion of the "Digest" response header, as described in 2289 Section 6.1. 2291 HTTP/3 "PUSH_PROMISE" frame: 2293 :method: GET 2294 :scheme: https 2295 :path: /files/example.txt 2296 :authority: example.org 2297 range: bytes=0-* 2299 HTTP/3 "HEADERS" frame including the "Digest" header: 2301 :status: 206 2302 content-length: 100 2303 content-range: bytes 0-49/100 2304 content-type: text/plain 2305 date: Fri, 20 Jan 2017 10:00:00 GMT 2306 digest: SHA-256=DieQ9zfRaDdyAilTVCvmBePuxMm+B6cNocP+QCrNSqo= 2308 HTTP/3 "DATA" frame containing 50 bytes of response body data: 2310 ... 2312 B.2.5. Transfer with Content Integrity and Authenticity 2314 In this example, content integrity is assured by the inclusion of the 2315 "Digest" response header, as described in Section 6.1. Content 2316 authenticity is assured separately for the request and the response 2317 messages by the "Signature" header which protects the header fields 2318 described in further detail below. The "Signature" header parameter 2319 "keyId" contains the URL of a file containing the public key related 2320 to the multicast sender's private key used to create the digital 2321 signature. 2323 HTTP/3 "PUSH_PROMISE" frame including a "Signature" header protecting 2324 the ":method" and ":path" (the request target), as well as the 2325 ":scheme" and ":authority" of the pseudo-request: 2327 :method: GET 2328 :scheme: https 2329 :path: /files/example.txt 2330 :authority: example.org 2331 signature: keyId="https://example.org/mcast-sender.example.org.pem", 2332 algorithm=rsa-sha256, 2333 headers="(request-target) :scheme :authority", 2334 signature="MGQCMFTaFptaM2FhgzJq2i9AaChuFDHjp6GiXVtRnI8BsA" 2336 HTTP/3 "HEADERS" frame including a "Signature" header protecting the 2337 ":method", ":path", ":scheme" and ":authority" of the pseudo-request 2338 above, plus the "Date" and "Digest" of the response: 2340 :status: 200 2341 content-length: 100 2342 content-type: text/plain 2343 date: Fri, 20 Jan 2017 10:00:00 GMT 2344 digest: SHA-256=DieQ9zfRaDdyAilTVCvmBePuxMm+B6cNocP+QCrNSqo= 2345 signature: keyId="https://example.org/mcast-sender.example.org.pem", 2346 algorithm=rsa-sha256, 2347 headers="(request-target) :scheme :authority date digest", 2348 signature="MGUCMBgx6cuwTzg0W29zNUra8xfMsEcb3rFA3Y" 2350 HTTP/3 "DATA" frame containing response body data: 2352 ... 2354 B.2.6. Partial Transfer with Content Integrity and Authenticity 2356 In this example, partial content is transferred and the "Range" 2357 header (as described in Section 8) is used to indicate that 50 bytes 2358 out of 100 bytes were transferred. Content integrity is provided by 2359 the inclusion of the "Digest" header, as described in Section 6.1. 2360 Authenticity is provided by the "Signature" header which protects the 2361 header fields described in further detail. The "Signature" header 2362 parameter "keyId" contains the URL of a file containing the public 2363 key related to the multicast sender's private key used to create the 2364 digital signature. 2366 HTTP/3 "PUSH_PROMISE" frame: 2368 :method: GET 2369 :scheme: https 2370 :path: /files/example.txt 2371 :authority: example.org 2372 range: bytes=0-* 2373 signature: keyId="https://example.org/mcast-sender.example.org.pem", 2374 algorithm=rsa-sha256, 2375 headers="(request-target) :scheme :authority range", 2376 signature="MGQCMFTaFptaM2FhgzJq2i9AaChuFDHjp6GiXVtRnI8BsA" 2378 HTTP/3 "HEADERS" frame protecting the ":method", ":path", ":scheme" 2379 and ":authority" of the pseudo-request above, plus the "Date", 2380 "Digest" and "Content-Range" of the response: 2382 :status: 206 2383 content-length: 100 2384 content-range: bytes 0-49/100 2385 content-type: text/plain 2386 date: Fri, 20 Jan 2017 10:00:00 GMT 2387 digest: SHA-256=DieQ9zfRaDdyAilTVCvmBePuxMm+B6cNocP+QCrNSqo= 2388 signature: keyId="https://example.org/mcast-sender.example.org.pem", 2389 algorithm=rsa-sha256, 2390 headers="(request-target) :scheme :authority 2391 date digest content-range", 2392 signature="MGUCMBgx6cuwTzg0W29zNUra8xfMsEcb3rFA3Y" 2394 HTTP/3 "DATA" frame containing response body data: 2396 ... 2398 Appendix C. Summary of differences from unicast QUIC and HTTP/3 2400 +================+=======================+=========================+ 2401 | Protocol | Unicast QUIC | Multicast QUIC profile | 2402 | feature | | | 2403 +================+=======================+=========================+ 2404 | Packet number | QUIC transport | All packets are | 2405 | spaces | packets are seperated | numbered in the | 2406 | | into three distinct | application data packet | 2407 | | packet number spaces: | number space. | 2408 | | initial, handshake | | 2409 | | and application data. | | 2410 +----------------+-----------------------+-------------------------+ 2411 | Transport | Combined | Not used. | 2412 | handshake | cryptographic and | | 2413 | | transport handshake | | 2414 | | stream conveying TLS | | 2415 | | handshake messages in | | 2416 | | QUIC Initial and | | 2417 | | Handshake packets. | | 2418 +----------------+-----------------------+-------------------------+ 2419 | TLS cipher | Client's preferred | Cipher suite optionally | 2420 | suite | cipher suite included | advertised out of band | 2421 | | in Client Hello | via Alt-Svc "cipher- | 2422 | | message. | suite" parameter. | 2423 | | | Default cipher suite is | 2424 | | | "0x00,0x00 | 2425 | | | (NULL_WITH_NULL_NULL)". | 2426 +----------------+-----------------------+-------------------------+ 2427 | TLS session | Session key included | Session key optionally | 2428 | key | in Server Hello | advertised out of band | 2429 | | message. | via Alt-Svc "key" | 2430 | | | parameter. | 2431 +----------------+-----------------------+-------------------------+ 2432 | TLS | Initialization vector | Initialization vector | 2433 | initialization | included in Server | optionally advertised | 2434 | vector | Hello message. | out of band via Alt-Svc | 2435 | | | "iv" parameter. | 2436 +----------------+-----------------------+-------------------------+ 2438 Table 1: Cryptography and Transport 2440 +=====================================+===============+=============+ 2441 | Protocol feature |Unicast QUIC |Multicast | 2442 | | |QUIC profile | 2443 +=====================================+===============+=============+ 2444 | initial_max_data |Connection- |Not used. | 2445 | |level flow |Peak flow | 2446 | |control window |rate of a | 2447 | |size. |session | 2448 | | |optionally | 2449 | | |advertised | 2450 | | |out of band | 2451 | | |via Alt-Svc | 2452 | | |"peak-flow- | 2453 | | |rate" | 2454 | | |parameter. | 2455 +-------------------------------------+---------------+-------------+ 2456 | initial_max_stream_data_bidi_local |Locally- |Not used. No| 2457 | |initiated |bidirectional| 2458 | |bidirectional |streams in | 2459 | |stream flow |this profile.| 2460 | |control window | | 2461 | |size. | | 2462 +-------------------------------------+---------------+-------------+ 2463 | initial_max_stream_data_bidi_remote |Remotely- |Not used. No| 2464 | |initiated |bidirectional| 2465 | |bidirectional |streams in | 2466 | |stream flow |this profile.| 2467 | |control window | | 2468 | |size. | | 2469 +-------------------------------------+---------------+-------------+ 2470 | initial_max_stream_data_uni |Unidirectional |Not used. | 2471 | |stream flow |Peak flow | 2472 | |control window |rate of a | 2473 | |size. |session | 2474 | | |optionally | 2475 | | |advertised | 2476 | | |out of band | 2477 | | |via Alt-Svc | 2478 | | |"peak-flow- | 2479 | | |rate | 2480 | | |parameter". | 2481 +-------------------------------------+---------------+-------------+ 2482 | "initial_max_streams_bidi" and |Maximum stream |Not used. | 2483 | "initial_max_streams_uni" |concurrency. |Maximum | 2484 | | |concurrent | 2485 | | |resources in | 2486 | | |a session | 2487 | | |optionally | 2488 | | |advertised | 2489 | | |out of band | 2490 | | |via Alt-Svc | 2491 | | |"max- | 2492 | | |concurrent- | 2493 | | |resources" | 2494 | | |parameter. | 2495 +-------------------------------------+---------------+-------------+ 2497 Table 2: Required Transport Parameters 2499 +====================================+=================+============+ 2500 | Protocol feature |Unicast QUIC |Multicast | 2501 | | |QUIC profile| 2502 +====================================+=================+============+ 2503 | original_destination_connection_id |The value of the |Not used. | 2504 | |Destination |No client | 2505 | |Connection ID |interaction.| 2506 | |field from the | | 2507 | |first Initial | | 2508 | |packet sent by | | 2509 | |the client. | | 2510 +------------------------------------+-----------------+------------+ 2511 | max_idle_timeout |How long to keep |Not used. | 2512 | |an idle |Advertised | 2513 | |connection open |out of band | 2514 | |for before |via Alt-Svc | 2515 | |closing. Takes a|"session- | 2516 | |default of 0 |idle- | 2517 | |(never close on |timeout" | 2518 | |idle) if not |parameter; | 2519 | |specified. |defaults to | 2520 | | |0 (never | 2521 | | |close on | 2522 | | |idle) if not| 2523 | | |specified. | 2524 +------------------------------------+-----------------+------------+ 2525 | stateless_reset_token |Used in verifying|Not used. | 2526 | |a stateless |Stateless | 2527 | |reset. |reset is not| 2528 | | |used by this| 2529 | | |profile. | 2530 +------------------------------------+-----------------+------------+ 2531 | max_udp_payload_size |Limit of the size|Not used. | 2532 | |of packets that |Maximum | 2533 | |an endpoint is |packet size | 2534 | |willing to |for a | 2535 | |receive. |session | 2536 | | |optionally | 2537 | | |advertised | 2538 | | |out of band | 2539 | | |via Alt-Svc | 2540 | | |"max-packet-| 2541 | | |size" | 2542 | | |parameter. | 2543 +------------------------------------+-----------------+------------+ 2544 | ack_delay_exponent |The exponent used|Not used. | 2545 | |to decode the ACK|"ACK" frames| 2546 | |Delay field in |are | 2547 | |the "ACK" frame. |prohibited | 2548 | | |by this | 2549 | | |profile. | 2550 +------------------------------------+-----------------+------------+ 2551 | max_ack_delay |Maximum time in |Not used. | 2552 | |milliseconds by |"ACK" frames| 2553 | |which an endpoint|are | 2554 | |will delay |prohibited | 2555 | |sending |by this | 2556 | |acknowledgements.|profile. | 2557 +------------------------------------+-----------------+------------+ 2558 | disable_active_migration |Signals if an |Not used. | 2559 | |endpoint does not|Session | 2560 | |support |migration | 2561 | |connection |not | 2562 | |migration. |currently | 2563 | | |supported by| 2564 | | |this | 2565 | | |profile. | 2566 +------------------------------------+-----------------+------------+ 2567 | preferred_address |Used to effect a |Not used. | 2568 | |change in server |No handshake| 2569 | |address at the |in this | 2570 | |end of the |profile. | 2571 | |handshake. | | 2572 +------------------------------------+-----------------+------------+ 2573 | active_connection_id_limit | |Not used. | 2574 | | |Only a | 2575 | | |single | 2576 | | |session | 2577 | | |identifier | 2578 | | |is used in | 2579 | | |this | 2580 | | |profile. | 2581 +------------------------------------+-----------------+------------+ 2582 | initial_source_connection_id |The value that an|Not used. | 2583 | |endpoint included|No client | 2584 | |in the Source |interaction.| 2585 | |Connection ID | | 2586 | |field of the | | 2587 | |first Initial | | 2588 | |packet it sent | | 2589 | |for the | | 2590 | |connection | | 2591 +------------------------------------+-----------------+------------+ 2592 | retry_source_connection_id |The value that |Not used. | 2593 | |the server |Retry | 2594 | |included in the |packets are | 2595 | |Source Connection|not used in | 2596 | |ID field of a |this | 2597 | |retry packet |profile. | 2598 +------------------------------------+-----------------+------------+ 2600 Table 3: Optional Transport Parameters 2602 +=============+=====================+===============================+ 2603 | Protocol | Unicast QUIC | Multicast QUIC profile | 2604 | feature | | | 2605 +=============+=====================+===============================+ 2606 | Maximum | Determined by path | Determined by path MTU | 2607 | packet size | MTU discovery or | discovery or other | 2608 | | other heuristic. | heuristic. | 2609 +-------------+---------------------+-------------------------------+ 2610 | Long header | Used for packets | Prohibited. | 2611 | packet | that are sent prior | | 2612 | | to the completion | | 2613 | | of version | | 2614 | | negotiation and | | 2615 | | before packet | | 2616 | | protection keys are | | 2617 | | established. | | 2618 +-------------+---------------------+-------------------------------+ 2619 | Version | Protocol version | Not permitted. | 2620 | negotiation | negotiation between | | 2621 | packet | initiating client | | 2622 | | and server. | | 2623 +-------------+---------------------+-------------------------------+ 2624 | Stateless | Used by a peer to | Not permitted. (Potential | 2625 | reset | terminate a | denial-of-service attack | 2626 | packet | connection that has | vector.) | 2627 | | become unusable. | | 2628 +-------------+---------------------+-------------------------------+ 2629 | Short | Used for packets | Used to convey QUIC frames | 2630 | header | that are sent once | (see below). | 2631 | packet | a connection has | | 2632 | | been established. | | 2633 | | Used to convey QUIC | | 2634 | | frames (see below). | | 2635 +-------------+---------------------+-------------------------------+ 2636 | Source | Connection IDs | Source Connection ID not | 2637 | Connection | negotiated between | used. Destination | 2638 | ID field, | client and server | Connection ID redefined to | 2639 | Destination | during handshake | be a Multicast Session ID | 2640 | Connection | and may be changed | which is optionally | 2641 | ID field | subsequently using | advertised out of band via | 2642 | | the | the Alt-Svc "session-id" | 2643 | | "NEW_CONNECTION_ID" | parameter. May be omitted | 2644 | | frame. | from packets if the | 2645 | | | address/port tuple is | 2646 | | | sufficient to identify the | 2647 | | | session, in which case it | 2648 | | | is not advertised. | 2649 +-------------+---------------------+-------------------------------+ 2651 Table 4: QUIC Packet Layer 2653 +========================+======================+===================+ 2654 | Protocol feature | Unicast QUIC | Multicast QUIC | 2655 | | | profile | 2656 +========================+======================+===================+ 2657 | "PADDING" frame | Used to pad out a | Permitted, but | 2658 | | QUIC packet with | wasteful of | 2659 | | zero bytes. (The | network capacity. | 2660 | | first packet sent | | 2661 | | on a connection | | 2662 | | must be at least | | 2663 | | 1200 bytes long to | | 2664 | | prove that the | | 2665 | | network can | | 2666 | | transmit packets | | 2667 | | of at least this | | 2668 | | size.) | | 2669 +------------------------+----------------------+-------------------+ 2670 | "PING" frame | Used by an | Used by the | 2671 | | endpoint to verify | multicast sender | 2672 | | that its peer is | as a session | 2673 | | still alive. | keep-alive | 2674 | | Acknowledged using | notification. | 2675 | | a regular "ACK" | Never | 2676 | | frame. | acknowledged. | 2677 +------------------------+----------------------+-------------------+ 2678 | "ACK" frames | Used by a receiver | Both "ACK" frame | 2679 | | to acknowledge | types are | 2680 | | receipt of data | prohibited. | 2681 | | from its peer. | | 2682 +------------------------+----------------------+-------------------+ 2683 | "RESET_STREAM" frame | Request by | Indication to | 2684 | | receiver for | receivers that | 2685 | | sender to | the multicast | 2686 | | terminate a stream | sender has | 2687 | | transmission | prematurely | 2688 | | prematurely. | terminated a | 2689 | | | stream | 2690 | | | transmission. | 2691 | | | Prohibited for | 2692 | | | receivers to | 2693 | | | send. | 2694 +------------------------+----------------------+-------------------+ 2695 | "STOP_SENDING" frame | Flow control back | Prohibited. | 2696 | | pressure. Used to | | 2697 | | signal to a peer | | 2698 | | that incoming data | | 2699 | | on a stream is | | 2700 | | being discarded on | | 2701 | | receipt at the | | 2702 | | application's | | 2703 | | request. This | | 2704 | | abruptly | | 2705 | | terminates a | | 2706 | | stream. | | 2707 +------------------------+----------------------+-------------------+ 2708 | "CRYPTO" frame | Used to transmit | Prohibited. | 2709 | | cryptographic | | 2710 | | handshake | | 2711 | | messages. | | 2712 +------------------------+----------------------+-------------------+ 2713 | "NEW_TOKEN" frame | Used by a server | Prohibited. | 2714 | | to supply a token | Session migration | 2715 | | to its client to | not currently | 2716 | | be sent in the | supported by this | 2717 | | header of an | profile. | 2718 | | initial packet for | | 2719 | | a future | | 2720 | | connection. Used | | 2721 | | to facilitate | | 2722 | | connection | | 2723 | | migration. | | 2724 +------------------------+----------------------+-------------------+ 2725 | "STREAM" frame | Conveys | Conveys | 2726 | | application-layer | application-layer | 2727 | | payloads (see | payloads (see | 2728 | | HTTP/3 mapping | HTTP/3 mapping | 2729 | | below). | below). | 2730 +------------------------+----------------------+-------------------+ 2731 | "FIN" bit on "STREAM" | Indication by | Indication by the | 2732 | frame | sender to its peer | multicast sender | 2733 | | that a stream | that a stream | 2734 | | transmission has | transmission has | 2735 | | finished. | finished. | 2736 +------------------------+----------------------+-------------------+ 2737 | "MAX_DATA" frame | Flow control | Prohibited. | 2738 | | update | | 2739 | | notification. | | 2740 +------------------------+----------------------+-------------------+ 2741 | "MAX_STREAM_DATA" | Flow control | Prohibited. | 2742 | frame | update | | 2743 | | notification. | | 2744 +------------------------+----------------------+-------------------+ 2745 | "MAX_STREAMS" frame | Used by an | Prohibited. | 2746 | | endpoint to inform | | 2747 | | a peer of the | | 2748 | | maximum stream ID | | 2749 | | that it is | | 2750 | | permitted to open. | | 2751 +------------------------+----------------------+-------------------+ 2752 | "DATA_BLOCKED" frame | Notification to | Prohibited. | 2753 | | receiver that | | 2754 | | sender's | | 2755 | | transmission is | | 2756 | | blocked pending an | | 2757 | | update to its flow | | 2758 | | control window by | | 2759 | | peer. | | 2760 +------------------------+----------------------+-------------------+ 2761 | "STREAM_DATA_BLOCKED" | Notification to | Prohibited. | 2762 | frame | receiver that | | 2763 | | sender's | | 2764 | | transmission of a | | 2765 | | single stream is | | 2766 | | blocked pending an | | 2767 | | update to its flow | | 2768 | | control window by | | 2769 | | peer. | | 2770 +------------------------+----------------------+-------------------+ 2771 | "STREAMS_BLOCKED" | Notification to | Prohibited. | 2772 | frames | receiver that the | | 2773 | | sender wishes to | | 2774 | | open a stream but | | 2775 | | is unable to do so | | 2776 | | because the | | 2777 | | maximum stream ID | | 2778 | | has been reached | | 2779 | | for a given stream | | 2780 | | type. | | 2781 +------------------------+----------------------+-------------------+ 2782 | "NEW_CONNECTION_ID" | Used to provide a | Prohibited. | 2783 | frame | peer with | Session migration | 2784 | | alternative | not currently | 2785 | | connection IDs | supported by this | 2786 | | that can be used | profile. | 2787 | | to break | | 2788 | | linkability when | | 2789 | | migrating | | 2790 | | connections. | | 2791 +------------------------+----------------------+-------------------+ 2792 | "RETIRE_CONNECTION_ID" | Indicates that an | Prohibited. | 2793 | frame | endpoint will no | Session migration | 2794 | | longer use a | not currently | 2795 | | connection ID that | supported by this | 2796 | | was issued by its | profile. | 2797 | | peer. | | 2798 +------------------------+----------------------+-------------------+ 2799 | "PATH_CHALLENGE" frame | Used to check | Prohibited. | 2800 | | reachability to a | | 2801 | | peer and for path | | 2802 | | validation during | | 2803 | | connection | | 2804 | | migration. | | 2805 +------------------------+----------------------+-------------------+ 2806 | "PATH_RESPONSE" frame | Sent in response | Prohibited. | 2807 | | to a | | 2808 | | "PATH_CHALLENGE" | | 2809 | | frame. | | 2810 +------------------------+----------------------+-------------------+ 2811 | "CONNECTION_CLOSE" | Notification (by | Prohibited. Use | 2812 | frame | either peer) of | HTTP explicit | 2813 | | graceful | session tear-down | 2814 | | connection | instead (see | 2815 | | shutdown. | Section 5.4). | 2816 +------------------------+----------------------+-------------------+ 2817 | "HANDSHAKE_DONE" frame | Used by a server | Prohibited. | 2818 | | to inform a client | | 2819 | | that the | | 2820 | | cryptographic | | 2821 | | handshake has | | 2822 | | completed. | | 2823 +------------------------+----------------------+-------------------+ 2825 Table 5: QUIC Framing Layer 2827 +================+================+================================+ 2828 | Protocol | Unicast HTTP/3 | Multicast HTTP/3 profile | 2829 | feature | | | 2830 +================+================+================================+ 2831 | Stream Type | Type of | Only Server Push type is | 2832 | | unidirectional | permitted. | 2833 | | stream. | | 2834 +----------------+----------------+--------------------------------+ 2835 | Push ID | Identifies a | Identifies a promised resource | 2836 | | promised | conveyed in an earlier | 2837 | | resource | "PUSH_PROMISE" frame. | 2838 | | conveyed in an | | 2839 | | earlier | | 2840 | | "PUSH_PROMISE" | | 2841 | | frame. | | 2842 +----------------+----------------+--------------------------------+ 2843 | "DATA" frame | Carriage of | Carriage of HTTP response | 2844 | | HTTP request/ | message body. | 2845 | | response | | 2846 | | message body. | | 2847 +----------------+----------------+--------------------------------+ 2848 | "HEADERS" | Carriage of | Carriage of HTTP response | 2849 | frame | HTTP request/ | message metadata. Trailing | 2850 | | response | "HEADERS" frame is permitted. | 2851 | | message | | 2852 | | metadata. | | 2853 | | Trailing | | 2854 | | "HEADERS" | | 2855 | | frame is | | 2856 | | permitted. | | 2857 +----------------+----------------+--------------------------------+ 2858 | "CANCEL_PUSH" | Used to | Permitted only for senders. | 2859 | frame | request | | 2860 | | cancellation | | 2861 | | of server push | | 2862 | | prior to the | | 2863 | | push stream | | 2864 | | being created. | | 2865 +----------------+----------------+--------------------------------+ 2866 | "SETTINGS" | Negotiation of | Prohibited. | 2867 | frame | HTTP/3 | | 2868 | | connection | | 2869 | | settings. | | 2870 +----------------+----------------+--------------------------------+ 2871 | "PUSH_PROMISE" | Carriage of | Carriage of HTTP pseudo- | 2872 | frame | HTTP pseudo- | request message metadata. All | 2873 | | request | HTTP representation transfers | 2874 | | message | over multicast begin this way. | 2875 | | metadata. | Stream ID of the first client- | 2876 | | | initiated bidirectional stream | 2877 | | | is reserved and all | 2878 | | | "PUSH_PROMISE" frames | 2879 | | | reference this as the client | 2880 | | | request from which they are | 2881 | | | notionally derived. This | 2882 | | | stream remains open while a | 2883 | | | sender is participating in the | 2884 | | | multicast QUIC session. | 2885 +----------------+----------------+--------------------------------+ 2886 | "GOAWAY" frame | Early | Prohibited. Use HTTP explicit | 2887 | | notification | session tear-down instead. | 2888 | | (by either | | 2889 | | endpoint) of | | 2890 | | future | | 2891 | | connection | | 2892 | | closure, | | 2893 | | allowing for | | 2894 | | orderly | | 2895 | | completion of | | 2896 | | open streams. | | 2897 +----------------+----------------+--------------------------------+ 2898 | "MAX_PUSH_ID" | Used by a | Prohibited. | 2899 | frame | receiver to | | 2900 | | control the | | 2901 | | number of | | 2902 | | server pushes | | 2903 | | that a sender | | 2904 | | can initiate. | | 2905 +----------------+----------------+--------------------------------+ 2906 | "ALTSVC" | Signalling | Prohibited. | 2907 | HTTP/2 | alternative | | 2908 | extension | service for | | 2909 | frame | HTTP/3 | | 2910 | | session. | | 2911 +----------------+----------------+--------------------------------+ 2912 | Other HTTP/2 | | Prohibited. | 2913 | extension | | | 2914 | frames | | | 2915 +----------------+----------------+--------------------------------+ 2917 Table 6: HTTP/3 Mapping 2919 +=============+=============================+==================+ 2920 | Protocol | Unicast HTTP/3 | Multicast HTTP/3 | 2921 | feature | | profile | 2922 +=============+=============================+==================+ 2923 | Huffman | Header blocks may use | Header blocks | 2924 | string | Huffman codes to compress | may use Huffman | 2925 | compression | literal string values. | codes to | 2926 | | | compress literal | 2927 | | | string values. | 2928 +-------------+-----------------------------+------------------+ 2929 | Static | Header blocks may refer to | Header blocks | 2930 | table | indexed entries in the | may refer to | 2931 | | static table. | indexed entries | 2932 | | | in the static | 2933 | | | table. | 2934 +-------------+-----------------------------+------------------+ 2935 | Dynamic | Header blocks may insert | Prohibited, size | 2936 | table | entries into the dynamic | is currently | 2937 | | table and subsequent header | locked to 0. | 2938 | | blocks may refer to their | | 2939 | | indexes. Unused as size is | | 2940 | | currently locked to 0. | | 2941 +-------------+-----------------------------+------------------+ 2943 Table 7: HTTP Metadata Compression Layer 2945 Appendix D. Changelog 2947 *RFC Editor's Note:* Please remove this section prior to 2948 publication of a final version of this document. 2950 D.1. Since draft-pardue-quic-http-mcast-08 2952 * Update references to QUIC WG I-Ds to [RFC9000], [RFC9001] and 2953 [RFC9002]. 2955 * Update reference to DATA_WITH_OFFSET frame draft. 2957 D.2. Since draft-pardue-quic-http-mcast-07 2959 * Update references to QUIC WG I-Ds. 2961 * Remove stale references to sections of the QUIC WG I-Ds that don't 2962 exist any more. 2964 * Add references to the DATA_WITH_OFFSET frame I-D. 2966 D.3. Since draft-pardue-quic-http-mcast-06 2968 * Update references to QUIC WG I-Ds. 2970 * Clarify that only the first source-address parameter should be 2971 used if duplicated. 2973 * Fix source-address example to not be a quoted string. 2975 * Fix bytes in the ALPN identification sequence following change to 2976 h3m. 2978 * Update language around QUIC Connection IDs to reflect the core 2979 specs. 2981 * Update frame and transport parameter names throughout to match 2982 core specifications. 2984 * Remove Author's Note about reserved stream ID for "PUSH_PROMISE" 2985 frames. 2987 * Update language around QPACK static and dynamic table indexing to 2988 more closely align with the core spec. 2990 * Update Session Idle Timeout to match core specs, including 2991 removing limitation of 600 seconds and expressing in milliseconds, 2992 not seconds. 2994 * Preface Session Termination with a statement clarifying that 2995 participants may leave at any time. 2997 D.4. Since draft-pardue-quic-http-mcast-05 2999 * Update references to QUIC WG I-Ds. 3001 * Sender packet number size is now fixed for the duration of a 3002 session. 3004 * Change how to handle multiple session IDs: sessions are now only 3005 allowed a single ID. 3007 * Remove incompatible requirements set by [RFC9000]'s "Required 3008 Operations". 3010 * Additionally ban "HANDSHAKE_DONE". 3012 * Remove Version Negotiation now that the "quic" Alt-Svc parameter 3013 has been removed (examples also updated). 3015 * Remove HTTP Prioritization references. 3017 * Add new "extensions" Alt-Svc parameter. 3019 * Broaden peak flow rate to QUIC payload to encompass all frame 3020 types. 3022 * Change ALPN identifier to h3m. 3024 D.5. Since draft-pardue-quic-http-mcast-04 3026 * Update references to QUIC WG I-Ds, remove QUIC-SPIN. (draft-ietf- 3027 quic-transport-20) 3029 * Update session ID length to match new connection ID length. 3030 (draft-ietf-quic-transport-22) 3032 * Clarify the mapping for the new "active_connection_id_limit" 3033 session parameter. (draft-ietf-quic-transport-21) 3035 * Update text to conform with latest version negotiation text from 3036 [RFC9000]. 3038 * Update stream types for server push in accordance with draft-ietf- 3039 quic-http-19. 3041 * Fix some idnits warnings to do with line lengths in Alt-Svc 3042 examples. 3044 * Update IPv6 informative reference to RFC 8200 as it obsoletes RFC 3045 2460. 3047 * Clarify difference between connection and session migration. 3049 * Move GOAWAY frame to HTTP/3 profile. 3051 * Renamed Session Shutdown to Connection Shutdown to mirror concept 3052 in [RFC9000]. 3054 * Clarify the layer of each frame type when referred to. 3056 D.6. Since draft-pardue-quic-http-mcast-03 3058 * Update references to QUIC WG I-Ds. 3060 * Change crypto handshake text now that it's no longer done on 3061 Stream ID 0. 3063 * Update to reference Source and Destination Connection IDs. 3065 * Prohibit the use of connection coalescing, migration and ECN. 3067 * Update allowed and disallowed packets and frames to match the core 3068 specs. 3070 * Remove references to the PONG frame. (draft-ietf-quic-transport- 3071 10) 3073 * Change HTTP/QUIC to HTTP/3. (draft-ietf-quic-http-17) 3075 * Change HPACK to QPACK. (draft-ietf-quic-http-10) 3077 * Prohibit the DUPLICATE_PUSH frame. 3079 * Clarify packet number space (only use application data space, not 3080 initial or handshake). 3082 * Add statement on QUIC latency spin bit. 3084 * Removed sentence stating that multiple Connection IDs cannot be 3085 used concurrently in a unicast QUIC session, in accordance with 3086 [RFC9000] section 5.1.2. 3088 D.7. Since draft-pardue-quic-http-mcast-02 3090 * No changes. 3092 D.8. Since draft-pardue-quic-http-mcast-01 3094 * Explicit guidance on maximum stream ID value permitted. 3096 * Updated guidance on PING (and PONG) frame. 3098 * Added a comparison table to appendix. 3100 * Remove invalid use of trailing headers. 3102 * Use the new HTTP/QUIC DATA frame. 3104 * Prohibit APPLICATION CLOSE frame, and move GOAWAY frame to HTTP/ 3105 QUIC section. 3107 * Redefine server push to reflect core document changes. 3109 * Remove default idle time out value. 3111 * Clarify session parameter requirements (session-idle-timeout 3112 became mandatory). 3114 * Update frame notation convention. 3116 D.9. Since draft-pardue-quic-http-mcast-00 3118 * Update references to QUIC WG I-Ds. 3120 * Relax session leaving requirements language. 3122 * Clarify handling of omitted session parameter advertisements. 3124 * Rename "Idle" state to "Quiescent". 3126 * Add digest algorithm session parameter. 3128 * Add signature algorithm session parameter. 3130 * Add Initialization Vector session parameter. 3132 * Replace COPT tag-value-pairs with TransportParameter values. 3134 * Add example of an advertisement for a session with content 3135 authenticity and integrity. 3137 Authors' Addresses 3139 Lucas Pardue 3141 Email: lucaspardue.24.7@gmail.com 3143 Richard Bradbury 3144 BBC Research & Development 3146 Email: richard.bradbury@bbc.co.uk 3147 Sam Hurst 3148 BBC Research & Development 3150 Email: sam.hurst@bbc.co.uk