idnits 2.17.1 draft-pardue-quic-http-mcast-08.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 (February 18, 2021) is 1160 days in the past. Is this intentional? Checking references for intended status: Experimental ---------------------------------------------------------------------------- == Outdated reference: A later version (-02) exists of draft-hurst-quic-http-data-offset-frame-00 ** Obsolete normative reference: RFC 3230 (Obsoleted by RFC 9530) ** Obsolete normative reference: RFC 7230 (Obsoleted by RFC 9110, RFC 9112) ** Obsolete normative reference: RFC 7233 (Obsoleted by RFC 9110) ** Obsolete normative reference: RFC 7234 (Obsoleted by RFC 9111) -- Obsolete informational reference (is this intentional?): RFC 4566 (Obsoleted by RFC 8866) Summary: 4 errors (**), 0 flaws (~~), 4 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: August 22, 2021 S. Hurst 6 BBC Research & Development 7 February 18, 2021 9 Hypertext Transfer Protocol (HTTP) over multicast QUIC 10 draft-pardue-quic-http-mcast-08 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 August 22, 2021. 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 45 (https://trustee.ietf.org/license-info) in effect on the date of 46 publication of this document. Please review these documents 47 carefully, as they describe your rights and restrictions with respect 48 to this document. Code Components extracted from this document must 49 include Simplified BSD License text as described in Section 4.e of 50 the Trust Legal Provisions and are provided without warranty as 51 described in the Simplified BSD License. 53 Table of Contents 55 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 4 56 1.1. Notational Conventions . . . . . . . . . . . . . . . . . 6 57 1.2. Definitions . . . . . . . . . . . . . . . . . . . . . . . 6 58 2. Multicast QUIC Sessions . . . . . . . . . . . . . . . . . . . 7 59 2.1. Session States . . . . . . . . . . . . . . . . . . . . . 8 60 2.1.1. Session Establishment . . . . . . . . . . . . . . . . 8 61 2.1.2. Session Termination . . . . . . . . . . . . . . . . . 9 62 2.1.3. Session Migration . . . . . . . . . . . . . . . . . . 9 63 2.2. Session Parameters . . . . . . . . . . . . . . . . . . . 9 64 2.3. Session Identification . . . . . . . . . . . . . . . . . 10 65 2.4. Session Security . . . . . . . . . . . . . . . . . . . . 11 66 3. Session Advertisement . . . . . . . . . . . . . . . . . . . . 11 67 3.1. Security Context . . . . . . . . . . . . . . . . . . . . 12 68 3.1.1. Cipher Suite . . . . . . . . . . . . . . . . . . . . 12 69 3.1.2. Key Exchange . . . . . . . . . . . . . . . . . . . . 13 70 3.1.3. Initialization Vector . . . . . . . . . . . . . . . . 13 71 3.2. Session Identification . . . . . . . . . . . . . . . . . 13 72 3.3. Session Idle Timeout . . . . . . . . . . . . . . . . . . 13 73 3.4. Session Peak Flow Rate . . . . . . . . . . . . . . . . . 14 74 3.5. Resource Concurrency . . . . . . . . . . . . . . . . . . 15 75 3.6. Additional TransportParameter Considerations . . . . . . 15 76 3.7. Digest Algorithm . . . . . . . . . . . . . . . . . . . . 16 77 3.8. Signature Algorithm . . . . . . . . . . . . . . . . . . . 17 78 4. QUIC Profile . . . . . . . . . . . . . . . . . . . . . . . . 18 79 4.1. Packet Size . . . . . . . . . . . . . . . . . . . . . . . 18 80 4.2. Packet Format . . . . . . . . . . . . . . . . . . . . . . 18 81 4.2.1. Packet Numbers . . . . . . . . . . . . . . . . . . . 18 82 4.2.2. Spin Bit . . . . . . . . . . . . . . . . . . . . . . 19 83 4.3. Connection Identifier . . . . . . . . . . . . . . . . . . 19 84 4.4. Stream Identifier . . . . . . . . . . . . . . . . . . . . 19 85 4.5. Flow Control . . . . . . . . . . . . . . . . . . . . . . 19 86 4.6. Stream Termination . . . . . . . . . . . . . . . . . . . 20 87 4.7. Connection Shutdown . . . . . . . . . . . . . . . . . . . 20 88 4.8. Connection Migration . . . . . . . . . . . . . . . . . . 20 89 4.9. Explicit Congestion Notification . . . . . . . . . . . . 21 90 4.10. Session Keep-alive . . . . . . . . . . . . . . . . . . . 21 91 4.11. Loss Detection and Recovery . . . . . . . . . . . . . . . 21 92 4.12. Prohibited QUIC Frames and Packets . . . . . . . . . . . 22 93 5. HTTP/3 Profile . . . . . . . . . . . . . . . . . . . . . . . 22 94 5.1. HTTP Connection Settings . . . . . . . . . . . . . . . . 23 95 5.2. Server Push . . . . . . . . . . . . . . . . . . . . . . . 23 96 5.3. Metadata Compression . . . . . . . . . . . . . . . . . . 24 97 5.4. Session Tear-down . . . . . . . . . . . . . . . . . . . . 24 98 5.5. Effects of Packet Loss . . . . . . . . . . . . . . . . . 24 99 5.6. HTTP/3 Extension frames . . . . . . . . . . . . . . . . . 25 100 5.7. Prohibited HTTP/3 Frames . . . . . . . . . . . . . . . . 25 101 6. Application-Layer Security . . . . . . . . . . . . . . . . . 26 102 6.1. Content Integrity . . . . . . . . . . . . . . . . . . . . 26 103 6.2. Content Authenticity . . . . . . . . . . . . . . . . . . 26 104 6.3. Content Confidentiality . . . . . . . . . . . . . . . . . 28 105 7. Loss Recovery . . . . . . . . . . . . . . . . . . . . . . . . 28 106 7.1. Forward Error Correction . . . . . . . . . . . . . . . . 28 107 7.2. Unicast Repair . . . . . . . . . . . . . . . . . . . . . 28 108 8. Transmission of Partial Content . . . . . . . . . . . . . . . 29 109 9. Protocol Identifier . . . . . . . . . . . . . . . . . . . . . 29 110 9.1. Draft Version Identification . . . . . . . . . . . . . . 29 111 10. Discovery of Multicast QUIC Sessions . . . . . . . . . . . . 30 112 10.1. Source-specific Multicast Advertisement . . . . . . . . 31 113 10.2. Session Parameter Advertisement . . . . . . . . . . . . 31 114 10.2.1. Cipher Suite . . . . . . . . . . . . . . . . . . . . 31 115 10.2.2. Session Key . . . . . . . . . . . . . . . . . . . . 32 116 10.2.3. Session Cipher Initialization Vector . . . . . . . . 32 117 10.2.4. Session Identification . . . . . . . . . . . . . . . 32 118 10.2.5. Session Idle Timeout Period . . . . . . . . . . . . 33 119 10.2.6. Resource Concurrency . . . . . . . . . . . . . . . . 33 120 10.2.7. Session Peak Flow Rate . . . . . . . . . . . . . . . 33 121 10.2.8. Digest Algorithm . . . . . . . . . . . . . . . . . . 34 122 10.2.9. Signature Algorithm . . . . . . . . . . . . . . . . 34 123 10.2.10. Extensions . . . . . . . . . . . . . . . . . . . . . 35 124 11. Security Considerations . . . . . . . . . . . . . . . . . . . 35 125 11.1. Pervasive Monitoring . . . . . . . . . . . . . . . . . . 35 126 11.1.1. Large-scale Data Gathering and Correlation . . . . . 36 127 11.1.2. Changing Content . . . . . . . . . . . . . . . . . . 36 128 11.2. Protection of Discovery Mechanism . . . . . . . . . . . 36 129 11.3. Spoofing . . . . . . . . . . . . . . . . . . . . . . . . 37 130 11.3.1. Sender Spoofing . . . . . . . . . . . . . . . . . . 37 131 11.4. Replay Attacks . . . . . . . . . . . . . . . . . . . . . 37 132 11.5. Message Deletion . . . . . . . . . . . . . . . . . . . . 37 133 11.6. Denial of Service . . . . . . . . . . . . . . . . . . . 38 134 11.6.1. Unprotected Frames and Packets . . . . . . . . . . . 38 135 11.6.2. Network Performance Degradation . . . . . . . . . . 38 136 11.6.3. Unicast Repair Stampeding Herd . . . . . . . . . . . 38 137 11.7. Receiver Resource Usage . . . . . . . . . . . . . . . . 38 138 11.8. Unicast Repair Information Leakage . . . . . . . . . . . 39 139 12. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 39 140 12.1. Registration of Protocol Identification String . . . . . 39 141 12.2. Registration of Alt-Svc parameters . . . . . . . . . . . 40 142 12.2.1. Source Address . . . . . . . . . . . . . . . . . . . 40 143 12.2.2. Cipher Suite . . . . . . . . . . . . . . . . . . . . 40 144 12.2.3. Key . . . . . . . . . . . . . . . . . . . . . . . . 40 145 12.2.4. Initialization Vector . . . . . . . . . . . . . . . 40 146 12.2.5. Session Identifier . . . . . . . . . . . . . . . . . 40 147 12.2.6. Session Idle Timeout . . . . . . . . . . . . . . . . 40 148 12.2.7. Maximum Concurrent Resources . . . . . . . . . . . . 41 149 12.2.8. Peak Flow Rate . . . . . . . . . . . . . . . . . . . 41 150 12.2.9. Digest Algorithm . . . . . . . . . . . . . . . . . . 41 151 12.2.10. Signature Algorithm . . . . . . . . . . . . . . . . 41 152 12.2.11. Extension . . . . . . . . . . . . . . . . . . . . . 41 153 13. References . . . . . . . . . . . . . . . . . . . . . . . . . 41 154 13.1. Normative References . . . . . . . . . . . . . . . . . . 41 155 13.2. Informative References . . . . . . . . . . . . . . . . . 43 156 Appendix A. Acknowledgements . . . . . . . . . . . . . . . . . . 45 157 Appendix B. Examples . . . . . . . . . . . . . . . . . . . . . . 45 158 B.1. Session Advertisement . . . . . . . . . . . . . . . . . . 45 159 B.1.1. Source-specific Multicast QUIC Session . . . . . . . 45 160 B.1.2. Source-specific Multicast QUIC Session with Transport 161 Encryption using a Symmetric Key . . . . . . . . . . 46 162 B.1.3. Source-specific Multicast QUIC Session with Transport 163 Encryption, Content Integrity and Authenticity . . . 46 164 B.2. Resource Transfer . . . . . . . . . . . . . . . . . . . . 47 165 B.2.1. Transfer without Content Integrity or Authenticity . 47 166 B.2.2. Transfer of Partial Content without Content Integrity 167 or Authenticity . . . . . . . . . . . . . . . . . . . 47 168 B.2.3. Transfer with Content Integrity and without 169 Authenticity . . . . . . . . . . . . . . . . . . . . 48 170 B.2.4. Partial Transfer with Content Integrity and without 171 Authenticity . . . . . . . . . . . . . . . . . . . . 48 172 B.2.5. Transfer with Content Integrity and Authenticity . . 49 173 B.2.6. Partial Transfer with Content Integrity and 174 Authenticity . . . . . . . . . . . . . . . . . . . . 50 175 Appendix C. Summary of differences from unicast QUIC and HTTP/3 51 176 Appendix D. Changelog . . . . . . . . . . . . . . . . . . . . . 62 177 D.1. Since draft-pardue-quic-http-mcast-07 . . . . . . . . . . 62 178 D.2. Since draft-pardue-quic-http-mcast-06 . . . . . . . . . . 63 179 D.3. Since draft-pardue-quic-http-mcast-05 . . . . . . . . . . 63 180 D.4. Since draft-pardue-quic-http-mcast-04 . . . . . . . . . . 64 181 D.5. Since draft-pardue-quic-http-mcast-03 . . . . . . . . . . 64 182 D.6. Since draft-pardue-quic-http-mcast-02 . . . . . . . . . . 65 183 D.7. Since draft-pardue-quic-http-mcast-01 . . . . . . . . . . 65 184 D.8. Since draft-pardue-quic-http-mcast-00 . . . . . . . . . . 66 185 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 66 187 1. Introduction 189 The means to bulk transfer resources over multicast IP [RFC1112] 190 using HTTP semantics presents an opportunity to more efficiently 191 deliver services at scale, while leveraging the wealth of existing 192 HTTP-related standards, tools and applications. Audio-visual 193 segmented media, in particular, would benefit from this mode of 194 transmission. 196 The carriage of HTTP over multicast IP may be satisfied using 197 existing technologies, for example the Real-time Transport Protocol 198 (RTP) [RFC3550], File Delivery over Unidirectional Transport (FLUTE) 199 [RFC6726], and NACK-Oriented Reliable Multicast (NORM) [RFC5740]. 200 However, such protocols typically require the translation or 201 encapsulation of HTTP. This introduces concerns for providers of 202 services, such as defining the translation, additional workload, 203 complication of workflows, manageability issues, versioning issues, 204 and so on. 206 In contrast, this document describes a simpler and more direct 207 expression of HTTP semantics over multicast IP. HTTP over multicast 208 QUIC is a profile of the QUIC protocol [QUIC-TRANSPORT] (Section 4) 209 and the HTTP/3 mapping [QUIC-HTTP] (Section 5). This includes the 210 repurposing of certain QUIC packet fields and changes to some 211 protocol procedures (e.g. prohibition of the usage of certain frame 212 types) which, in turn, change the behavioural expectations of 213 endpoints. However, the profile purposely limits the scope of change 214 in order to preserve maximum syntactic and semantic compatibility 215 with conventional QUIC. For the reader's convenience, the 216 differences between this specification and conventional QUIC are 217 summarised in Appendix C. 219 This profile prohibits the transmission of QUIC packets from receiver 220 to sender via multicast IP. The use of side-channel or out-of-band 221 feedback mechanisms is not prohibited by this specification, but is 222 out of scope and these are not considered further by the present 223 document. 225 Experience indicates that a generally available multicast deployment 226 is difficult to achieve on the Internet notwithstanding the 227 improvements that IPv6 [RFC8200] makes in this area. There is 228 evidence that discretely referenced multicast "islands" can more 229 pragmatically be deployed. Discovery of such islands by receivers, 230 as they become available, is typically difficult, however. To 231 address the problem, this document describes an HTTP-based discovery 232 mechanism that uses HTTP Alternative Services [RFC7838] to advertise 233 the existence of multicast QUIC sessions (Section 3). This provides 234 the means for multicast-capable endpoints to learn about and make use 235 of them in an opportunistic and user-imperceptible manner. This 236 mechanism results in a common HTTP application layer for both the 237 discovery and delivery of services across unicast and multicast 238 networks. This provides support for users and devices accessing 239 services over a heterogeneous network. This is a departure from 240 conventional multicast discovery technologies such as SDP [RFC4566] 241 and SAP [RFC2974]. 243 The discovery mechanism also addresses some of the issues related to 244 using QUIC over a unidirectional network association by replacing 245 connection establishment aspects that depend on a bidirectional 246 transport. 248 The present document includes a number of optional features. It is 249 anticipated that further specifications will define interoperability 250 profiles suited to particular application domains. 252 1.1. Notational Conventions 254 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 255 "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and 256 "OPTIONAL" in this document are to be interpreted as described in BCP 257 14 [RFC2119] [RFC8174] when, and only when, they appear in all 258 captials, as shown here. 260 This document uses the Augmented BNF defined in [RFC5234] and updated 261 by [RFC7405] along with the "#rule" extension defined in Section 7 of 262 [RFC7230]. The rules below are defined in [RFC5234], [RFC7230], and 263 [RFC7234]: 265 o quoted-string = 267 o token = 269 o uri-host = 271 1.2. Definitions 273 Definitions of terms that are used in this document: 275 o endpoint: A host capable of being a participant in a multicast 276 QUIC session. 278 o multicast QUIC session: A logical unidirectional flow of metadata 279 and data over multicast IP, framed according to this 280 specification. The lifetime of a session is independent of any 281 endpoint. 283 o participant: A sender or receiver that is taking part in a 284 multicast QUIC session. 286 o sender: A participant sending multicast traffic according to this 287 specification. 289 o receiver: A participant receiving multicast traffic according to 290 this specification. 292 o session: See multicast QUIC session. 294 o session ID: The identifier for a multicast QUIC session. 296 o session parameter: Characteristic of a multicast QUIC session. 298 2. Multicast QUIC Sessions 300 A QUIC connection [QUIC-TRANSPORT] carried over bidirectional unicast 301 is defined as a conversation between two QUIC endpoints that 302 multiplexes several logical streams within a single encryption 303 context. This is a one-to-one relationship. Furthermore, QUIC 304 connections achieve decoupling from the underlying network (IP and 305 port) by means of a set of Connection IDs, with each endpoint 306 generating these IDs and using them to identify the direction of 307 flow. Use of a consistent connection identifier allows QUIC 308 connections to survive changes to the network connectivity. The 309 establishment of a QUIC connection relies upon an up-front, in-band 310 exchange (and possible negotiation) of cryptographic and transport 311 parameters (conveyed in QUIC handshake messages). 313 The mapping of HTTP semantics over the QUIC transport protocol 314 [QUIC-HTTP] facilitates the transfer of hypermedia over QUIC 315 connections. The establishment of a HTTP/3 connection relies upon 316 all the requirements stipulated for the transport, as well as 317 communication of HTTP-specific settings (conveyed in HTTP/3 318 "SETTINGS" frames). Such parameters may be required or optional and 319 may be used by either endpoint to control the characteristics of 320 connection usage. 322 This concept of a connection does not suit the carriage of HTTP/3 323 over unidirectional network associations such as multicast IP. In 324 fact, there is no requirement for either endpoint (multicast sender 325 or receiver) to be in existence in order for the other to start or 326 join this one-sided conversation. The term "connection" is 327 misleading in this context; therefore we introduce an alternative 328 term "multicast QUIC session" or simply "session", which is defined 329 as the logical entity describing the characteristics of the 330 anticipated unidirectional flow of metadata and data. Such 331 characteristics are expressed as "session parameters", described in 332 Section 2.2. Advertisement of multicast QUIC sessions, specified in 333 Section 3, allows for the senders and receivers to discover a session 334 and to form multicast IP network associations that permit traffic 335 flow. 337 2.1. Session States 339 The lifecycle of a multicast QUIC session is decoupled from the 340 lifecycle of any particular endpoint. Multicast receivers or senders 341 that take part in a session are called participants. The state of a 342 session is influenced by the actions of participants. The loose 343 coupling of participants means that they are unlikely to have a 344 consistent shared view of the current state of a session. There is 345 no requirement for a participant to know the session state and the 346 present document does not define a method to explicitly determine it. 347 The definitions of session states provided below are intended to 348 assist higher-level operational treatment of sessions: 350 o Quiescent: the session has no participants and is ready to accept 351 them. 353 o Half-established: the session has a participant. 355 o Fully-established: the session has a sender and at least one 356 receiver participant. 358 o Finished: the session has ended, and there are no participants. 360 Permitted states transitions are shown in Figure 1 below. 362 The transmission of QUIC packets is expected to occur only during the 363 Half-Established and Fully-Established states. 365 +-----------+ +------------------+ +-------------------+ 366 | |-------->| |------->| | 367 | Quiescent | | Half-Established | | Fully-Established | 368 | |<--------| |<-------| | 369 +-----------+ +------------------+ +-------------------+ 370 | | 371 | v 372 | +----------+ 373 | | | 374 +------------------>| Finished | 375 | | 376 +----------+ 378 Figure 1: Multicast QUIC session states 380 2.1.1. Session Establishment 382 A session begins in the Quiescent state. A typical session 383 establishment sequence would see the transition from Quiescent to 384 Half-Established when a sender joins the session. The transition 385 from Half-Established to Fully-Established occurs when at least one 386 receiver joins the session. 388 It is equally valid for a receiver to join a session in the Quiescent 389 state, triggering the transition to Half-Established. In this case, 390 the transition to Fully-Established takes place only when a sender 391 joins the session. 393 2.1.2. Session Termination 395 Participants MAY leave a session at any time. A session enters the 396 Finished state when all participants have left it. Senders MAY 397 signal their intent to leave using explicit session tear-down 398 (Section 5.4). Receivers can detect that a sender has left via idle 399 timeout (Section 3.3) and take that as a signal to leave, or 400 receivers may leave as part of session migration (described in the 401 next section). 403 In a typical case, a session that is in the Fully-Established state 404 would be closed in two stages. In the first stage the sender sends 405 explicit shutdown messages to the multicast group and subsequently 406 stops transmitting packets. This causes the session to transition 407 from Fully-Established to Half-Established. In the second stage, 408 receivers that have received explicit shutdown messages leave the 409 multicast group. Once all receivers have left the session it 410 transitions from Half-Established to Finished. 412 The transition from Quiescent to Finished could also occur in 413 response to out-of-band actions, for example the availability of a 414 session being withdrawn without any participants having made use of 415 it. 417 2.1.3. Session Migration 419 Endpoints MAY migrate between multicast QUIC sessions (for example, 420 to make use of alternate session parameters that are preferred). 421 Session migration requires participants to leave the current session 422 and join the new session. These actions affect the state of the 423 respective sessions as explained above. 425 The discovery of multicast QUIC sessions is described in Section 3. 427 2.2. Session Parameters 429 The characteristics of multicast QUIC sessions are expressed as 430 session parameters, which cover cryptographic and transport 431 parameters, HTTP-specific settings and multicast-specific 432 configuration. 434 Session parameter exchange over IP multicast is difficult: 436 o In-band exchanges are one-way, and so the client does not have the 437 means to send session parameters. 439 o The lifecycle of any multicast sender is independent of the 440 multicast receiver. It is therefore unlikely that all receivers 441 will have joined a session in time to receive parameters sent at 442 the start of a multicast session. 444 A range of strategies exists to mitigate these points. However, each 445 has the possibility to add complexity to deployment and 446 manageability, transmission overhead, or other such concerns. This 447 document defines a solution that relies on the one-way announcement 448 of session parameters in advance of session establishment. This is 449 achieved using HTTP Alternative Services [RFC7838] and is explained 450 in Section 3. Other advertisement solutions are not prohibited but 451 are not explored in this document. 453 Session parameters MUST NOT change during the lifetime of a session. 454 This restriction also applies to HTTP-level settings (see 455 Section 5.1). 457 2.3. Session Identification 459 This document defines an optional session identifier used to identify 460 a session. This "Session ID" affords independence from multicast IP, 461 creating the possibility for a session to span multiple multicast 462 groups, or to migrate a session to a different multicast group. 463 Assignment of Session ID is considered out of this document's scope. 465 The Session ID is carried in the Destination Connection ID field of 466 the QUIC packet (see Section 4.3). Source Connection IDs are not 467 used. 469 The maximum size of a Session ID is 160 bits. The size of the 470 Destination Connection ID field used to convey the Session ID SHALL 471 be the smallest number of full bytes required to represent the full 472 Session ID value advertised in the "session-id" session parameter 473 (Section 10.2.4). If no "session-id" parameter is advertised, then 474 this session has a zero-length session ID, and the Destination 475 Connection ID field SHALL be omitted from all QUIC packets related to 476 the session. 478 A multicast sender participating in a session with an advertised 479 "session-id" session parameter MUST send QUIC packets with a matching 480 Session ID. Conversely, a multicast sender participating in a 481 session without an advertised "session-id" session parameter MUST NOT 482 send QUIC packets with a non-zero-length Destination Connection ID 483 field. 485 A multicast receiver participating in a session with an advertised 486 "session-id" session parameter MUST validate that the Session ID of 487 received QUIC packets matches that advertised in the session 488 parameters (Section 10.2.4) before any HTTP-level processing is done. 489 In the case of validation failure, the receiver SHOULD ignore the 490 packet in order to protect itself from denial-of-service attacks. 492 2.4. Session Security 494 *Authors' Note:* Security handshake (as described in WG documents) 495 is in flux. This section will track developments and will be 496 updated accordingly. 498 The QUIC cryptographic handshake ([QUIC-TRANSPORT] and [QUIC-TLS]) 499 sets out methods to achieve the goals of authenticated key exchange 500 and QUIC packet protection between two endpoints forming a QUIC 501 connection. The design facilitates low-latency connection; 1-RTT or 502 0-RTT. This specification replaces the in-band security handshake, 503 achieving similar goals through the use of session parameters 504 described in Section 3.1. 506 Integrity and authenticity concerns are addressed in Section 6.1 and 507 Section 6.2 respectively. In order to protect themselves from attack 508 vectors, endpoints SHOULD NOT participate in sessions for which they 509 cannot establish reasonable confidence over the cipher suite or key 510 in use for that session. Participants MAY leave any session that 511 fails to successfully match anticipated security characteristics. 513 3. Session Advertisement 515 In this specification, connection negotiation is replaced with a 516 session advertisement mechanism based on HTTP Alternative Services 517 (Alt-Svc) [RFC7838]. This document specifies how the parameters of a 518 multicast QUIC session are expressed as Alt-Svc parameters. The 519 following sections provide a high-level view of these; further 520 details are provided in Section 10.2, with examples provided in 521 Appendix B.1. QUIC connection parameters not defined as, or related 522 to, Alt-Svc parameters are not used. 524 The definition of a session (including the session ID and its 525 parameters) is not the responsibility of any endpoint. Rather, 526 endpoints SHOULD use session advertisements to determine if they are 527 capable of participating in a given session. This document does not 528 specify which party is responsible for defining and/or advertising 529 multicast QUIC sessions. 531 Endpoints SHOULD NOT become participants in sessions where the 532 advertisement requirements set out in the present document are 533 unfulfilled. 535 The freshness of Alt-Svc multicast QUIC session advertisements is as 536 described in section 2.2 of [RFC7838]. 538 It is RECOMMENDED that session advertisements are carried over a 539 secure transport (such as HTTPS) which can guarantee the authenticity 540 and integrity of the Alt-Svc information. This addresses some of the 541 concerns around the protection of session establishment described in 542 Section 11.2. 544 *Authors' Note:* We invite review comments on mandating the use of 545 a secure transport for advertising sessions. 547 Senders MAY also advertise the availability of alternative sessions 548 by carrying Alt-Svc in a multicast QUIC session. 550 3.1. Security Context 552 *Authors' Note:* Security handshake (as described in WG documents) 553 is in flux. This section will track developments and will be 554 updated accordingly. 556 This specification replaces the in-band security handshake. The 557 session parameters "cipher suite", "key" and "iv" (described below) 558 allow for the establishment of a security context. In order to 559 protect themselves, endpoints SHOULD NOT participate in sessions for 560 which they cannot establish reasonable confidence over the cipher 561 suite, key, or IV in use for that session. Endpoints SHOULD leave 562 any sessions which fail to successfully match anticipated security 563 characteristics. 565 3.1.1. Cipher Suite 567 Cipher suite negotiation is replaced with a "cipher suite" session 568 parameter, which is advertised as the Alt-Svc parameter "cipher- 569 suite" (Section 10.2.1). 571 The Alt-Svc "cipher-suite" parameter is OPTIONAL. If present, this 572 parameter MUST contain only one value that corresponds to an entry in 573 the TLS Cipher Suite Registry (see http://www.iana.org/assignments/ 574 tls-parameters/tls-parameters.xhtml#tls-parameters-4). Session 575 advertisements that omit this parameter imply that the session is 576 operating with cipher suite 0x00,0x00 (NULL_WITH_NULL_NULL). 578 3.1.2. Key Exchange 580 Key exchange is replaced with a "key" session parameter, which is 581 advertised as the Alt-Svc parameter "key" (Section 10.2.2). The 582 parameter carries a variable-length hex-encoded key for use with the 583 session cipher suite. 585 The Alt-Svc "key" parameter is OPTIONAL. Session advertisements that 586 omit this parameter imply that the key may be available via an out- 587 of-band method not described in this document. 589 3.1.3. Initialization Vector 591 Initialization Vector (IV) exchange is replaced with an "iv" session 592 parameter, which is advertised as the Alt-Svc parameter "iv" 593 (Section 10.2.3). The parameter carries a variable-length hex- 594 encoded IV for use with the session cipher suite and key. 596 The Alt-Svc "iv" parameter is OPTIONAL. Session advertisements that 597 omit this parameter imply that the IV may be available via an out-of- 598 band method not described in this document. 600 3.2. Session Identification 602 [QUIC-TRANSPORT] specifies how the QUIC connection identifiers are 603 used, in particular the independent selection of these identifiers by 604 each endpoint for its peer. In a unidirectional multicast 605 environment, there is no meaningful way for an endpoint to generate a 606 connection identifier for its peer to use. This document defines a 607 "session identifier" session parameter, which is advertised as the 608 Alt-Svc parameter "session-id" (Section 10.2.4). The requirements 609 for the usage of session identifiers have already been described in 610 Section 2.3. 612 The Alt-Svc "session-id" parameter is optional. Session 613 advertisements MAY contain at most one instance of a "session-id" 614 parameter. Session advertisements that identify the same Any Source 615 Multicast group {G} or Source Specific Multicast group {S,G} indicate 616 that multiple sessions are multiplexed in the same multicast group 617 and each such advertisement must carry a unique "session-id". 619 3.3. Session Idle Timeout 621 Conventional QUIC connections may be implicitly terminated following 622 a period of idleness (lack of network activity). The optional QUIC 623 TransportParameter "max_idle_timeout" provides a means for endpoints 624 to specify the timeout period. This document defines a "session idle 625 timeout" session parameter, which is advertised as the Alt-Svc 626 parameter "session-idle-timeout" (Section 10.2.5). This session 627 parameter mimics the behaviour of "max_idle_timeout", providing a 628 means for multicast QUIC sessions to define their own idle timeout 629 periods. 631 Session idle timeout may be prevented by keep-alive strategies 632 Section 4.10. 634 The Alt-Svc "session-idle-timeout" parameter is optional. Session 635 advertisements MAY contain zero or more instances of this parameter. 636 If it is repeated, the first occurrence MUST be used and subsequent 637 occurrences MUST be ignored. Session advertisements that omit the 638 "session-idle-timeout" parameter, or set it to zero never time out. 640 Receiving participants SHOULD leave multicast QUIC sessions when the 641 session idle timeout period has elapsed (Section 4.7). Leaving 642 participants MUST use the silent close method, in which no QUIC 643 "CONNECTION_CLOSE" frame is sent. 645 3.4. Session Peak Flow Rate 647 [QUIC-TRANSPORT] specifies a credit-based stream- and connection- 648 level flow control scheme which prevents a fast sender from 649 overwhelming a slow receiver at the stream level, as well as an 650 aggregate level of all streams. Window size connection parameters 651 are exchanged on connection establishment using the required QUIC 652 TransportParameters "initial_max_data", 653 "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 [QUIC-TRANSPORT] considers concurrency in terms of the number of 678 active incoming streams, which is varied by the receiving endpoint 679 adjusting the maximum Stream ID. The initial value of maximum Stream 680 ID is 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 [QUIC-TRANSPORT] defines a mechanism for endpoints 718 to show willingness to receive one or more extension frame types. It 719 is not possible for multicast QUIC receivers to signal this 720 information to 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 [QUIC-TRANSPORT]. 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 o the session does not use the content integrity mechanism, or 764 o 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 o the session does not use the content authenticity mechanism, or 803 o 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 [QUIC-TRANSPORT] is presented in this section. In 826 order to preserve compatibility with conventional QUIC, the 827 specification works with a limited scope of change. However, the 828 nature of unidirectional multicast communications means that some 829 protocol procedures or behaviours need to be modified. 831 Section 5.3 of [QUIC-TRANSPORT] defines a set of required actions 832 that a QUIC server and QUIC client must be able to perform. Due to 833 the limitations of this profile, all of the requirements in 834 Section 5.3 of [QUIC-TRANSPORT] are removed except for: 836 o Configuring the minimum and total number of permitted streams of 837 each type is described in Section 3.5. 839 o 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 [QUIC-TRANSPORT]. 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 [QUIC-TRANSPORT]. Senders must always use the same 870 number of bytes to represent the packet number for all packets sent 871 to a session. Because a receiver may join a session after the sender 872 has already sent several packets, it MUST NOT assume that the first 873 packet number will be 0. 875 4.2.2. Spin Bit 877 [QUIC-TRANSPORT] specifies a bit in the short packet header as the 878 latency spin bit that may be used to measure network round trip 879 latency between a client and a server. This mechanism is not usable 880 in a unidirectional multicast packet flow. Senders SHALL set the 881 spin bit to zero in all packets. Receivers SHOULD ignore the spin 882 bit. 884 *Authors' Note:* The authors welcome suggestions for the use of 885 the spin bit in a multicast context. 887 4.3. Connection Identifier 889 The Destination Connection ID field MUST be non-zero-length in every 890 QUIC packet if the session was advertised with a "session-id" session 891 parameter (Section 10.2.4). If the multicast QUIC session 892 advertisement does not carry a "session identifier" session 893 parameter, then the Destination Connection ID MUST be zero-length in 894 any QUIC packet for that session. In the case where multiple 895 sessions are multiplexed on the same 5-tuple network association, the 896 Destination Connection ID field MUST be non-zero-length in every QUIC 897 packet and must be distinct for each session. 899 4.4. Stream Identifier 901 The maximum Stream ID of a multicast QUIC session is 2^62, as 902 explained in Section 3.5. With the exception of the first client- 903 initiated request Stream ID, which is reserved as described in 904 Section 5.2, all Stream ID values SHALL be of the server-initiated 905 unidirectional stream type. 907 4.5. Flow Control 909 Conventional QUIC provides stream- and connection-level flow control, 910 and endpoints manage this by sending QUIC "MAX_DATA" or 911 "MAX_STREAM_DATA" frames as required. When a sender is blocked from 912 sending flow-controlled frames, it sends an informational QUIC 913 "DATA_BLOCKED" or "STREAM_DATA_BLOCKED" frame. 915 In a unidirectional environment, the sender never has a receive 916 window and the receiver cannot send in-band updates. Therefore, the 917 management of flow-control windows and transmission of blockage 918 information is not supported by this profile. The QUIC "MAX_DATA", 919 "MAX_STREAM_DATA", "DATA_BLOCKED" and "STREAM_DATA_BLOCKED" frames 920 are prohibited by this profile. Participants MUST NOT send these 921 frame types. Reception of these frame types MUST be handled as 922 described in Section 4.12. 924 4.6. Stream Termination 926 A sender MAY prematurely terminate the transmission on any unreserved 927 QUIC Stream ID by setting the "FIN" bit of a QUIC "STREAM" frame, or 928 by sending a QUIC "RESET_STREAM" frame (as specified in 929 [QUIC-TRANSPORT] and [QUIC-HTTP]). 931 Receiving participants MUST NOT make any attempt to send QUIC 932 "RESET_STREAM" frames to the multicast group. 934 4.7. Connection Shutdown 936 Explicit shutdown of a multicast QUIC session using QUIC methods is 937 not supported by this profile. 939 The QUIC "CONNECTION_CLOSE" frames and the Stateless Reset packet are 940 prohibited. Participants MUST NOT send these and reception MUST be 941 handled as described in Section 4.12. 943 Explicit session tear-down using HTTP semantics is allowed, as 944 described in Section 5.4. 946 Implicit shutdown by means of silent close is also supported, as 947 described in Section 3.3. 949 4.8. Connection Migration 951 [QUIC-TRANSPORT] has a connection migration feature that allows a 952 connection to survive changes to endpoint addresses. This profile 953 does not currently support connection migration, and as such the QUIC 954 "NEW_CONNECTION_ID" and "RETIRE_CONNECTION_ID" frames are prohibited. 955 Similarly, the QUIC "PATH_CHALLENGE" and "PATH_RESPONSE" frames are 956 also prohibited, but additionally because they require bidirectional 957 capability that this profile does not provide. 959 Endpoints participating in a session conforming to this profile MUST 960 only use a single session ID for the duration of the session, and as 961 such there is no mapping for the "active_connection_id_limit" 962 transport parameter specified in section 5.1.1 of [QUIC-TRANSPORT] in 963 this profile. 965 *Author's Note*: Seamless migration from one multicast QUIC 966 session to another is described in Section 2.1.3. 968 4.9. Explicit Congestion Notification 970 [QUIC-TRANSPORT] specifies that clients may use Explicit Congestion 971 Notification (ECN) [RFC3168]. ECN allows receivers to inform senders 972 of impending congestion before packets are dropped, and the sender 973 may then reduce its transmission rate. As ECN requires bidirectional 974 communication for the receiver to inform the sender of the 975 congestion, the use of ECN for this profile is prohibited. 977 *Author's Note*: It is the responsibility of a receiver to 978 determine whether network conditions permit the uncongested 979 reception of a given session based on the advertised "peak-flow- 980 rate" parameter. 982 4.10. Session Keep-alive 984 The flow of traffic in a multicast QUIC session is driven by a 985 sender. There may be periods where the sender has no application 986 data to send for a period longer than the session idle timeout. This 987 profile repurposes the QUIC "PING" frame to act as a unidirectional 988 keep-alive message that may be sent in order to inform receivers that 989 the session should remain in the Fully-established state. 990 [QUIC-TRANSPORT] contains guidance on the sending frequency of QUIC 991 "PING" frames. 993 Senders MAY send a QUIC "PING" frame at any time in order to inform 994 receivers that the session traffic flow has not fallen idle. This 995 frame MUST NOT be acknowledged. Indeed, QUIC "ACK" frames are 996 prohibited by this profile (Section 4.11). 998 Receiving participants MUST NOT make any attempt to send QUIC "PING" 999 frames. 1001 4.11. Loss Detection and Recovery 1003 Receivers implementing this profile MUST NOT make any attempt to 1004 acknowledge the reception of QUIC packets. The QUIC "ACK" frame is 1005 prohibited for both senders and receivers. Reception of this frame 1006 MUST be handled as described in Section 4.12. 1008 Section 7 specifies alternative strategies for loss recovery. 1010 4.12. Prohibited QUIC Frames and Packets 1012 The following QUIC packets MUST NOT be transmitted by participants: 1013 Any packets with a long header (Initial, 0-RTT Protected, Handshake, 1014 Retry), Version Negotiation, Stateless Reset. 1016 The following QUIC frames MUST NOT be transmitted by participants: 1017 "ACK", "CONNECTION_CLOSE", "CRYPTO", "DATA_BLOCKED", 1018 "HANDSHAKE_DONE", "MAX_DATA", "MAX_STREAM_DATA", "MAX_STREAMS", 1019 "NEW_CONNECTION_ID", "NEW_TOKEN", "PATH_CHALLENGE", "PATH_RESPONSE", 1020 "RETIRE_CONNECTION_ID", "STOP_SENDING", "STREAM_DATA_BLOCKED", 1021 "STREAMS_BLOCKED". 1023 In addition, any QUIC extension frames not advertised in the session 1024 advertisement Section 3.6 MUST NOT be transmitted by participants. 1026 The following QUIC frames MUST NOT be transmitted by receivers: 1027 "PING", "RESET_STREAM". 1029 Reception of a prohibited or non-advertised QUIC frame or packet is a 1030 protocol error. Receivers MUST ignore all prohibited QUIC frames and 1031 packets. 1033 5. HTTP/3 Profile 1035 *Authors' Note:* The HTTP/3 mapping document is subject to change. 1036 This section is based on our best understanding of draft-ietf- 1037 quic-http-29. The authors will track developments and will update 1038 this section accordingly. 1040 HTTP over multicast QUIC depends on HTTP server push, as described in 1041 Section 4.4 of [QUIC-HTTP]. Section 5.2 below applies an additional 1042 constraint on the use of server push. A multicast sender 1043 participating in a session pushes resources as a series of QUIC 1044 "STREAM" frames carrying HTTP/3 "PUSH_PROMISE", "HEADERS" and "DATA" 1045 frames. Examples of this are provided in Appendix B.2. Senders MUST 1046 comply with the requirements of the session parameters, as described 1047 earlier in Section 3. 1049 The profile of HTTP/3 specified in this section places additional 1050 constraints on the use of metadata compression (Section 5.3). 1052 5.1. HTTP Connection Settings 1054 The HTTP/3 "SETTINGS" frame is prohibited by this profile. 1055 Participants MUST NOT make any attempt to send this frame type. 1056 Reception of this frame MUST be handled as described in Section 5.7. 1058 5.2. Server Push 1060 Server push is, by default, disabled for HTTP/3 connections. A 1061 conventional HTTP/3 client enables and manages server push by 1062 controlling the maximum Push ID ([QUIC-HTTP], Section 7.2.7), 1063 achieved by sending the HTTP/3 "MAX_PUSH_ID" frame. 1065 This profile mandates the use of server push, and specifies no means 1066 to disable it. The maximum Push ID for multicast QUIC sessions 1067 (initial and always) is 2^62. Values of Push ID SHALL be allocated 1068 in accordance with [QUIC-HTTP]. 1070 Server push concurrency in multicast QUIC is described in 1071 Section 3.5. There is no role for the HTTP/3 "MAX_PUSH_ID" frame and 1072 it is prohibited. Participants MUST NOT send this frame type. 1073 Reception of this frame type MUST be handled as described in 1074 Section 5.7. 1076 For this profile, the Stream Type for any new server-initiated 1077 unidirectional stream MUST be Server Push ("0x01"). 1079 The HTTP/3 "CANCEL_PUSH" frame MAY be used by sending participants to 1080 abort sending a response for the identified server push. Usage of 1081 this frame SHALL follow the guidance for servers in [QUIC-HTTP]. 1083 Receiving participants MUST NOT make any attempt to send HTTP/3 1084 "CANCEL_PUSH" frames to the multicast group. 1086 Receiving participants SHOULD ignore all frames on server-initiated 1087 unidirectional streams for which the packet containing the Push ID 1088 has not been received. Receiving participants SHOULD ignore all 1089 frames on server-initiated unidirectional streams carrying a Push ID 1090 that was not previously promised to the receiver. 1092 Conventionally, pushed responses are associated with an explicit 1093 request from a client. This is not possible when using a 1094 unidirectional transport such as multicast IP. This profile reserves 1095 the first client-initiated, bidirectional QUIC stream. HTTP/3 1096 "PUSH_PROMISE" frames MUST be sent on this reserved Stream ID. 1098 5.3. Metadata Compression 1100 The compression of HTTP header fields is considered in QPACK 1101 [QUIC-QPACK], which describes two methods for the compression of HTTP 1102 header fields: indexing (via static or dynamic tables) and Huffman 1103 encoding. 1105 A multicast QUIC session, as described in the present document, does 1106 not provide the assurances (receiver participation, transport 1107 reliability) required to sufficiently maintain the dynamic decoding 1108 context. Therefore, this document requires that endpoints SHALL NOT 1109 use dynamic table indexing. It is RECOMMENDED that endpoints use 1110 static table indexing and/or Huffman encoding in order to benefit 1111 from the remaining compression methods available. 1113 5.4. Session Tear-down 1115 A multicast QUIC session MAY be explicitly torn down by means of the 1116 "Connection: close" HTTP header described in section 6.6 of 1117 [RFC7230]. A sender intending to leave the session SHOULD include 1118 the "Connection: close" header in its response metadata. A sender 1119 SHOULD transmit all outstanding frames related to remaining request/ 1120 response exchanges before ending transmission to the multicast group. 1121 A receiver SHOULD continue to receive and process frames until all 1122 outstanding request/response exchanges are complete. 1124 The HTTP/3 "GOAWAY" frame is prohibited. Participants MUST NOT send 1125 this and reception MUST be handled as described in Section 5.7. 1127 5.5. Effects of Packet Loss 1129 Since multicast QUIC is an inherently unreliable delivery mechanism, 1130 portions of HTTP messages sent by the sender may not be received by 1131 the receiver. Conventional HTTP/3 frames assume reliable, in-order 1132 delivery by the underlying QUIC stream. HTTP/3 frames do not 1133 therefore carry any information indicating their position within the 1134 stream, because this information is instead carried in the QUIC 1135 "STREAM" frame header. 1137 In multicast QUIC, packet loss leaves gaps in the flow of a stream, 1138 and therefore gaps in the HTTP/3 frame(s) that are carried on that 1139 stream. 1141 1. Loss of an HTTP/3 "PUSH_PROMISE" frame renders the reception of 1142 an entire stream impossible, since the receiver ignores the new 1143 push stream that has not been promised as described in 1144 Section 5.2. 1146 2. Loss of a QUIC packet comprising all or part of an HTTP/3 1147 "HEADERS" frame will likely prevent the QPACK decoder from 1148 successfully parsing the received metadata, leaving the receiver 1149 unable to make use of the affected HTTP representation. 1151 3. Loss of a QUIC packet containing an HTTP/3 "DATA" frame header 1152 leaves a receiver unsure where to look for the start of the next 1153 HTTP/3 frame on the same stream. In the unlikely event that the 1154 receiver manages to resynchronise to the start of a subsequent 1155 HTTP/3 "DATA" frame, the position of the payload in the HTTP 1156 representation data is unknown because it is not explicitly 1157 signalled in the "DATA" frame header. The Offset field in the 1158 QUIC "STREAM" header describes the offset within the stream, but 1159 it is impossible for the receiver to know the size of any "DATA" 1160 frame headers that were lost. 1162 4. Loss of QUIC packets that only contain part of an HTTP/3 "DATA" 1163 frame Data field (i.e. beyond the frame header) can be recovered 1164 using the unicast repair mechanism described in Section 7.2. 1166 [H3-DATA-OFFSET] describes the "DATA_WITH_OFFSET" HTTP/3 extension 1167 frame type, which can be used to solve the third problem described 1168 above. Multicast QUIC sessions that make use of the 1169 "DATA_WITH_OFFSET" extension frame MUST advertise the session with 1170 the appropriate non-compatible experiment identifier "data-offset" in 1171 the ALPN string, as specified in Section 9.1. 1173 5.6. HTTP/3 Extension frames 1175 Except where explicitly allowed by this specification (e.g. in 1176 Section 5.5 above), HTTP/3 extension frames (e.g. "ALTSVC") are 1177 prohibited by this profile. Participants MUST NOT make any attempt 1178 to send prohibited extension frame types. Reception of these MUST be 1179 handled as described in Section 5.7. 1181 5.7. Prohibited HTTP/3 Frames 1183 The following HTTP/3 frames MUST NOT be transmitted by participants: 1184 "GOAWAY", "MAX_PUSH_ID", "SETTINGS". 1186 In addition, all HTTP/3 extension frame types MUST NOT be transmitted 1187 by participants. 1189 The following HTTP/3 frames MUST NOT be transmitted by receivers: 1190 "CANCEL_PUSH". 1192 Reception of a prohibited HTTP/3 frame is a protocol error. 1193 Receivers MUST ignore prohibited HTTP/3 frames. 1195 6. Application-Layer Security 1197 As already described in Section 3.1, the implicit cipher suite used 1198 by a multicast QUIC session makes very limited provision for security 1199 in the transport and session layers. This section profiles the use 1200 of some additional features to provide equivalent functionality at 1201 the application-layer. 1203 6.1. Content Integrity 1205 In many applications, it is important to ensure that an HTTP 1206 representation has been received intact (i.e. has not suffered from 1207 transmission loss or random bit errors) before passing the received 1208 object on to the receiving application. A mechanism is therefore 1209 specified here to provide end-to-end content integrity protection for 1210 HTTP representations in transit. The use of this content integrity 1211 mechanism is RECOMMENDED. 1213 *Authors' Note:* We invite review comments on mandating the use of 1214 this content integrity mechanism. 1216 [RFC3230] specifies an instance digest HTTP header called "Digest". 1217 A sender MAY include this header in the HTTP/3 "HEADERS" frame of any 1218 representation it transmits and a receiver MAY use this header to 1219 validate the integrity of the received representation once it has 1220 been reassembled. Where this validation fails, the receiver SHOULD 1221 discard the representation without processing it further. 1223 Note that the digest value protects a whole HTTP instance (i.e. the 1224 representation of a resource at the point of transmission as opposed 1225 to the body of a particular HTTP message). In cases where partial 1226 representations are fragmented over one or more HTTP response 1227 messages, the digest value is computed over the complete 1228 representation prior to fragmentation into partial responses. 1230 Any of the algorithms specified in the IANA registry of digest 1231 algorithms (http://www.iana.org/assignments/http-dig-alg/http-dig- 1232 alg.xhtml#http-dig-alg-1) MAY be used in conjunction with the 1233 "Digest" header. There is no requirement for participants to support 1234 the full set of algorithms. 1236 6.2. Content Authenticity 1238 In some applications, it is important for a receiver to reassure 1239 itself that an HTTP representation has been received from an 1240 authentic source. It is also sometimes useful for a receiver to know 1241 that the information has not been tampered with in transit by a 1242 malicious intermediate actor. A mechanism is therefore specified 1243 here to prove the authenticity of HTTP messages in transit. The use 1244 of this content authenticity mechanism is RECOMMENDED for senders 1245 implementing this specification. 1247 *Authors' Note:* We invite review comments on mandating the use of 1248 this content authenticity mechanism. 1250 [I-D.cavage-http-signatures] specifies a means of securely signing 1251 metadata associated with any HTTP message. The resulting digital 1252 signature is conveyed in the "Signature" header of the message 1253 itself. The "Signature" header also conveys a list of HTTP header 1254 fields over which the signature was computed. A receiver MAY verify 1255 the "Signature" header in order to validate the authenticity of 1256 received metadata. Where this validation fails, the receiver SHOULD 1257 discard or ignore any related metadata and/or data without processing 1258 it further. 1260 Note that the signature proves the authenticity of the metadata in a 1261 single HTTP message. A "Signature" header MAY be included separately 1262 in the HTTP/3 "PUSH_PROMISE" frame (protecting the request metadata) 1263 and in the final (or only) HTTP/3 "HEADERS" frame relating to a 1264 particular resource (protecting the response metadata). In order to 1265 provide an additional level of protection, however, it is RECOMMENDED 1266 that the signature be computed over the combined request metadata 1267 (from the HTTP/3 "PUSH_PROMISE" frame) and the corresponding response 1268 metadata (from the HTTP/3 "HEADERS" frames) of the same resource. 1269 This binds the request metadata and response metadata together, 1270 providing the receiver with additional reassurance of authenticity. 1271 In this latter case, the combined digital signature SHALL be conveyed 1272 in the final (or only) HTTP/3 "HEADERS" frame. 1274 In applications where the detection of replay attacks is a 1275 requirement, it is RECOMMENDED that the "Date" header be included in 1276 the scope of the signature. It is RECOMMENDED that receivers use the 1277 value of the "Date" header for replay detection using appropriate 1278 strategies (e.g. checking for freshness). The definition of such 1279 strategies is beyond the scope of this document. 1281 In applications where the authenticity and integrity of the 1282 transmission are both important, it is RECOMMENDED that the "Digest" 1283 header specified in Section 6.1 above is included in the scope of the 1284 signature. By signing the instance digest, the authenticity and 1285 integrity of the HTTP message body are also assured in addition to 1286 that of the metadata. 1288 Any of the algorithms specified in the IANA registry of signature 1289 algorithms (http://www.iana.org/assignments/signature-algorithms) MAY 1290 be used in conjunction with the "Signature" header. There is no 1291 requirement for participants to support the full set of algorithms. 1293 6.3. Content Confidentiality 1295 In applications where there is a requirement for the content itself 1296 to remain confidential, appropriate steps SHOULD be taken to protect 1297 the application payload, for example by encrypting it. This document 1298 does not preclude the use of application-level encryption, but does 1299 not specify a mechanism for the distribution of content decryption 1300 keys. 1302 7. Loss Recovery 1304 Because the acknowledgement of received packets to multicast groups 1305 is prohibited by this specification (Section 4.11) the detection of 1306 discarded or corrupted packets is the sole responsibility of the 1307 receiver, and such losses must be recovered by means other than the 1308 retransmission mechanism specified in [QUIC-TRANSPORT] and 1309 [QUIC-RECOVERY]. 1311 7.1. Forward Error Correction 1313 *Authors' Note:* A simple parity-based Forward Error Correction 1314 scheme was removed from the experimental QUIC wire protocol 1315 specification in version Q032. The IETF's QUIC Working Group is 1316 chartered to specify one (or more) new FEC schemes in the future. 1317 This section will track developments in this area, and will be 1318 updated accordingly. 1320 A sender MAY make use of a suitable Forward Error Correction scheme 1321 to allow a receiver to reconstruct lost packets from those that have 1322 been successfully received. 1324 7.2. Unicast Repair 1326 In the case where a lost QUIC packet cannot be recovered using 1327 Forward Error Correction, either because the number of packets lost 1328 exceeds the scheme's threshold for reconstruction, or because FEC is 1329 not in use on the multicast QUIC session, a receiver MAY instead 1330 recover the missing payload data using conventional unicast HTTP 1331 requests to an origin server. 1333 o The total size of the resource is indicated in the "content- 1334 length" response header carried in the HTTP/3 "HEADERS" frame. 1336 o The location of the missing data can be determined by examining 1337 the Offset field in the QUIC "STREAM" frame headers of 1338 successfully received QUIC packets. 1340 Using this information, a receiver MAY compose an efficient HTTP 1341 range request [RFC7233] to the origin server indicated in the URL. 1342 Several disjoint ranges MAY be combined into a single HTTP request. 1343 A receiver MAY direct its request to an alternative server using Alt- 1344 Svc information received on the multicast QUIC session, or else 1345 received as part of a previous unicast HTTP response according to the 1346 rules in [RFC7838]. 1348 8. Transmission of Partial Content 1350 Under certain circumstances, a sender may not be in full possession 1351 of a resource body when transmission begins, or may not be able to 1352 guarantee that a transmission will complete. In such cases, the 1353 sender MAY employ the syntax of an HTTP range request [RFC7233] to 1354 indicate partial content, as specified below. All receivers SHALL 1355 implement support for such HTTP range requests. 1357 If partial content is to be transmitted: 1359 o The "range" header (Section 3.1 of [RFC7233]) SHALL be present in 1360 the HTTP/3 "PUSH_PROMISE" frame. 1362 o The corresponding HTTP/3 "HEADERS" frame SHALL indicate HTTP 1363 status code 206. 1365 * The range being transmitted SHALL be indicated in a "content- 1366 range" header field and the size of the complete resource 1367 indicated in a "content-length" header field. 1369 9. Protocol Identifier 1371 The HTTP over multicast QUIC protocol specified in this document is 1372 identified by the application-layer protocol negotiation (ALPN) 1373 [RFC7301] identifier "h3m". The IANA registration of this protocol 1374 identifier can be found in Section 12.1. This reserves the ALPN 1375 identifier space but describes a protocol that does not use TLS. The 1376 usage of the "h3m" identifier for discoverability is described in 1377 Section 10. 1379 9.1. Draft Version Identification 1381 *RFC Editor's Note:* Please remove this section prior to 1382 publication of a final version of this document. 1384 Only implementations of the final, published RFC can identify 1385 themselves as "h3m". Until such an RFC exists, implementations MUST 1386 NOT identify themselves using this string. 1388 Implementations of draft versions of the protocol MUST add the string 1389 "-" and the corresponding draft number to the identifier. For 1390 example, draft-pardue-quic-http-mcast-06 is identified using the 1391 string "h3m-06". 1393 Non-compatible experiments that are based on these draft versions 1394 MUST append the string "-" and an experiment name to the identifier. 1395 For example, an experimental implementation based on draft-pardue- 1396 quic-http-mcast-06 which uses extension features not registered with 1397 the appropriate IANA registry might identify itself as "h3m-06- 1398 extension-foo". Note that any label MUST conform to the "token" 1399 syntax defined in Section 3.2.6 of [RFC7230]. Experimenters are 1400 encouraged to coordinate their experiments. 1402 10. Discovery of Multicast QUIC Sessions 1404 The announcement and discovery of services operating over multicast 1405 IP has previously been specified by the Session Description Protocol 1406 (SDP) [RFC4566], Session Announcement Protocol [RFC2974] and Session 1407 Initiation Protocol [RFC3261]. These are typically deployed together 1408 and in conjunction with a multicast-friendly transport such as the 1409 Real-time Transport Protocol (RTP) [RFC3550]. 1411 In contrast, the present document specifies a mechanism for 1412 advertising services that is built into HTTP metadata and is 1413 consistent across unicast and multicast resource delivery modes. 1414 This means that a single application-layer can be used for service 1415 advertisement/discovery, and for bulk data transmission/reception. 1416 Specifically, the "Alt-Svc" HTTP header is specified as the means to 1417 advertise multicast services from a unicast service. A unicast HTTP 1418 response MAY be decorated with an Alt-Svc value that hints to the 1419 client about the availability of the resource via a multicast QUIC 1420 session. A client that supports such a multicast QUIC session MAY 1421 then transparently switch to it. 1423 Symmetrically, the "Alt-Svc" header can also be used to advertise the 1424 unicast service from a multicast service. A resource transmitted as 1425 part of a multicast QUIC session MAY be decorated with an Alt-Svc 1426 value that hints to the client about the availability of the resource 1427 via an alternative unicast HTTP server. A receiver MAY then use this 1428 HTTP server for unicast resource patching (Section 7.2). 1430 Where HTTP over multicast QUIC sessions are advertised using Alt-Svc, 1431 the protocol identifier SHALL be "h3m", as specified in Section 9. 1433 10.1. Source-specific Multicast Advertisement 1435 Source-specific multicast (SSM) [RFC4607] MAY be used for the 1436 delivery of multicast services. 1438 *Authors' Note:* We invite review comments on mandating the use of 1439 source-specific multicast only. 1441 This document specifies the "source-address" parameter for Alt-Svc, 1442 which is used to provide the SSM source address to endpoints. 1444 Syntax: 1446 source-address = uri-host; see RFC7230, Section 2.7 1448 For example: 1450 source-address=192.0.2.1 1452 When a multicast QUIC session is provided using SSM, the "source- 1453 address" parameter MUST be advertised. If the parameter is repeated, 1454 the first occurrence MUST be used and subsequent occurrences MUST be 1455 ignored. 1457 10.2. Session Parameter Advertisement 1459 The concept of session parameters is introduced in Section 2.2. This 1460 section details how the session parameters are expressed as Alt-Svc 1461 parameters. 1463 10.2.1. Cipher Suite 1465 This document specifies the "cipher-suite" parameter for Alt-Svc, 1466 which carries the cipher suite in use by a multicast QUIC session. 1467 "cipher-suite" MUST contain one of the values contained in the TLS 1468 Cipher Suite Registry (http://www.iana.org/assignments/tls- 1469 parameters/tls-parameters.xhtml#tls-parameters-4): 1471 Syntax: 1473 cipher-suite = 4*4 HEXDIG 1475 For example, the following specifies cipher suite 0x13,0x01 1476 ("TLS_AES_128_GCM_SHA256"): 1478 cipher-suite=1301 1479 The requirements for endpoint usage of "cipher-suite" are described 1480 in Section 3.1. 1482 10.2.2. Session Key 1484 This document specifies the "key" parameter for Alt-Svc, which 1485 carries the cryptographic key in use by the multicast QUIC session. 1487 Syntax: 1489 key = *HEXDIG 1491 For example: 1493 key=4adf1eab9c2a37fd 1495 The requirements for endpoint usage of "key" are described in 1496 Section 3.1. 1498 10.2.3. Session Cipher Initialization Vector 1500 This document specifies the "iv" parameter for Alt-Svc, which carries 1501 the cipher Initialization Vector (IV) in use by the multicast QUIC 1502 session. 1504 Syntax: 1506 iv = *HEXDIG 1508 For example: 1510 iv=4dbe593acb4d1577ad6ba7dc3189834e 1512 The requirements for endpoint usage of "iv" are described in 1513 Section 3.1. 1515 10.2.4. Session Identification 1517 This document defines the "session-id" parameter for Alt-Svc, which 1518 carries the multicast QUIC session identifier. 1520 Syntax: 1522 session-id = *HEXDIG 1524 For example, the following specifies session 101 (0x65 hexadecimal): 1526 session-id=65 1527 The requirements for endpoint usage of "session-id" are described in 1528 Section 2.3. In the above example, the Destination Connection ID 1529 field in every QUIC packet header would be one byte in size. For a 1530 session-id of BADBEEF then then Destintation Connection ID field in 1531 every QUIC packet header would be four bytes in size. 1533 10.2.5. Session Idle Timeout Period 1535 This document specifies the "session-idle-timeout" parameter for Alt- 1536 Svc, which carries the idle timeout period in milliseconds of a 1537 multicast QUIC session. 1539 Syntax: 1541 session-idle-timeout = *DIGIT ; integer milliseconds 1543 For example, the following specifies a one-minute session idle 1544 timeout period: 1546 session-idle-timeout=60 1548 The requirements for endpoint usage of "session-idle-timeout" are 1549 described in Section 3.3. 1551 10.2.6. Resource Concurrency 1553 This document specifies the "max-concurrent-resources" parameter for 1554 Alt-Svc, which expresses the maximum number of concurrent active 1555 resources from the sender in a multicast QUIC session. 1557 Syntax: 1559 max-concurrent-resources = *DIGIT ; unsigned 32-bit integer 1561 For example, the following specifies that no more than 12 (decimal) 1562 resources will be concurrently active in the session: 1564 max-concurrent-resources=12 1566 The requirements for endpoint usage of "max-concurrent-resources" are 1567 described in Section 3.5. 1569 10.2.7. Session Peak Flow Rate 1571 This document specifies the "peak-flow-rate" parameter for Alt-Svc, 1572 which expresses the expected maximum aggregate transfer rate of data 1573 from all sources of the multicast QUIC session. 1575 Syntax: 1577 peak-flow-rate = *DIGIT ; bits per second 1579 For example, the following specifies a peak flow rate of 550 kbits/s 1580 in the session: 1582 peak-flow-rate=550000 1584 The requirements for endpoint usage of "peak-flow-rate" are described 1585 in Section 3.4. 1587 10.2.8. Digest Algorithm 1589 This document specifies the "digest-algorithm" parameter for Alt-Svc, 1590 which carries the digest algorithm in use by a multicast QUIC 1591 session. "digest-algorithm" MUST contain one of the values defined in 1592 the HTTP Digest Algorithm Values registry 1593 (https://www.iana.org/assignments/http-dig-alg/http-dig- 1594 alg.xhtml#http-dig-alg-1). 1596 Syntax: 1598 digest-algorithm = token 1600 For example, the following specifies a digest algorithm of SHA-256: 1602 digest-algorithm=SHA-256 1604 The requirements for endpoint usage of "digest-algorithm" are 1605 described in Section 3.7. 1607 10.2.9. Signature Algorithm 1609 This document specifies the "signature-algorithm" parameter for Alt- 1610 Svc, which carries the signature algorithm in use by a multicast QUIC 1611 session. "signature-algorithm" MUST contain one of the values defined 1612 in the Signature Algorithms registry 1613 (http://www.iana.org/assignments/signature-algorithms). 1615 Syntax: 1617 signature-algorithm = token 1619 For example, the following specifies a signature algorithm of SHA- 1620 256: 1622 signature-algorithm=rsa-sha256 1623 The requirements for endpoint usage of "signature-algorithm" are 1624 described in Section 3.8. 1626 10.2.10. Extensions 1628 This document specifies the "extensions" parameter for Alt-Svc, which 1629 carries a list of extension types potentially in use by a multicast 1630 QUIC session. "extensions" MUST only contain values from the QUIC 1631 Transport Parameter registry ([QUIC-TRANSPORT], section 22.3) that 1632 have explicit support for multicast QUIC. Each entry in the list 1633 consists of a key identifying the transport parameter, and an 1634 optional value. Both the key and the value are hex-encoded. 1636 Syntax: 1638 extensions = DQUOTE ext-transport-param 1639 *[ "," ext-transport-param ] DQUOTE 1640 ext-transport-param = ext-key [ "=" ext-value ] 1641 ext-key = 4*4HEXDIG; Transport Parameter key 1642 ext-value = *HEXDIG; Optional Transport Parameter value 1644 For example, the following specifies two extensions: 1646 extensions="0094,0d0d=f00" 1648 The requirements for endpoint usage of "extensions" are described in 1649 Section 3.6 1651 11. Security Considerations 1653 This document specifies a profile of QUIC and HTTP/3 that changes the 1654 security model. In order to address this, application-level security 1655 methods are described in Section 6. This document does not preclude 1656 the use of secure multicast approaches that may provide additional 1657 security assurances required for certain use cases. 1659 The use of side-channel or out-of-band technologies (potentially 1660 bidirectional interactions) to support multicast QUIC sessions are 1661 considered out of this document's scope. Services using such 1662 technologies should apply their security considerations accordingly. 1664 11.1. Pervasive Monitoring 1666 Certain multicast deployment architectures may require the use of a 1667 session decryption key shared by all participants. Furthermore, the 1668 discovery mechanism described in this document provides a means for a 1669 receiver to obtain a session decryption key without joining the 1670 session. The act of removing packet protection in order to inspect 1671 or modify application contents may, in certain deployments, be 1672 trivial. The exploration of restricting key learning or session 1673 joining to authorised participants goes beyond the scope of this 1674 document. 1676 Because in-band multicast interactions are unidirectional, the impact 1677 of Pervasive Monitoring [RFC7258] on in-band traffic flows is 1678 inherently reduced. Actors can only inspect or modify sender- 1679 initiated traffic. Additional measures for content confidentiality 1680 may mitigate the impact further. This is discussed in Section 6.3. 1682 Further Pervasive Monitoring concerns are addressed in the following 1683 sections. 1685 11.1.1. Large-scale Data Gathering and Correlation 1687 Multicast QUIC sessions decouple sending and receiving participants. 1688 Session participation is subject to operations that allow an endpoint 1689 to join or leave a multicast group, typically IGMP [RFC3376] or MLD 1690 [RFC3810]. The propagation intent of these messages travelling 1691 deeper through a network hierarchy generally leads to the 1692 anonymisation of data if implemented as specified. It may be 1693 possible to gather user-identifiable messages close to the network 1694 edge, for example a router logging such messages. However, this 1695 would require wide-ranging access across Internet Service Provider 1696 networks. Therefore, while such attacks are feasible, it can be 1697 asserted that gathering and correlating user-identifiable traffic is 1698 difficult to perform covertly and at scale. 1700 11.1.2. Changing Content 1702 Sessions that use a symmetric key for packet protection are subject 1703 to the possibility of a malicious actor modifying traffic at some 1704 point in the network between a legitimate sender and one (or more) 1705 receivers. Receiver-side validation, as specified in Section 6 of 1706 the present document, and also in [QUIC-TRANSPORT], allows for the 1707 detection of such modification. Two approaches help mitigate the 1708 impact of modification; the first is application-level methods that 1709 protect data (Section 6.1) and metadata (Section 6.2); the second is 1710 reduction of the QUIC packet attack surface by means of removal of 1711 many frame types (Section 4.12 and Section 5.7). 1713 11.2. Protection of Discovery Mechanism 1715 Multicast QUIC session advertisements SHOULD be conveyed over a 1716 secure transport that guarantees authenticity and integrity in order 1717 to mitigate attacks related to a malicious service advertisement, for 1718 example a "man in the middle" directing endpoints to a service that 1719 may lead to other attacks or exploitations. 1721 *Authors' Note:* We invite review comments on mandating the use of 1722 a secure transport for advertising sessions. 1724 Endpoints that make use of multicast QUIC session advertisements 1725 SHOULD have reasonable assurance that the alternative service is 1726 under control of, and valid for, the whole origin, as described in 1727 Section 2.1 of [RFC7838]. Section 6.2 discusses measures that may be 1728 used to fulfil this requirement. 1730 11.3. Spoofing 1732 11.3.1. Sender Spoofing 1734 A malicious actor may be able to stage a spoof attack by sending fake 1735 QUIC packets to a multicast QUIC session. This could affect the 1736 operation or behaviour of receivers. In a multicast scenario, this 1737 form of attack has the potential to scale massively. 1739 The feasibility of spoofing a multicast sender is governed by the 1740 characteristics of the multicast deployment and network 1741 infrastructure. The use of source-specific multicast [RFC4607] may 1742 reduce the feasibility. The use of content authenticity 1743 (Section 6.2) may mitigate concerns for the application-level 1744 messages. However, there remains the possibility for transport-level 1745 messages to be spoofed. Multicast applications should consider 1746 further mitigations to address this concern. 1748 11.4. Replay Attacks 1750 Conventional QUIC strategies for protecting against replay attacks 1751 apply similarly here. 1753 Certain multicast QUIC sessions may use a shared key for transport- 1754 level encryption, which would allow an attacker to record, decrypt, 1755 repackage and replay QUIC packets. Section 6.2 discusses how the 1756 application-level contents may be protected from replay (by signing 1757 the "Date" HTTP header), which provides some mitigation to the 1758 success rate or effects of replay attacks. 1760 11.5. Message Deletion 1762 Since HTTP over multicast QUIC is designed to tolerate unreliable 1763 delivery, the impacts of message deletion attacks are presumed to be 1764 small. Deletion of packets carrying HTTP headers will cause a 1765 receiver to ignore subsequent packets carrying body data. 1767 Furthermore, the use of multicast QUIC sessions is opportunistic; 1768 disruption in service (for example, deleting packets and causing a 1769 receiver to fail in construction of a content object) is mitigated by 1770 falling back to a unicast service. Considerations for how this may 1771 affect the performance of the unicast service are given in 1772 Section 11.6.3. 1774 11.6. Denial of Service 1776 11.6.1. Unprotected Frames and Packets 1778 The profile described in the present document provides the means for 1779 a multicast sender to protect QUIC packets with a shared key, which 1780 is not a strong protection. The weak protection of QUIC packets 1781 could present a denial-of-service risk. To mitigate the impact of 1782 handling such QUIC packets, certain frames and packets are prohibited 1783 as described in (Section 4.12 and Section 5.7). 1785 The frame types that are allowed by this profile do not present a 1786 risk of denial of service. Concerns over authenticity and integrity 1787 are addressed by the application-layer protection mechanisms 1788 described in Section 6. 1790 11.6.2. Network Performance Degradation 1792 The possibility for malfunctioning or malicious participants to 1793 degrade the network is a broad issue and considered out of scope for 1794 this document. Guidelines and concerns discussed in UDP Best 1795 Practices [RFC8085] and other sources apply equally here. This 1796 specification does not preclude the use of network performance 1797 degradation mitigation solutions such as network circuit breakers. 1799 11.6.3. Unicast Repair Stampeding Herd 1801 Deployments that support the unicast repair mechanism described in 1802 Section 7.2 should be aware that a triggering of this behaviour 1803 (either deliberate, planned or unplanned) in a large population of 1804 multicast receivers may cause a stampeding herd of client requests to 1805 the unicast repair service. Service operators SHOULD mitigate the 1806 impact of stampeding herd on their deployment. 1808 11.7. Receiver Resource Usage 1810 The application of receiver-side validation, as defined in the 1811 present document and in [QUIC-TRANSPORT], adds some protection 1812 against allocating resource to the processing of bad data. 1814 11.8. Unicast Repair Information Leakage 1816 The unicast repair mechanism may lead to the leakage of user 1817 behaviour data. An attacker could gain insight into any receiver 1818 participating in a multicast QUIC session, for example by monitoring 1819 the TCP port of the unicast alternative. This alone is no worse than 1820 current abilities to monitor unicast interactions, for example 1821 observing the SNI field contained in a TLS ClientHello. The complete 1822 protection of unicast interactions is beyond the scope of this 1823 document. However, knowledge that a user (or group of users) has 1824 participated in a session is sensitive and may be obtained by 1825 correlation between with observable multicast and unicast traffic. 1827 To give an example, a malicious "man in the middle" could purposely 1828 cause all receivers to perform a unicast repair (by disrupting the 1829 QUIC traffic flow in some way). The disruption is untargeted and may 1830 be simple to orchestrate, but the correlation of user activity data, 1831 especially across a distributed repair service (e.g. a CDN), requires 1832 resources that may reduce the attractiveness of such an attack. 1834 The ability for an attacker to disrupt multicast QUIC sessions is 1835 mitigated by this profile (mainly the prohibition of frames and 1836 packets). Application-layer security measures described in Section 6 1837 reduce the feasibility further. 1839 Multicast receivers concerned about this form of leakage can 1840 eliminate this risk completely by disabling support for unicast 1841 repair, at the potential cost of reduced service quality. 1843 12. IANA Considerations 1845 12.1. Registration of Protocol Identification String 1847 This document creates a new registration for the identification of 1848 the HTTP over multicast QUIC protocol in the "Application-Layer 1849 Protocol Negotiation (ALPN) Protocol IDs" registry established by 1850 [RFC7301]. 1852 The "h3m" string identifies HTTP semantics expressed as HTTP mapped 1853 to a QUIC layer and carried over IP multicast: 1855 Protocol: Bulk data transport using HTTP over multicast QUIC 1857 Identification Sequence: 0x68 0x33 0x6D ("h3m") 1859 Specification: This document, Section 9 1860 This entry reserves an identifier that is not allowed to appear in 1861 TLS Application-Layer Protocol Negotiation. 1863 12.2. Registration of Alt-Svc parameters 1865 This document creates seven registrations for the identification of 1866 parameters for the "Hypertext Transfer Protocol (HTTP) Alt-Svc 1867 Parameter Registry" established by [RFC7838] 1868 (http://www.iana.org/assignments/tls-extensiontype-values/tls- 1869 extensiontype-values.xhtml#alpn-protocol-ids). 1871 12.2.1. Source Address 1873 Parameter name: source-address 1875 Specification: This document, Section 10.1 1877 12.2.2. Cipher Suite 1879 Parameter name: cipher-suite 1881 Specification: This document, Section 10.2.1 1883 12.2.3. Key 1885 Parameter name: key 1887 Specification: This document, Section 10.2.2 1889 12.2.4. Initialization Vector 1891 Parameter name: iv 1893 Specification: This document, Section 10.2.3 1895 12.2.5. Session Identifier 1897 Parameter name: session-id 1899 Specification: This document, Section 10.2.4 1901 12.2.6. Session Idle Timeout 1903 Parameter name: session-idle-timeout 1905 Specification: This document, Section 10.2.5 1907 12.2.7. Maximum Concurrent Resources 1909 Parameter name: max-concurrent-resources 1911 Specification: This document, Section 10.2.6 1913 12.2.8. Peak Flow Rate 1915 Parameter name: peak-flow-rate 1917 Specification: This document, Section 10.2.7 1919 12.2.9. Digest Algorithm 1921 Parameter name: digest-algorithm 1923 Specification: This document, Section 10.2.8 1925 12.2.10. Signature Algorithm 1927 Parameter name: signature-algorithm 1929 Specification: This document, Section 10.2.9 1931 12.2.11. Extension 1933 Parameter name: extension 1935 Specification: This document, Section 10.2.10 1937 13. References 1939 13.1. Normative References 1941 [H3-DATA-OFFSET] 1942 Hurst, S., "An Offset Extension Frame For HTTP/3 Data", 1943 draft-hurst-quic-http-data-offset-frame-00 (work in 1944 progress). 1946 [I-D.cavage-http-signatures] 1947 Cavage, M. and M. Sporny, "Signing HTTP Messages", draft- 1948 cavage-http-signatures-12 (work in progress), October 1949 2019. 1951 [QUIC-HTTP] 1952 Bishop, M., Ed., "Hypertext Transfer Protocol Version 3 1953 (HTTP/3)", draft-ietf-quic-http-34 (work in progress). 1955 [QUIC-QPACK] 1956 Krasic, C., Ed., Bishop, M., Ed., and A. Frindell, Ed., 1957 "QPACK: Header Compression for HTTP over QUIC", draft- 1958 ietf-quic-qpack-21 (work in progress). 1960 [QUIC-TRANSPORT] 1961 Iyengar, J., Ed. and M. Thomson, Ed., "QUIC: A UDP-Based 1962 Multiplexed and Secure Transport", draft-ietf-quic- 1963 transport-34 (work in progress). 1965 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 1966 Requirement Levels", BCP 14, RFC 2119, 1967 DOI 10.17487/RFC2119, March 1997, 1968 . 1970 [RFC3168] Ramakrishnan, K., Floyd, S., and D. Black, "The Addition 1971 of Explicit Congestion Notification (ECN) to IP", 1972 RFC 3168, DOI 10.17487/RFC3168, September 2001, 1973 . 1975 [RFC3230] Mogul, J. and A. Van Hoff, "Instance Digests in HTTP", 1976 RFC 3230, DOI 10.17487/RFC3230, January 2002, 1977 . 1979 [RFC4607] Holbrook, H. and B. Cain, "Source-Specific Multicast for 1980 IP", RFC 4607, DOI 10.17487/RFC4607, August 2006, 1981 . 1983 [RFC5234] Crocker, D., Ed. and P. Overell, "Augmented BNF for Syntax 1984 Specifications: ABNF", STD 68, RFC 5234, 1985 DOI 10.17487/RFC5234, January 2008, 1986 . 1988 [RFC7230] Fielding, R., Ed. and J. Reschke, Ed., "Hypertext Transfer 1989 Protocol (HTTP/1.1): Message Syntax and Routing", 1990 RFC 7230, DOI 10.17487/RFC7230, June 2014, 1991 . 1993 [RFC7233] Fielding, R., Ed., Lafon, Y., Ed., and J. Reschke, Ed., 1994 "Hypertext Transfer Protocol (HTTP/1.1): Range Requests", 1995 RFC 7233, DOI 10.17487/RFC7233, June 2014, 1996 . 1998 [RFC7234] Fielding, R., Ed., Nottingham, M., Ed., and J. Reschke, 1999 Ed., "Hypertext Transfer Protocol (HTTP/1.1): Caching", 2000 RFC 7234, DOI 10.17487/RFC7234, June 2014, 2001 . 2003 [RFC7301] Friedl, S., Popov, A., Langley, A., and E. Stephan, 2004 "Transport Layer Security (TLS) Application-Layer Protocol 2005 Negotiation Extension", RFC 7301, DOI 10.17487/RFC7301, 2006 July 2014, . 2008 [RFC7405] Kyzivat, P., "Case-Sensitive String Support in ABNF", 2009 RFC 7405, DOI 10.17487/RFC7405, December 2014, 2010 . 2012 [RFC7838] Nottingham, M., McManus, P., and J. Reschke, "HTTP 2013 Alternative Services", RFC 7838, DOI 10.17487/RFC7838, 2014 April 2016, . 2016 [RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC 2017 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, 2018 May 2017, . 2020 13.2. Informative References 2022 [QUIC-RECOVERY] 2023 Iyengar, J., Ed. and I. Swett, Ed., "QUIC Loss Detection 2024 and Congestion Control", draft-ietf-quic-recovery-34 (work 2025 in progress). 2027 [QUIC-TLS] 2028 Thomson, M., Ed. and S. Turner, Ed, Ed., "Using Transport 2029 Layer Security (TLS) to Secure QUIC", draft-ietf-quic- 2030 tls-34 (work in progress). 2032 [RFC1112] Deering, S., "Host extensions for IP multicasting", STD 5, 2033 RFC 1112, DOI 10.17487/RFC1112, August 1989, 2034 . 2036 [RFC1191] Mogul, J. and S. Deering, "Path MTU discovery", RFC 1191, 2037 DOI 10.17487/RFC1191, November 1990, 2038 . 2040 [RFC2974] Handley, M., Perkins, C., and E. Whelan, "Session 2041 Announcement Protocol", RFC 2974, DOI 10.17487/RFC2974, 2042 October 2000, . 2044 [RFC3261] Rosenberg, J., Schulzrinne, H., Camarillo, G., Johnston, 2045 A., Peterson, J., Sparks, R., Handley, M., and E. 2046 Schooler, "SIP: Session Initiation Protocol", RFC 3261, 2047 DOI 10.17487/RFC3261, June 2002, 2048 . 2050 [RFC3376] Cain, B., Deering, S., Kouvelas, I., Fenner, B., and A. 2051 Thyagarajan, "Internet Group Management Protocol, Version 2052 3", RFC 3376, DOI 10.17487/RFC3376, October 2002, 2053 . 2055 [RFC3550] Schulzrinne, H., Casner, S., Frederick, R., and V. 2056 Jacobson, "RTP: A Transport Protocol for Real-Time 2057 Applications", STD 64, RFC 3550, DOI 10.17487/RFC3550, 2058 July 2003, . 2060 [RFC3810] Vida, R., Ed. and L. Costa, Ed., "Multicast Listener 2061 Discovery Version 2 (MLDv2) for IPv6", RFC 3810, 2062 DOI 10.17487/RFC3810, June 2004, 2063 . 2065 [RFC4566] Handley, M., Jacobson, V., and C. Perkins, "SDP: Session 2066 Description Protocol", RFC 4566, DOI 10.17487/RFC4566, 2067 July 2006, . 2069 [RFC4821] Mathis, M. and J. Heffner, "Packetization Layer Path MTU 2070 Discovery", RFC 4821, DOI 10.17487/RFC4821, March 2007, 2071 . 2073 [RFC5737] Arkko, J., Cotton, M., and L. Vegoda, "IPv4 Address Blocks 2074 Reserved for Documentation", RFC 5737, 2075 DOI 10.17487/RFC5737, January 2010, 2076 . 2078 [RFC5740] Adamson, B., Bormann, C., Handley, M., and J. Macker, 2079 "NACK-Oriented Reliable Multicast (NORM) Transport 2080 Protocol", RFC 5740, DOI 10.17487/RFC5740, November 2009, 2081 . 2083 [RFC6676] Venaas, S., Parekh, R., Van de Velde, G., Chown, T., and 2084 M. Eubanks, "Multicast Addresses for Documentation", 2085 RFC 6676, DOI 10.17487/RFC6676, August 2012, 2086 . 2088 [RFC6726] Paila, T., Walsh, R., Luby, M., Roca, V., and R. Lehtonen, 2089 "FLUTE - File Delivery over Unidirectional Transport", 2090 RFC 6726, DOI 10.17487/RFC6726, November 2012, 2091 . 2093 [RFC7258] Farrell, S. and H. Tschofenig, "Pervasive Monitoring Is an 2094 Attack", BCP 188, RFC 7258, DOI 10.17487/RFC7258, May 2095 2014, . 2097 [RFC7450] Bumgardner, G., "Automatic Multicast Tunneling", RFC 7450, 2098 DOI 10.17487/RFC7450, February 2015, 2099 . 2101 [RFC8085] Eggert, L., Fairhurst, G., and G. Shepherd, "UDP Usage 2102 Guidelines", BCP 145, RFC 8085, DOI 10.17487/RFC8085, 2103 March 2017, . 2105 [RFC8200] Deering, S. and R. Hinden, "Internet Protocol, Version 6 2106 (IPv6) Specification", STD 86, RFC 8200, 2107 DOI 10.17487/RFC8200, July 2017, 2108 . 2110 Appendix A. Acknowledgements 2112 The authors would like to thank the following for their contributions 2113 to the design described in the present document: Brandon Butterworth, 2114 Chris Poole, Craig Taylor and David Waring. 2116 We are also grateful to Thomas Swindells and Magnus Westerlund for 2117 their helpful review comments. 2119 Appendix B. Examples 2121 This appendix contains examples of multicast QUIC session 2122 advertisement and resource transfer (with and without application- 2123 layer content security). 2125 B.1. Session Advertisement 2127 This section shows several different examples of an HTTP service 2128 advertising a multicast QUIC session. Examples are given in IPv4 2129 form, using reserved address ranges as specified in [RFC5737] and 2130 [RFC6676]. 2132 B.1.1. Source-specific Multicast QUIC Session 2134 Advertisement of a multicast QUIC session operating on the source- 2135 specific multicast group address 232.0.0.1 on port 2000 with the 2136 source address 192.0.2.1. The session ID is 16 (0x10) and the idle 2137 timeout is one minute. At most 10 resources may be concurrently 2138 active in the session and the flow rate should not exceed 10 kbits/s. 2139 The multicast transport is unencrypted. 2141 HTTP Alternative Service header field: 2143 Alt-Svc: 2144 h3m="232.0.0.1:2000"; source-address="192.0.2.1"; 2145 session-id=10; session-idle-timeout=60; 2146 max-concurrent-resources=10; peak-flow-rate=10000 2148 B.1.2. Source-specific Multicast QUIC Session with Transport Encryption 2149 using a Symmetric Key 2151 Advertisement of a multicast QUIC session operating on the IPv6 2152 globally-scoped source-specific multicast group address ff3e::1234 on 2153 port 2000 with the source address 2001:db8::1. The session ID is 16 2154 (0x10) and the idle timeout is one minute. At most 10 resources may 2155 be concurrently active in the session and the flow rate should not 2156 exceed 10 kbits/s. The multicast transport is encrypted using the 2157 AEAD cipher suite 0x13,0x01 ("TLS_AES_128_GCM_SHA256") with the 2158 shared session key and IV provided. 2160 HTTP Alternative Service header field: 2162 Alt-Svc: 2163 h3m="[ff3e::1234]:2000"; source-address="2001:db8::1"; 2164 session-id=10; session-idle-timeout=60; 2165 max-concurrent-resources=10; peak-flow-rate=10000; 2166 cipher-suite=1301; key=4adf1eab9c2a37fd; 2167 iv=4dbe593acb4d1577ad6ba7dc3189834e 2169 B.1.3. Source-specific Multicast QUIC Session with Transport 2170 Encryption, Content Integrity and Authenticity 2172 Advertisement of a multicast QUIC session operating on the IPv6 2173 globally-scoped source-specific multicast group address ff3e::1234 on 2174 port 2000 with the source address 2001:db8::1. The session ID is 16 2175 (0x10) and the idle timeout is one minute. At most 10 resources may 2176 be concurrently active in the session and the flow rate should not 2177 exceed 10 kbits/s. The multicast transport is encrypted using the 2178 AEAD cipher suite 0x13,0x01 ("TLS_AES_128_GCM_SHA256") with the 2179 shared session key and IV provided. Content integrity is in use with 2180 the digest algorithm set restricted to SHA-256. Content authenticity 2181 is in use with the signature algorithm set restricted to rsa-sha256. 2183 HTTP Alternative Service header field: 2185 Alt-Svc: 2186 h3m="[ff3e::1234]:2000"; source-address="2001:db8::1"; 2187 session-id=10; session-idle-timeout=60; 2188 max-concurrent-resources=10; peak-flow-rate=10000; 2189 cipher-suite=1301; key=4adf1eab9c2a37fd; 2190 iv=4dbe593acb4d1577ad6ba7dc3189834e; 2191 digest-algorithm=SHA-256; signature-algorithm=rsa-sha256 2193 B.2. Resource Transfer 2195 This section shows several different examples of the HTTP message 2196 patterns for a single resource. 2198 Examples that show HTTP/3 "PUSH_PROMISE" or "HEADERS" frames describe 2199 the contents of enclosed header block fragments. 2201 B.2.1. Transfer without Content Integrity or Authenticity 2203 HTTP/3 "PUSH_PROMISE" frame: 2205 :method: GET 2206 :scheme: https 2207 :path: /files/example.txt 2208 :authority: example.org 2210 HTTP/3 "HEADERS" frame: 2212 :status: 200 2213 content-length: 100 2214 content-type: text/plain 2215 date: Fri, 20 Jan 2017 10:00:00 GMT 2217 HTTP/3 "DATA" frame containing 100 bytes of response body data: 2219 ... 2221 B.2.2. Transfer of Partial Content without Content Integrity or 2222 Authenticity 2224 In this example, partial content is transferred as described in 2225 Section 8. The "Range" request header is used to indicate the 2226 sender's original intention to transfer all 100 bytes of the 2227 representation. The "Content-Range" response header indicates that 2228 only the first 50 bytes were actually sent. 2230 HTTP/3 "PUSH_PROMISE" frame: 2232 :method: GET 2233 :scheme: https 2234 :path: /files/example.txt 2235 :authority: example.org 2236 range: bytes=0-* 2238 HTTP/3 "HEADERS" frame: 2240 :status: 206 2241 content-length: 100 2242 content-range: bytes 0-49/100 2243 content-type: text/plain 2244 date: Fri, 20 Jan 2017 10:00:00 GMT 2246 HTTP/3 "DATA" frame containing 50 bytes of response body data: 2248 ... 2250 B.2.3. Transfer with Content Integrity and without Authenticity 2252 In this example, content integrity is assured by the inclusion of the 2253 "Digest" response header, as described in Section 6.1. 2255 HTTP/3 "PUSH_PROMISE" frame: 2257 :method: GET 2258 :scheme: https 2259 :path: /files/example.txt 2260 :authority: example.org 2262 HTTP/3 "HEADERS" frame including the "Digest" header: 2264 :status: 200 2265 content-length: 100 2266 content-type: text/plain 2267 date: Fri, 20 Jan 2017 10:00:00 GMT 2268 digest: SHA-256=DieQ9zfRaDdyAilTVCvmBePuxMm+B6cNocP+QCrNSqo= 2270 HTTP/3 "DATA" frame containing 100 bytes of response body data: 2272 ... 2274 B.2.4. Partial Transfer with Content Integrity and without Authenticity 2276 In this example, partial content is transferred as described in 2277 Section 8. The "Range" request header is used to indicate the 2278 sender's intention to transfer all 100 bytes of the representation. 2279 The "Content-Range" response header indicates that only the first 50 2280 bytes were actually sent. Content integrity is assured by the 2281 inclusion of the "Digest" response header, as described in 2282 Section 6.1. 2284 HTTP/3 "PUSH_PROMISE" frame: 2286 :method: GET 2287 :scheme: https 2288 :path: /files/example.txt 2289 :authority: example.org 2290 range: bytes=0-* 2292 HTTP/3 "HEADERS" frame including the "Digest" header: 2294 :status: 206 2295 content-length: 100 2296 content-range: bytes 0-49/100 2297 content-type: text/plain 2298 date: Fri, 20 Jan 2017 10:00:00 GMT 2299 digest: SHA-256=DieQ9zfRaDdyAilTVCvmBePuxMm+B6cNocP+QCrNSqo= 2301 HTTP/3 "DATA" frame containing 50 bytes of response body data: 2303 ... 2305 B.2.5. Transfer with Content Integrity and Authenticity 2307 In this example, content integrity is assured by the inclusion of the 2308 "Digest" response header, as described in Section 6.1. Content 2309 authenticity is assured separately for the request and the response 2310 messages by the "Signature" header which protects the header fields 2311 described in further detail below. The "Signature" header parameter 2312 "keyId" contains the URL of a file containing the public key related 2313 to the multicast sender's private key used to create the digital 2314 signature. 2316 HTTP/3 "PUSH_PROMISE" frame including a "Signature" header protecting 2317 the ":method" and ":path" (the request target), as well as the 2318 ":scheme" and ":authority" of the pseudo-request: 2320 :method: GET 2321 :scheme: https 2322 :path: /files/example.txt 2323 :authority: example.org 2324 signature: keyId="https://example.org/mcast-sender.example.org.pem", 2325 algorithm=rsa-sha256, 2326 headers="(request-target) :scheme :authority", 2327 signature="MGQCMFTaFptaM2FhgzJq2i9AaChuFDHjp6GiXVtRnI8BsA" 2329 HTTP/3 "HEADERS" frame including a "Signature" header protecting the 2330 ":method", ":path", ":scheme" and ":authority" of the pseudo-request 2331 above, plus the "Date" and "Digest" of the response: 2333 :status: 200 2334 content-length: 100 2335 content-type: text/plain 2336 date: Fri, 20 Jan 2017 10:00:00 GMT 2337 digest: SHA-256=DieQ9zfRaDdyAilTVCvmBePuxMm+B6cNocP+QCrNSqo= 2338 signature: keyId="https://example.org/mcast-sender.example.org.pem", 2339 algorithm=rsa-sha256, 2340 headers="(request-target) :scheme :authority date digest", 2341 signature="MGUCMBgx6cuwTzg0W29zNUra8xfMsEcb3rFA3Y" 2343 HTTP/3 "DATA" frame containing response body data: 2345 ... 2347 B.2.6. Partial Transfer with Content Integrity and Authenticity 2349 In this example, partial content is transferred and the "Range" 2350 header (as described in Section 8) is used to indicate that 50 bytes 2351 out of 100 bytes were transferred. Content integrity is provided by 2352 the inclusion of the "Digest" header, as described in Section 6.1. 2353 Authenticity is provided by the "Signature" header which protects the 2354 header fields described in further detail. The "Signature" header 2355 parameter "keyId" contains the URL of a file containing the public 2356 key related to the multicast sender's private key used to create the 2357 digital signature. 2359 HTTP/3 "PUSH_PROMISE" frame: 2361 :method: GET 2362 :scheme: https 2363 :path: /files/example.txt 2364 :authority: example.org 2365 range: bytes=0-* 2366 signature: keyId="https://example.org/mcast-sender.example.org.pem", 2367 algorithm=rsa-sha256, 2368 headers="(request-target) :scheme :authority range", 2369 signature="MGQCMFTaFptaM2FhgzJq2i9AaChuFDHjp6GiXVtRnI8BsA" 2371 HTTP/3 "HEADERS" frame protecting the ":method", ":path", ":scheme" 2372 and ":authority" of the pseudo-request above, plus the "Date", 2373 "Digest" and "Content-Range" of the response: 2375 :status: 206 2376 content-length: 100 2377 content-range: bytes 0-49/100 2378 content-type: text/plain 2379 date: Fri, 20 Jan 2017 10:00:00 GMT 2380 digest: SHA-256=DieQ9zfRaDdyAilTVCvmBePuxMm+B6cNocP+QCrNSqo= 2381 signature: keyId="https://example.org/mcast-sender.example.org.pem", 2382 algorithm=rsa-sha256, 2383 headers="(request-target) :scheme :authority 2384 date digest content-range", 2385 signature="MGUCMBgx6cuwTzg0W29zNUra8xfMsEcb3rFA3Y" 2387 HTTP/3 "DATA" frame containing response body data: 2389 ... 2391 Appendix C. Summary of differences from unicast QUIC and HTTP/3 2392 +----------------+-----------------------+--------------------------+ 2393 | Protocol | Unicast QUIC | Multicast QUIC profile | 2394 | feature | | | 2395 +----------------+-----------------------+--------------------------+ 2396 | Packet number | QUIC transport | All packets are numbered | 2397 | spaces | packets are seperated | in the application data | 2398 | | into three distinct | packet number space. | 2399 | | packet number spaces: | | 2400 | | initial, handshake | | 2401 | | and application data. | | 2402 | | | | 2403 | Transport | Combined | Not used. | 2404 | handshake | cryptographic and | | 2405 | | transport handshake | | 2406 | | stream conveying TLS | | 2407 | | handshake messages in | | 2408 | | QUIC Initial and | | 2409 | | Handshake packets. | | 2410 | | | | 2411 | TLS cipher | Client's preferred | Cipher suite optionally | 2412 | suite | cipher suite included | advertised out of band | 2413 | | in Client Hello | via Alt-Svc "cipher- | 2414 | | message. | suite" parameter. | 2415 | | | Default cipher suite is | 2416 | | | "0x00,0x00 | 2417 | | | (NULL_WITH_NULL_NULL)". | 2418 | | | | 2419 | TLS session | Session key included | Session key optionally | 2420 | key | in Server Hello | advertised out of band | 2421 | | message. | via Alt-Svc "key" | 2422 | | | parameter. | 2423 | | | | 2424 | TLS | Initialization vector | Initialization vector | 2425 | initialization | included in Server | optionally advertised | 2426 | vector | Hello message. | out of band via Alt-Svc | 2427 | | | "iv" parameter. | 2428 +----------------+-----------------------+--------------------------+ 2430 Table 1: Cryptography and Transport 2432 +----------------------------+----------------+---------------------+ 2433 | Protocol feature | Unicast QUIC | Multicast QUIC | 2434 | | | profile | 2435 +----------------------------+----------------+---------------------+ 2436 | "initial_max_data" | Connection- | Not used. Peak flow | 2437 | | level flow | rate of a session | 2438 | | control window | optionally | 2439 | | size. | advertised out of | 2440 | | | band via Alt-Svc | 2441 | | | "peak-flow-rate" | 2442 | | | parameter. | 2443 | | | | 2444 | "initial_max_stream_data_b | Locally- | Not used. No | 2445 | idi_local" | initiated | bidirectional | 2446 | | bidirectional | streams in this | 2447 | | stream flow | profile. | 2448 | | control window | | 2449 | | size. | | 2450 | | | | 2451 | "initial_max_stream_data_b | Remotely- | Not used. No | 2452 | idi_remote" | initiated | bidirectional | 2453 | | bidirectional | streams in this | 2454 | | stream flow | profile. | 2455 | | control window | | 2456 | | size. | | 2457 | | | | 2458 | "initial_max_stream_data_u | Unidirectional | Not used. Peak flow | 2459 | ni" | stream flow | rate of a session | 2460 | | control window | optionally | 2461 | | size. | advertised out of | 2462 | | | band via Alt-Svc | 2463 | | | "peak-flow-rate | 2464 | | | parameter". | 2465 | | | | 2466 | "initial_max_streams_bidi" | Maximum stream | Not used. Maximum | 2467 | and | concurrency. | concurrent | 2468 | "initial_max_streams_uni" | | resources in a | 2469 | | | session optionally | 2470 | | | advertised out of | 2471 | | | band via Alt-Svc | 2472 | | | "max-concurrent- | 2473 | | | resources" | 2474 | | | parameter. | 2475 +----------------------------+----------------+---------------------+ 2477 Table 2: Required Transport Parameters 2479 +------------------------------+---------------+--------------------+ 2480 | Protocol feature | Unicast QUIC | Multicast QUIC | 2481 | | | profile | 2482 +------------------------------+---------------+--------------------+ 2483 | "original_destination_connec | The value of | Not used. No | 2484 | tion_id" | the | client | 2485 | | Destination | interaction. | 2486 | | Connection ID | | 2487 | | field from | | 2488 | | the first | | 2489 | | Initial | | 2490 | | packet sent | | 2491 | | by the | | 2492 | | client. | | 2493 | | | | 2494 | "max_idle_timeout" | How long to | Not used. | 2495 | | keep an idle | Advertised out of | 2496 | | connection | band via Alt-Svc | 2497 | | open for | "session-idle- | 2498 | | before | timeout" | 2499 | | closing. | parameter; | 2500 | | Takes a | defaults to 0 | 2501 | | default of 0 | (never close on | 2502 | | (never close | idle) if not | 2503 | | on idle) if | specified. | 2504 | | not | | 2505 | | specified. | | 2506 | | | | 2507 | "stateless_reset_token" | Used in | Not used. | 2508 | | verifying a | Stateless reset is | 2509 | | stateless | not used by this | 2510 | | reset. | profile. | 2511 | | | | 2512 | "max_udp_payload_size" | Limit of the | Not used. Maximum | 2513 | | size of | packet size for a | 2514 | | packets that | session optionally | 2515 | | an endpoint | advertised out of | 2516 | | is willing to | band via Alt-Svc | 2517 | | receive. | "max-packet-size" | 2518 | | | parameter. | 2519 | | | | 2520 | "ack_delay_exponent" | The exponent | Not used. "ACK" | 2521 | | used to | frames are | 2522 | | decode the | prohibited by this | 2523 | | ACK Delay | profile. | 2524 | | field in the | | 2525 | | "ACK" frame. | | 2526 | | | | 2527 | "max_ack_delay" | Maximum time | Not used. "ACK" | 2528 | | in | frames are | 2529 | | milliseconds | prohibited by this | 2530 | | by which an | profile. | 2531 | | endpoint will | | 2532 | | delay sending | | 2533 | | acknowledgeme | | 2534 | | nts. | | 2535 | | | | 2536 | "disable_active_migration" | Signals if an | Not used. Session | 2537 | | endpoint does | migration not | 2538 | | not support | currently | 2539 | | connection | supported by this | 2540 | | migration. | profile. | 2541 | | | | 2542 | "preferred_address" | Used to | Not used. No | 2543 | | effect a | handshake in this | 2544 | | change in | profile. | 2545 | | server | | 2546 | | address at | | 2547 | | the end of | | 2548 | | the | | 2549 | | handshake. | | 2550 | | | | 2551 | "active_connection_id_limit" | | Not used. Only a | 2552 | | | single session | 2553 | | | identifier is used | 2554 | | | in this profile. | 2555 | | | | 2556 | "initial_source_connection_i | The value | Not used. No | 2557 | d" | that an | client | 2558 | | endpoint | interaction. | 2559 | | included in | | 2560 | | the Source | | 2561 | | Connection ID | | 2562 | | field of the | | 2563 | | first Initial | | 2564 | | packet it | | 2565 | | sent for the | | 2566 | | connection | | 2567 | | | | 2568 | "retry_source_connection_id" | The value | Not used. Retry | 2569 | | that the | packets are not | 2570 | | server | used in this | 2571 | | included in | profile. | 2572 | | the Source | | 2573 | | Connection ID | | 2574 | | field of a | | 2575 | | retry packet | | 2576 +------------------------------+---------------+--------------------+ 2578 Table 3: Optional Transport Parameters 2580 +-------------+---------------------+-------------------------------+ 2581 | Protocol | Unicast QUIC | Multicast QUIC profile | 2582 | feature | | | 2583 +-------------+---------------------+-------------------------------+ 2584 | Maximum | Determined by path | Determined by path MTU | 2585 | packet size | MTU discovery or | discovery or other heuristic. | 2586 | | other heuristic. | | 2587 | | | | 2588 | Long header | Used for packets | Prohibited. | 2589 | packet | that are sent prior | | 2590 | | to the completion | | 2591 | | of version | | 2592 | | negotiation and | | 2593 | | before packet | | 2594 | | protection keys are | | 2595 | | established. | | 2596 | | | | 2597 | Version | Protocol version | Not permitted. | 2598 | negotiation | negotiation between | | 2599 | packet | initiating client | | 2600 | | and server. | | 2601 | | | | 2602 | Stateless | Used by a peer to | Not permitted. (Potential | 2603 | reset | terminate a | denial-of-service attack | 2604 | packet | connection that has | vector.) | 2605 | | become unusable. | | 2606 | | | | 2607 | Short | Used for packets | Used to convey QUIC frames | 2608 | header | that are sent once | (see below). | 2609 | packet | a connection has | | 2610 | | been established. | | 2611 | | Used to convey QUIC | | 2612 | | frames (see below). | | 2613 | | | | 2614 | Source | Connection IDs | Source Connection ID not | 2615 | Connection | negotiated between | used. Destination Connection | 2616 | ID field, | client and server | ID redefined to be a | 2617 | Destination | during handshake | Multicast Session ID which is | 2618 | Connection | and may be changed | optionally advertised out of | 2619 | ID field | subsequently using | band via the Alt-Svc | 2620 | | the | "session-id" parameter. May | 2621 | | "NEW_CONNECTION_ID" | be omitted from packets if | 2622 | | frame. | the address/port tuple is | 2623 | | | sufficient to identify the | 2624 | | | session, in which case it is | 2625 | | | not advertised. | 2626 +-------------+---------------------+-------------------------------+ 2628 Table 4: QUIC Packet Layer 2630 +------------------------+----------------------+---------------------+ 2631 | Protocol feature | Unicast QUIC | Multicast QUIC | 2632 | | | profile | 2633 +------------------------+----------------------+---------------------+ 2634 | "PADDING" frame | Used to pad out a | Permitted, but | 2635 | | QUIC packet with | wasteful of network | 2636 | | zero bytes. (The | capacity. | 2637 | | first packet sent on | | 2638 | | a connection must be | | 2639 | | at least 1200 bytes | | 2640 | | long to prove that | | 2641 | | the network can | | 2642 | | transmit packets of | | 2643 | | at least this size.) | | 2644 | | | | 2645 | "PING" frame | Used by an endpoint | Used by the | 2646 | | to verify that its | multicast sender as | 2647 | | peer is still alive. | a session keep- | 2648 | | Acknowledged using a | alive notification. | 2649 | | regular "ACK" frame. | Never acknowledged. | 2650 | | | | 2651 | "ACK" frames | Used by a receiver | Both "ACK" frame | 2652 | | to acknowledge | types are | 2653 | | receipt of data from | prohibited. | 2654 | | its peer. | | 2655 | | | | 2656 | "RESET_STREAM" frame | Request by receiver | Indication to | 2657 | | for sender to | receivers that the | 2658 | | terminate a stream | multicast sender | 2659 | | transmission | has prematurely | 2660 | | prematurely. | terminated a stream | 2661 | | | transmission. | 2662 | | | Prohibited for | 2663 | | | receivers to send. | 2664 | | | | 2665 | "STOP_SENDING" frame | Flow control back | Prohibited. | 2666 | | pressure. Used to | | 2667 | | signal to a peer | | 2668 | | that incoming data | | 2669 | | on a stream is being | | 2670 | | discarded on receipt | | 2671 | | at the application's | | 2672 | | request. This | | 2673 | | abruptly terminates | | 2674 | | a stream. | | 2675 | | | | 2676 | "CRYPTO" frame | Used to transmit | Prohibited. | 2677 | | cryptographic | | 2678 | | handshake messages. | | 2679 | | | | 2680 | "NEW_TOKEN" frame | Used by a server to | Prohibited. Session | 2681 | | supply a token to | migration not | 2682 | | its client to be | currently supported | 2683 | | sent in the header | by this profile. | 2684 | | of an initial packet | | 2685 | | for a future | | 2686 | | connection. Used to | | 2687 | | facilitate | | 2688 | | connection | | 2689 | | migration. | | 2690 | | | | 2691 | "STREAM" frame | Conveys application- | Conveys | 2692 | | layer payloads (see | application-layer | 2693 | | HTTP/3 mapping | payloads (see | 2694 | | below). | HTTP/3 mapping | 2695 | | | below). | 2696 | | | | 2697 | "FIN" bit on "STREAM" | Indication by sender | Indication by the | 2698 | frame | to its peer that a | multicast sender | 2699 | | stream transmission | that a stream | 2700 | | has finished. | transmission has | 2701 | | | finished. | 2702 | | | | 2703 | "MAX_DATA" frame | Flow control update | Prohibited. | 2704 | | notification. | | 2705 | | | | 2706 | "MAX_STREAM_DATA" | Flow control update | Prohibited. | 2707 | frame | notification. | | 2708 | | | | 2709 | "MAX_STREAMS" frame | Used by an endpoint | Prohibited. | 2710 | | to inform a peer of | | 2711 | | the maximum stream | | 2712 | | ID that it is | | 2713 | | permitted to open. | | 2714 | | | | 2715 | "DATA_BLOCKED" frame | Notification to | Prohibited. | 2716 | | receiver that | | 2717 | | sender's | | 2718 | | transmission is | | 2719 | | blocked pending an | | 2720 | | update to its flow | | 2721 | | control window by | | 2722 | | peer. | | 2723 | | | | 2724 | "STREAM_DATA_BLOCKED" | Notification to | Prohibited. | 2725 | frame | receiver that | | 2726 | | sender's | | 2727 | | transmission of a | | 2728 | | single stream is | | 2729 | | blocked pending an | | 2730 | | update to its flow | | 2731 | | control window by | | 2732 | | peer. | | 2733 | | | | 2734 | "STREAMS_BLOCKED" | Notification to | Prohibited. | 2735 | frames | receiver that the | | 2736 | | sender wishes to | | 2737 | | open a stream but is | | 2738 | | unable to do so | | 2739 | | because the maximum | | 2740 | | stream ID has been | | 2741 | | reached for a given | | 2742 | | stream type. | | 2743 | | | | 2744 | "NEW_CONNECTION_ID" | Used to provide a | Prohibited. Session | 2745 | frame | peer with | migration not | 2746 | | alternative | currently supported | 2747 | | connection IDs that | by this profile. | 2748 | | can be used to break | | 2749 | | linkability when | | 2750 | | migrating | | 2751 | | connections. | | 2752 | | | | 2753 | "RETIRE_CONNECTION_ID" | Indicates that an | Prohibited. Session | 2754 | frame | endpoint will no | migration not | 2755 | | longer use a | currently supported | 2756 | | connection ID that | by this profile. | 2757 | | was issued by its | | 2758 | | peer. | | 2759 | | | | 2760 | "PATH_CHALLENGE" frame | Used to check | Prohibited. | 2761 | | reachability to a | | 2762 | | peer and for path | | 2763 | | validation during | | 2764 | | connection | | 2765 | | migration. | | 2766 | | | | 2767 | "PATH_RESPONSE" frame | Sent in response to | Prohibited. | 2768 | | a "PATH_CHALLENGE" | | 2769 | | frame. | | 2770 | | | | 2771 | "CONNECTION_CLOSE" | Notification (by | Prohibited. Use | 2772 | frame | either peer) of | HTTP explicit | 2773 | | graceful connection | session tear-down | 2774 | | shutdown. | instead (see | 2775 | | | Section 5.4). | 2776 | | | | 2777 | "HANDSHAKE_DONE" frame | Used by a server to | Prohibited. | 2778 | | inform a client that | | 2779 | | the cryptographic | | 2780 | | handshake has | | 2781 | | completed. | | 2782 +------------------------+----------------------+---------------------+ 2784 Table 5: QUIC Framing Layer 2786 +----------------+------------------+-------------------------------+ 2787 | Protocol | Unicast HTTP/3 | Multicast HTTP/3 profile | 2788 | feature | | | 2789 +----------------+------------------+-------------------------------+ 2790 | Stream Type | Type of | Only Server Push type is | 2791 | | unidirectional | permitted. | 2792 | | stream. | | 2793 | | | | 2794 | Push ID | Identifies a | Identifies a promised | 2795 | | promised | resource conveyed in an | 2796 | | resource | earlier "PUSH_PROMISE" frame. | 2797 | | conveyed in an | | 2798 | | earlier | | 2799 | | "PUSH_PROMISE" | | 2800 | | frame. | | 2801 | | | | 2802 | "DATA" frame | Carriage of HTTP | Carriage of HTTP response | 2803 | | request/response | message body. | 2804 | | message body. | | 2805 | | | | 2806 | "HEADERS" | Carriage of HTTP | Carriage of HTTP response | 2807 | frame | request/response | message metadata. Trailing | 2808 | | message | "HEADERS" frame is permitted. | 2809 | | metadata. | | 2810 | | Trailing | | 2811 | | "HEADERS" frame | | 2812 | | is permitted. | | 2813 | | | | 2814 | "CANCEL_PUSH" | Used to request | Permitted only for senders. | 2815 | frame | cancellation of | | 2816 | | server push | | 2817 | | prior to the | | 2818 | | push stream | | 2819 | | being created. | | 2820 | | | | 2821 | "SETTINGS" | Negotiation of | Prohibited. | 2822 | frame | HTTP/3 | | 2823 | | connection | | 2824 | | settings. | | 2825 | | | | 2826 | "PUSH_PROMISE" | Carriage of HTTP | Carriage of HTTP pseudo- | 2827 | frame | pseudo-request | request message metadata. All | 2828 | | message | HTTP representation transfers | 2829 | | metadata. | over multicast begin this | 2830 | | | way. Stream ID of the first | 2831 | | | client-initiated | 2832 | | | bidirectional stream is | 2833 | | | reserved and all | 2834 | | | "PUSH_PROMISE" frames | 2835 | | | reference this as the client | 2836 | | | request from which they are | 2837 | | | notionally derived. This | 2838 | | | stream remains open while a | 2839 | | | sender is participating in | 2840 | | | the multicast QUIC session. | 2841 | | | | 2842 | "GOAWAY" frame | Early | Prohibited. Use HTTP explicit | 2843 | | notification (by | session tear-down instead. | 2844 | | either endpoint) | | 2845 | | of future | | 2846 | | connection | | 2847 | | closure, | | 2848 | | allowing for | | 2849 | | orderly | | 2850 | | completion of | | 2851 | | open streams. | | 2852 | | | | 2853 | "MAX_PUSH_ID" | Used by a | Prohibited. | 2854 | frame | receiver to | | 2855 | | control the | | 2856 | | number of server | | 2857 | | pushes that a | | 2858 | | sender can | | 2859 | | initiate. | | 2860 | | | | 2861 | "ALTSVC" | Signalling | Prohibited. | 2862 | HTTP/2 | alternative | | 2863 | extension | service for | | 2864 | frame | HTTP/3 session. | | 2865 | | | | 2866 | Other HTTP/2 | | Prohibited. | 2867 | extension | | | 2868 | frames | | | 2869 +----------------+------------------+-------------------------------+ 2871 Table 6: HTTP/3 Mapping 2873 +-------------+----------------------------------+------------------+ 2874 | Protocol | Unicast HTTP/3 | Multicast HTTP/3 | 2875 | feature | | profile | 2876 +-------------+----------------------------------+------------------+ 2877 | Huffman | Header blocks may use Huffman | Header blocks | 2878 | string | codes to compress literal string | may use Huffman | 2879 | compression | values. | codes to | 2880 | | | compress literal | 2881 | | | string values. | 2882 | | | | 2883 | Static | Header blocks may refer to | Header blocks | 2884 | table | indexed entries in the static | may refer to | 2885 | | table. | indexed entries | 2886 | | | in the static | 2887 | | | table. | 2888 | | | | 2889 | Dynamic | Header blocks may insert entries | Prohibited, size | 2890 | table | into the dynamic table and | is currently | 2891 | | subsequent header blocks may | locked to 0. | 2892 | | refer to their indexes. Unused | | 2893 | | as size is currently locked to | | 2894 | | 0. | | 2895 +-------------+----------------------------------+------------------+ 2897 Table 7: HTTP Metadata Compression Layer 2899 Appendix D. Changelog 2901 *RFC Editor's Note:* Please remove this section prior to 2902 publication of a final version of this document. 2904 D.1. Since draft-pardue-quic-http-mcast-07 2906 o Update references to QUIC WG I-Ds. 2908 o Remove stale references to sections of the QUIC WG I-Ds that don't 2909 exist any more. 2911 o Add references to the DATA_WITH_OFFSET frame I-D. 2913 D.2. Since draft-pardue-quic-http-mcast-06 2915 o Update references to QUIC WG I-Ds. 2917 o Clarify that only the first source-address parameter should be 2918 used if duplicated. 2920 o Fix source-address example to not be a quoted string. 2922 o Fix bytes in the ALPN identification sequence following change to 2923 h3m. 2925 o Update language around QUIC Connection IDs to reflect the core 2926 specs. 2928 o Update frame and transport parameter names throughout to match 2929 core specifications. 2931 o Remove Author's Note about reserved stream ID for "PUSH_PROMISE" 2932 frames. 2934 o Update language around QPACK static and dynamic table indexing to 2935 more closely align with the core spec. 2937 o Update Session Idle Timeout to match core specs, including 2938 removing limitation of 600 seconds and expressing in milliseconds, 2939 not seconds. 2941 o Preface Session Termination with a statement clarifying that 2942 participants may leave at any time. 2944 D.3. Since draft-pardue-quic-http-mcast-05 2946 o Update references to QUIC WG I-Ds. 2948 o Sender packet number size is now fixed for the duration of a 2949 session. 2951 o Change how to handle multiple session IDs: sessions are now only 2952 allowed a single ID. 2954 o Remove incompatible requirements set by [QUIC-TRANSPORT]'s 2955 "Required Operations". 2957 o Additionally ban "HANDSHAKE_DONE". 2959 o Remove Version Negotiation now that the "quic" Alt-Svc parameter 2960 has been removed (examples also updated). 2962 o Remove HTTP Prioritization references. 2964 o Add new "extensions" Alt-Svc parameter. 2966 o Broaden peak flow rate to QUIC payload to encompass all frame 2967 types. 2969 o Change ALPN identifier to h3m. 2971 D.4. Since draft-pardue-quic-http-mcast-04 2973 o Update references to QUIC WG I-Ds, remove QUIC-SPIN. (draft-ietf- 2974 quic-transport-20) 2976 o Update session ID length to match new connection ID length. 2977 (draft-ietf-quic-transport-22) 2979 o Clarify the mapping for the new "active_connection_id_limit" 2980 session parameter. (draft-ietf-quic-transport-21) 2982 o Update text to conform with latest version negotiation text from 2983 [QUIC-TRANSPORT]. 2985 o Update stream types for server push in accordance with draft-ietf- 2986 quic-http-19. 2988 o Fix some idnits warnings to do with line lengths in Alt-Svc 2989 examples. 2991 o Update IPv6 informative reference to RFC 8200 as it obsoletes RFC 2992 2460. 2994 o Clarify difference between connection and session migration. 2996 o Move GOAWAY frame to HTTP/3 profile. 2998 o Renamed Session Shutdown to Connection Shutdown to mirror concept 2999 in [QUIC-TRANSPORT]. 3001 o Clarify the layer of each frame type when referred to. 3003 D.5. Since draft-pardue-quic-http-mcast-03 3005 o Update references to QUIC WG I-Ds. 3007 o Change crypto handshake text now that it's no longer done on 3008 Stream ID 0. 3010 o Update to reference Source and Destination Connection IDs. 3012 o Prohibit the use of connection coalescing, migration and ECN. 3014 o Update allowed and disallowed packets and frames to match the core 3015 specs. 3017 o Remove references to the PONG frame. (draft-ietf-quic-transport- 3018 10) 3020 o Change HTTP/QUIC to HTTP/3. (draft-ietf-quic-http-17) 3022 o Change HPACK to QPACK. (draft-ietf-quic-http-10) 3024 o Prohibit the DUPLICATE_PUSH frame. 3026 o Clarify packet number space (only use application data space, not 3027 initial or handshake). 3029 o Add statement on QUIC latency spin bit. 3031 o Removed sentence stating that multiple Connection IDs cannot be 3032 used concurrently in a unicast QUIC session, in accordance with 3033 [QUIC-TRANSPORT] section 5.1.2. 3035 D.6. Since draft-pardue-quic-http-mcast-02 3037 o No changes. 3039 D.7. Since draft-pardue-quic-http-mcast-01 3041 o Explicit guidance on maximum stream ID value permitted. 3043 o Updated guidance on PING (and PONG) frame. 3045 o Added a comparison table to appendix. 3047 o Remove invalid use of trailing headers. 3049 o Use the new HTTP/QUIC DATA frame. 3051 o Prohibit APPLICATION CLOSE frame, and move GOAWAY frame to HTTP/ 3052 QUIC section. 3054 o Redefine server push to reflect core document changes. 3056 o Remove default idle time out value. 3058 o Clarify session parameter requirements (session-idle-timeout 3059 became mandatory). 3061 o Update frame notation convention. 3063 D.8. Since draft-pardue-quic-http-mcast-00 3065 o Update references to QUIC WG I-Ds. 3067 o Relax session leaving requirements language. 3069 o Clarify handling of omitted session parameter advertisements. 3071 o Rename "Idle" state to "Quiescent". 3073 o Add digest algorithm session parameter. 3075 o Add signature algorithm session parameter. 3077 o Add Initialization Vector session parameter. 3079 o Replace COPT tag-value-pairs with TransportParameter values. 3081 o Add example of an advertisement for a session with content 3082 authenticity and integrity. 3084 Authors' Addresses 3086 Lucas Pardue 3088 Email: lucaspardue.24.7@gmail.com 3090 Richard Bradbury 3091 BBC Research & Development 3093 Email: richard.bradbury@bbc.co.uk 3095 Sam Hurst 3096 BBC Research & Development 3098 Email: sam.hurst@bbc.co.uk