idnits 2.17.00 (12 Aug 2021) /tmp/idnits19015/draft-pardue-quic-http-mcast-07.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 : ---------------------------------------------------------------------------- ** The document seems to lack a Security Considerations section. ** There is 1 instance of too long lines in the document, the longest one being 13 characters in excess of 72. == 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 (August 7, 2020) is 652 days in the past. Is this intentional? Checking references for intended status: Informational ---------------------------------------------------------------------------- == Outdated reference: A later version (-34) exists of draft-ietf-quic-http-29 == Outdated reference: A later version (-21) exists of draft-ietf-quic-qpack-16 == Outdated reference: draft-ietf-quic-transport has been published as RFC 9000 == Outdated reference: draft-ietf-quic-recovery has been published as RFC 9002 == Outdated reference: draft-ietf-quic-tls has been published as RFC 9001 -- Obsolete informational reference (is this intentional?): RFC 4566 (Obsoleted by RFC 8866) Summary: 2 errors (**), 0 flaws (~~), 8 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: Informational R. Bradbury 5 Expires: February 8, 2021 S. Hurst 6 BBC Research & Development 7 August 7, 2020 9 Hypertext Transfer Protocol (HTTP) over multicast QUIC 10 draft-pardue-quic-http-mcast-07 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 February 8, 2021. 38 Copyright Notice 40 Copyright (c) 2020 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 . . . . . . . . . . . . . . . . . . 23 97 5.4. Session Tear-down . . . . . . . . . . . . . . . . . . . . 24 98 5.5. HTTP/3 Extension frames . . . . . . . . . . . . . . . . . 24 99 5.6. Prohibited HTTP/3 Frames . . . . . . . . . . . . . . . . 24 100 6. Application-Layer Security . . . . . . . . . . . . . . . . . 24 101 6.1. Content Integrity . . . . . . . . . . . . . . . . . . . . 25 102 6.2. Content Authenticity . . . . . . . . . . . . . . . . . . 25 103 6.3. Content Confidentiality . . . . . . . . . . . . . . . . . 27 104 7. Loss Recovery . . . . . . . . . . . . . . . . . . . . . . . . 27 105 7.1. Forward Error Correction . . . . . . . . . . . . . . . . 27 106 7.2. Unicast Repair . . . . . . . . . . . . . . . . . . . . . 27 107 8. Transmission of Partial Content . . . . . . . . . . . . . . . 28 108 9. Protocol Identifier . . . . . . . . . . . . . . . . . . . . . 28 109 9.1. Draft Version Identification . . . . . . . . . . . . . . 28 110 10. Discovery of Multicast QUIC Sessions . . . . . . . . . . . . 29 111 10.1. Source-specific Multicast Advertisement . . . . . . . . 30 112 10.2. Session Parameter Advertisement . . . . . . . . . . . . 30 113 10.2.1. Cipher Suite . . . . . . . . . . . . . . . . . . . . 30 114 10.2.2. Session Key . . . . . . . . . . . . . . . . . . . . 31 115 10.2.3. Session Cipher Initialization Vector . . . . . . . . 31 116 10.2.4. Session Identification . . . . . . . . . . . . . . . 31 117 10.2.5. Session Idle Timeout Period . . . . . . . . . . . . 32 118 10.2.6. Resource Concurrency . . . . . . . . . . . . . . . . 32 119 10.2.7. Session Peak Flow Rate . . . . . . . . . . . . . . . 32 120 10.2.8. Digest Algorithm . . . . . . . . . . . . . . . . . . 33 121 10.2.9. Signature Algorithm . . . . . . . . . . . . . . . . 33 122 10.2.10. Extensions . . . . . . . . . . . . . . . . . . . . . 34 123 11. Security and Privacy Considerations . . . . . . . . . . . . . 34 124 11.1. Pervasive Monitoring . . . . . . . . . . . . . . . . . . 34 125 11.1.1. Large-scale Data Gathering and Correlation . . . . . 35 126 11.1.2. Changing Content . . . . . . . . . . . . . . . . . . 35 127 11.2. Protection of Discovery Mechanism . . . . . . . . . . . 35 128 11.3. Spoofing . . . . . . . . . . . . . . . . . . . . . . . . 36 129 11.3.1. Spoofed Ack Attacks . . . . . . . . . . . . . . . . 36 130 11.3.2. Sender Spoofing . . . . . . . . . . . . . . . . . . 36 131 11.3.3. Receiver Spoofing . . . . . . . . . . . . . . . . . 36 132 11.4. Replay Attacks . . . . . . . . . . . . . . . . . . . . . 36 133 11.5. Message Deletion . . . . . . . . . . . . . . . . . . . . 37 134 11.6. Denial of Service . . . . . . . . . . . . . . . . . . . 37 135 11.6.1. Unprotected Frames and Packets . . . . . . . . . . . 37 136 11.6.2. Network Performance Degradation . . . . . . . . . . 37 137 11.6.3. Unicast Repair Stampeding Herd . . . . . . . . . . . 38 138 11.7. Receiver Resource Usage . . . . . . . . . . . . . . . . 38 139 11.8. Unicast Repair Information Leakage . . . . . . . . . . . 38 140 12. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 39 141 12.1. Registration of Protocol Identification String . . . . . 39 142 12.2. Registration of Alt-Svc parameters . . . . . . . . . . . 39 143 12.2.1. Source Address . . . . . . . . . . . . . . . . . . . 39 144 12.2.2. Cipher Suite . . . . . . . . . . . . . . . . . . . . 39 145 12.2.3. Key . . . . . . . . . . . . . . . . . . . . . . . . 39 146 12.2.4. Initialization Vector . . . . . . . . . . . . . . . 40 147 12.2.5. Session Identifier . . . . . . . . . . . . . . . . . 40 148 12.2.6. Session Idle Timeout . . . . . . . . . . . . . . . . 40 149 12.2.7. Maximum Concurrent Resources . . . . . . . . . . . . 40 150 12.2.8. Peak Flow Rate . . . . . . . . . . . . . . . . . . . 40 151 12.2.9. Digest Algorithm . . . . . . . . . . . . . . . . . . 40 152 12.2.10. Signature Algorithm . . . . . . . . . . . . . . . . 40 153 12.2.11. Extension . . . . . . . . . . . . . . . . . . . . . 40 154 13. References . . . . . . . . . . . . . . . . . . . . . . . . . 41 155 13.1. Normative References . . . . . . . . . . . . . . . . . . 41 156 13.2. Informative References . . . . . . . . . . . . . . . . . 42 157 Appendix A. Acknowledgements . . . . . . . . . . . . . . . . . . 44 158 Appendix B. Examples . . . . . . . . . . . . . . . . . . . . . . 44 159 B.1. Session Advertisement . . . . . . . . . . . . . . . . . . 44 160 B.1.1. Source-specific Multicast QUIC Session . . . . . . . 45 161 B.1.2. Source-specific Multicast QUIC Session with Transport 162 Encryption using a Symmetric Key . . . . . . . . . . 45 163 B.1.3. Source-specific Multicast QUIC Session with Transport 164 Encryption, Content Integrity and Authenticity . . . 45 165 B.2. Resource Transfer . . . . . . . . . . . . . . . . . . . . 46 166 B.2.1. Transfer without Content Integrity or Authenticity . 46 167 B.2.2. Transfer of Partial Content without Content Integrity 168 or Authenticity . . . . . . . . . . . . . . . . . . . 46 169 B.2.3. Transfer with Content Integrity and without 170 Authenticity . . . . . . . . . . . . . . . . . . . . 47 171 B.2.4. Partial Transfer with Content Integrity and without 172 Authenticity . . . . . . . . . . . . . . . . . . . . 48 173 B.2.5. Transfer with Content Integrity and Authenticity . . 48 174 B.2.6. Partial Transfer with Content Integrity and 175 Authenticity . . . . . . . . . . . . . . . . . . . . 49 176 Appendix C. Summary of differences from unicast QUIC and HTTP/3 50 177 Appendix D. Changelog . . . . . . . . . . . . . . . . . . . . . 61 178 D.1. Since draft-pardue-quic-http-mcast-06 . . . . . . . . . . 61 179 D.2. Since draft-pardue-quic-http-mcast-05 . . . . . . . . . . 62 180 D.3. Since draft-pardue-quic-http-mcast-04 . . . . . . . . . . 63 181 D.4. Since draft-pardue-quic-http-mcast-03 . . . . . . . . . . 63 182 D.5. Since draft-pardue-quic-http-mcast-02 . . . . . . . . . . 64 183 D.6. Since draft-pardue-quic-http-mcast-01 . . . . . . . . . . 64 184 D.7. Since draft-pardue-quic-http-mcast-00 . . . . . . . . . . 64 185 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 65 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.2 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.4 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.4 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.6. 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.6. 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 Conventionally, pushed responses are associated with an explicit 1087 request from a client. This is not possible when using a 1088 unidirectional transport such as multicast IP. This profile reserves 1089 the first client-initiated, bidirectional QUIC stream. HTTP/3 1090 "PUSH_PROMISE" frames MUST be sent on this reserved Stream ID. 1092 5.3. Metadata Compression 1094 The compression of HTTP header fields is considered in QPACK 1095 [QUIC-QPACK], which describes two methods for the compression of HTTP 1096 header fields: indexing (via static or dynamic tables) and Huffman 1097 encoding. 1099 A multicast QUIC session, as described in the present document, does 1100 not provide the assurances (receiver participation, transport 1101 reliability) required to sufficiently maintain the dynamic decoding 1102 context. Therefore, this document requires that endpoints SHALL NOT 1103 use dynamic table indexing. It is RECOMMENDED that endpoints use 1104 static table indexing and/or Huffman encoding in order to benefit 1105 from the remaining compression methods available. 1107 5.4. Session Tear-down 1109 A multicast QUIC session MAY be explicitly torn down by means of the 1110 "Connection: close" HTTP header described in section 6.6 of 1111 [RFC7230]. A sender intending to leave the session SHOULD include 1112 the "Connection: close" header in its response metadata. A sender 1113 SHOULD transmit all outstanding frames related to remaining request/ 1114 response exchanges before ending transmission to the multicast group. 1115 A receiver SHOULD continue to receive and process frames until all 1116 outstanding request/response exchanges are complete. 1118 The HTTP/3 "GOAWAY" frame is prohibited. Participants MUST NOT send 1119 this and reception MUST be handled as described in Section 5.6. 1121 5.5. HTTP/3 Extension frames 1123 HTTP/3 extension frames (e.g. "ALTSVC") are prohibited by this 1124 profile. Participants MUST NOT make any attempt to send extension 1125 frame types. Reception of these MUST be handled as described in 1126 Section 5.6. 1128 5.6. Prohibited HTTP/3 Frames 1130 The following HTTP/3 frames MUST NOT be transmitted by participants: 1131 "GOAWAY", "MAX_PUSH_ID", "SETTINGS". 1133 In addition, all HTTP/3 extension frame types MUST NOT be transmitted 1134 by participants. 1136 The following HTTP/3 frames MUST NOT be transmitted by receivers: 1137 "CANCEL_PUSH". 1139 Reception of a prohibited HTTP/3 frame is a protocol error. 1140 Receivers MUST ignore prohibited HTTP/3 frames. 1142 6. Application-Layer Security 1144 As already described in Section 3.1, the implicit cipher suite used 1145 by a multicast QUIC session makes very limited provision for security 1146 in the transport and session layers. This section profiles the use 1147 of some additional features to provide equivalent functionality at 1148 the application-layer. 1150 6.1. Content Integrity 1152 In many applications, it is important to ensure that an HTTP 1153 representation has been received intact (i.e. has not suffered from 1154 transmission loss or random bit errors) before passing the received 1155 object on to the receiving application. A mechanism is therefore 1156 specified here to provide end-to-end content integrity protection for 1157 HTTP representations in transit. The use of this content integrity 1158 mechanism is RECOMMENDED. 1160 *Authors' Note:* We invite review comments on mandating the use of 1161 this content integrity mechanism. 1163 [RFC3230] specifies an instance digest HTTP header called "Digest". 1164 A sender MAY include this header in the HTTP/3 "HEADERS" frame of any 1165 representation it transmits and a receiver MAY use this header to 1166 validate the integrity of the received representation once it has 1167 been reassembled. Where this validation fails, the receiver SHOULD 1168 discard the representation without processing it further. 1170 Note that the digest value protects a whole HTTP instance (i.e. the 1171 representation of a resource at the point of transmission as opposed 1172 to the body of a particular HTTP message). In cases where partial 1173 representations are fragmented over one or more HTTP response 1174 messages, the digest value is computed over the complete 1175 representation prior to fragmentation into partial responses. 1177 Any of the algorithms specified in the IANA registry of digest 1178 algorithms (http://www.iana.org/assignments/http-dig-alg/http-dig- 1179 alg.xhtml#http-dig-alg-1) MAY be used in conjunction with the 1180 "Digest" header. There is no requirement for participants to support 1181 the full set of algorithms. 1183 6.2. Content Authenticity 1185 In some applications, it is important for a receiver to reassure 1186 itself that an HTTP representation has been received from an 1187 authentic source. It is also sometimes useful for a receiver to know 1188 that the information has not been tampered with in transit by a 1189 malicious intermediate actor. A mechanism is therefore specified 1190 here to prove the authenticity of HTTP messages in transit. The use 1191 of this content authenticity mechanism is RECOMMENDED for senders 1192 implementing this specification. 1194 *Authors' Note:* We invite review comments on mandating the use of 1195 this content authenticity mechanism. 1197 [I-D.cavage-http-signatures] specifies a means of securely signing 1198 metadata associated with any HTTP message. The resulting digital 1199 signature is conveyed in the "Signature" header of the message 1200 itself. The "Signature" header also conveys a list of HTTP header 1201 fields over which the signature was computed. A receiver MAY verify 1202 the "Signature" header in order to validate the authenticity of 1203 received metadata. Where this validation fails, the receiver SHOULD 1204 discard or ignore any related metadata and/or data without processing 1205 it further. 1207 Note that the signature proves the authenticity of the metadata in a 1208 single HTTP message. A "Signature" header MAY be included separately 1209 in the HTTP/3 "PUSH_PROMISE" frame (protecting the request metadata) 1210 and in the final (or only) HTTP/3 "HEADERS" frame relating to a 1211 particular resource (protecting the response metadata). In order to 1212 provide an additional level of protection, however, it is RECOMMENDED 1213 that the signature be computed over the combined request metadata 1214 (from the HTTP/3 "PUSH_PROMISE" frame) and the corresponding response 1215 metadata (from the HTTP/3 "HEADERS" frames) of the same resource. 1216 This binds the request metadata and response metadata together, 1217 providing the receiver with additional reassurance of authenticity. 1218 In this latter case, the combined digital signature SHALL be conveyed 1219 in the final (or only) HTTP/3 "HEADERS" frame. 1221 In applications where the detection of replay attacks is a 1222 requirement, it is RECOMMENDED that the "Date" header be included in 1223 the scope of the signature. It is RECOMMENDED that receivers use the 1224 value of the "Date" header for replay detection using appropriate 1225 strategies (e.g. checking for freshness). The definition of such 1226 strategies is beyond the scope of this document. 1228 In applications where the authenticity and integrity of the 1229 transmission are both important, it is RECOMMENDED that the "Digest" 1230 header specified in Section 6.1 above is included in the scope of the 1231 signature. By signing the instance digest, the authenticity and 1232 integrity of the HTTP message body are also assured in addition to 1233 that of the metadata. 1235 Any of the algorithms specified in the IANA registry of signature 1236 algorithms (http://www.iana.org/assignments/signature-algorithms) MAY 1237 be used in conjunction with the "Signature" header. There is no 1238 requirement for participants to support the full set of algorithms. 1240 6.3. Content Confidentiality 1242 In applications where there is a requirement for the content itself 1243 to remain confidential, appropriate steps SHOULD be taken to protect 1244 the application payload, for example by encrypting it. This document 1245 does not preclude the use of application-level encryption, but does 1246 not specify a mechanism for the distribution of content decryption 1247 keys. 1249 7. Loss Recovery 1251 Because the acknowledgement of received packets to multicast groups 1252 is prohibited by this specification (Section 4.11) the detection of 1253 discarded or corrupted packets is the sole responsibility of the 1254 receiver, and such losses must be recovered by means other than the 1255 retransmission mechanism specified in [QUIC-TRANSPORT] and 1256 [QUIC-RECOVERY]. 1258 7.1. Forward Error Correction 1260 *Authors' Note:* A simple parity-based Forward Error Correction 1261 scheme was removed from the experimental QUIC wire protocol 1262 specification in version Q032. The IETF's QUIC Working Group is 1263 chartered to specify one (or more) new FEC schemes in the future. 1264 This section will track developments in this area, and will be 1265 updated accordingly. 1267 A sender MAY make use of a suitable Forward Error Correction scheme 1268 to allow a receiver to reconstruct lost packets from those that have 1269 been successfully received. 1271 7.2. Unicast Repair 1273 In the case where a lost QUIC packet cannot be recovered using 1274 Forward Error Correction, either because the number of packets lost 1275 exceeds the scheme's threshold for reconstruction, or because FEC is 1276 not in use on the multicast QUIC session, a receiver MAY instead 1277 recover the missing payload data using conventional unicast HTTP 1278 requests to an origin server. 1280 o The total size of the resource is indicated in the "content- 1281 length" response header carried in the HTTP/3 "HEADERS" frame. 1283 o The location of the missing data can be determined by examining 1284 the Offset field in the QUIC "STREAM" frame headers of 1285 successfully received QUIC packets. 1287 Using this information, a receiver MAY compose an efficient HTTP 1288 range request [RFC7233] to the origin server indicated in the URL. 1289 Several disjoint ranges MAY be combined into a single HTTP request. 1290 A receiver MAY direct its request to an alternative server using Alt- 1291 Svc information received on the multicast QUIC session, or else 1292 received as part of a previous unicast HTTP response according to the 1293 rules in [RFC7838]. 1295 8. Transmission of Partial Content 1297 Under certain circumstances, a sender may not be in full possession 1298 of a resource body when transmission begins, or may not be able to 1299 guarantee that a transmission will complete. In such cases, the 1300 sender MAY employ the syntax of an HTTP range request [RFC7233] to 1301 indicate partial content, as specified below. All receivers SHALL 1302 implement support for such HTTP range requests. 1304 If partial content is to be transmitted: 1306 o The "range" header (Section 3.1 of [RFC7233]) SHALL be present in 1307 the HTTP/3 "PUSH_PROMISE" frame. 1309 o The corresponding HTTP/3 "HEADERS" frame SHALL indicate HTTP 1310 status code 206. 1312 * The range being transmitted SHALL be indicated in a "content- 1313 range" header field and the size of the complete resource 1314 indicated in a "content-length" header field. 1316 9. Protocol Identifier 1318 The HTTP over multicast QUIC protocol specified in this document is 1319 identified by the application-layer protocol negotiation (ALPN) 1320 [RFC7301] identifier "h3m". The IANA registration of this protocol 1321 identifier can be found in Section 12.1. This reserves the ALPN 1322 identifier space but describes a protocol that does not use TLS. The 1323 usage of the "h3m" identifier for discoverability is described in 1324 Section 10. 1326 9.1. Draft Version Identification 1328 *RFC Editor's Note:* Please remove this section prior to 1329 publication of a final version of this document. 1331 Only implementations of the final, published RFC can identify 1332 themselves as "h3m". Until such an RFC exists, implementations MUST 1333 NOT identify themselves using this string. 1335 Implementations of draft versions of the protocol MUST add the string 1336 "-" and the corresponding draft number to the identifier. For 1337 example, draft-pardue-quic-http-mcast-06 is identified using the 1338 string "h3m-06". 1340 Non-compatible experiments that are based on these draft versions 1341 MUST append the string "-" and an experiment name to the identifier. 1342 For example, an experimental implementation based on draft-pardue- 1343 quic-http-mcast-06 which uses extension features not registered with 1344 the appropriate IANA registry might identify itself as "h3m-06- 1345 extension-foo". Note that any label MUST conform to the "token" 1346 syntax defined in Section 3.2.6 of [RFC7230]. Experimenters are 1347 encouraged to coordinate their experiments. 1349 10. Discovery of Multicast QUIC Sessions 1351 The announcement and discovery of services operating over multicast 1352 IP has previously been specified by the Session Description Protocol 1353 (SDP) [RFC4566], Session Announcement Protocol [RFC2974] and Session 1354 Initiation Protocol [RFC3261]. These are typically deployed together 1355 and in conjunction with a multicast-friendly transport such as the 1356 Real-time Transport Protocol (RTP) [RFC3550]. 1358 In contrast, the present document specifies a mechanism for 1359 advertising services that is built into HTTP metadata and is 1360 consistent across unicast and multicast resource delivery modes. 1361 This means that a single application-layer can be used for service 1362 advertisement/discovery, and for bulk data transmission/reception. 1363 Specifically, the "Alt-Svc" HTTP header is specified as the means to 1364 advertise multicast services from a unicast service. A unicast HTTP 1365 response MAY be decorated with an Alt-Svc value that hints to the 1366 client about the availability of the resource via a multicast QUIC 1367 session. A client that supports such a multicast QUIC session MAY 1368 then transparently switch to it. 1370 Symmetrically, the "Alt-Svc" header can also be used to advertise the 1371 unicast service from a multicast service. A resource transmitted as 1372 part of a multicast QUIC session MAY be decorated with an Alt-Svc 1373 value that hints to the client about the availability of the resource 1374 via an alternative unicast HTTP server. A receiver MAY then use this 1375 HTTP server for unicast resource patching (Section 7.2). 1377 Where HTTP over multicast QUIC sessions are advertised using Alt-Svc, 1378 the protocol identifier SHALL be "h3m", as specified in Section 9. 1380 10.1. Source-specific Multicast Advertisement 1382 Source-specific multicast (SSM) [RFC4607] MAY be used for the 1383 delivery of multicast services. 1385 *Authors' Note:* We invite review comments on mandating the use of 1386 source-specific multicast only. 1388 This document specifies the "source-address" parameter for Alt-Svc, 1389 which is used to provide the SSM source address to endpoints. 1391 Syntax: 1393 source-address = uri-host; see RFC7230, Section 2.7 1395 For example: 1397 source-address=192.0.2.1 1399 When a multicast QUIC session is provided using SSM, the "source- 1400 address" parameter MUST be advertised. If the parameter is repeated, 1401 the first occurrence MUST be used and subsequent occurrences MUST be 1402 ignored. 1404 10.2. Session Parameter Advertisement 1406 The concept of session parameters is introduced in Section 2.2. This 1407 section details how the session parameters are expressed as Alt-Svc 1408 parameters. 1410 10.2.1. Cipher Suite 1412 This document specifies the "cipher-suite" parameter for Alt-Svc, 1413 which carries the cipher suite in use by a multicast QUIC session. 1414 "cipher-suite" MUST contain one of the values contained in the TLS 1415 Cipher Suite Registry (http://www.iana.org/assignments/tls- 1416 parameters/tls-parameters.xhtml#tls-parameters-4): 1418 Syntax: 1420 cipher-suite = 4*4 HEXDIG 1422 For example, the following specifies cipher suite 0x13,0x01 1423 ("TLS_AES_128_GCM_SHA256"): 1425 cipher-suite=1301 1426 The requirements for endpoint usage of "cipher-suite" are described 1427 in Section 3.1. 1429 10.2.2. Session Key 1431 This document specifies the "key" parameter for Alt-Svc, which 1432 carries the cryptographic key in use by the multicast QUIC session. 1434 Syntax: 1436 key = *HEXDIG 1438 For example: 1440 key=4adf1eab9c2a37fd 1442 The requirements for endpoint usage of "key" are described in 1443 Section 3.1. 1445 10.2.3. Session Cipher Initialization Vector 1447 This document specifies the "iv" parameter for Alt-Svc, which carries 1448 the cipher Initialization Vector (IV) in use by the multicast QUIC 1449 session. 1451 Syntax: 1453 iv = *HEXDIG 1455 For example: 1457 iv=4dbe593acb4d1577ad6ba7dc3189834e 1459 The requirements for endpoint usage of "iv" are described in 1460 Section 3.1. 1462 10.2.4. Session Identification 1464 This document defines the "session-id" parameter for Alt-Svc, which 1465 carries the multicast QUIC session identifier. 1467 Syntax: 1469 session-id = *HEXDIG 1471 For example, the following specifies session 101 (0x65 hexadecimal): 1473 session-id=65 1474 The requirements for endpoint usage of "session-id" are described in 1475 Section 2.3. In the above example, the Destination Connection ID 1476 field in every QUIC packet header would be one byte in size. For a 1477 session-id of BADBEEF then then Destintation Connection ID field in 1478 every QUIC packet header would be four bytes in size. 1480 10.2.5. Session Idle Timeout Period 1482 This document specifies the "session-idle-timeout" parameter for Alt- 1483 Svc, which carries the idle timeout period in milliseconds of a 1484 multicast QUIC session. 1486 Syntax: 1488 session-idle-timeout = *DIGIT ; integer milliseconds 1490 For example, the following specifies a one-minute session idle 1491 timeout period: 1493 session-idle-timeout=60 1495 The requirements for endpoint usage of "session-idle-timeout" are 1496 described in Section 3.3. 1498 10.2.6. Resource Concurrency 1500 This document specifies the "max-concurrent-resources" parameter for 1501 Alt-Svc, which expresses the maximum number of concurrent active 1502 resources from the sender in a multicast QUIC session. 1504 Syntax: 1506 max-concurrent-resources = *DIGIT ; unsigned 32-bit integer 1508 For example, the following specifies that no more than 12 (decimal) 1509 resources will be concurrently active in the session: 1511 max-concurrent-resources=12 1513 The requirements for endpoint usage of "max-concurrent-resources" are 1514 described in Section 3.5. 1516 10.2.7. Session Peak Flow Rate 1518 This document specifies the "peak-flow-rate" parameter for Alt-Svc, 1519 which expresses the expected maximum aggregate transfer rate of data 1520 from all sources of the multicast QUIC session. 1522 Syntax: 1524 peak-flow-rate = *DIGIT ; bits per second 1526 For example, the following specifies a peak flow rate of 550 kbits/s 1527 in the session: 1529 peak-flow-rate=550000 1531 The requirements for endpoint usage of "peak-flow-rate" are described 1532 in Section 3.4. 1534 10.2.8. Digest Algorithm 1536 This document specifies the "digest-algorithm" parameter for Alt-Svc, 1537 which carries the digest algorithm in use by a multicast QUIC 1538 session. "digest-algorithm" MUST contain one of the values defined in 1539 the HTTP Digest Algorithm Values registry 1540 (https://www.iana.org/assignments/http-dig-alg/http-dig- 1541 alg.xhtml#http-dig-alg-1). 1543 Syntax: 1545 digest-algorithm = token 1547 For example, the following specifies a digest algorithm of SHA-256: 1549 digest-algorithm=SHA-256 1551 The requirements for endpoint usage of "digest-algorithm" are 1552 described in Section 3.7. 1554 10.2.9. Signature Algorithm 1556 This document specifies the "signature-algorithm" parameter for Alt- 1557 Svc, which carries the signature algorithm in use by a multicast QUIC 1558 session. "signature-algorithm" MUST contain one of the values defined 1559 in the Signature Algorithms registry 1560 (http://www.iana.org/assignments/signature-algorithms). 1562 Syntax: 1564 signature-algorithm = token 1566 For example, the following specifies a signature algorithm of SHA- 1567 256: 1569 signature-algorithm=rsa-sha256 1570 The requirements for endpoint usage of "signature-algorithm" are 1571 described in Section 3.8. 1573 10.2.10. Extensions 1575 This document specifies the "extensions" parameter for Alt-Svc, which 1576 carries a list of extension types potentially in use by a multicast 1577 QUIC session. "extensions" MUST only contain values from the QUIC 1578 Transport Parameter registry ([QUIC-TRANSPORT], section 22.2) that 1579 have explicit support for multicast QUIC. Each entry in the list 1580 consists of a key identifying the transport parameter, and an 1581 optional value. Both the key and the value are hex-encoded. 1583 Syntax: 1585 extensions = DQUOTE ext-transport-param *[ "," ext-transport-param ] DQUOTE 1586 ext-transport-param = ext-key [ "=" ext-value ] 1587 ext-key = 4*4HEXDIG; Transport Parameter key 1588 ext-value = *HEXDIG; Optional Transport Parameter value 1590 For example, the following specifies two extensions: 1592 extensions="0094,0d0d=f00" 1594 The requirements for endpoint usage of "extensions" are described in 1595 Section 3.6 1597 11. Security and Privacy Considerations 1599 This document specifies a profile of QUIC and HTTP/3 that changes the 1600 security model. In order to address this, application-level security 1601 methods are described in Section 6. This document does not preclude 1602 the use of secure multicast approaches that may provide additional 1603 security assurances required for certain use cases. 1605 The use of side-channel or out-of-band technologies (potentially 1606 bidirectional interactions) to support multicast QUIC sessions are 1607 considered out of this document's scope. Services using such 1608 technologies should apply their security considerations accordingly. 1610 11.1. Pervasive Monitoring 1612 Certain multicast deployment architectures may require the use of a 1613 session decryption key shared by all participants. Furthermore, the 1614 discovery mechanism described in this document provides a means for a 1615 receiver to obtain a session decryption key without joining the 1616 session. The act of removing packet protection in order to inspect 1617 or modify application contents may, in certain deployments, be 1618 trivial. The exploration of restricting key learning or session 1619 joining to authorised participants goes beyond the scope of this 1620 document. 1622 Because in-band multicast interactions are unidirectional, the impact 1623 of Pervasive Monitoring [RFC7258] on in-band traffic flows is 1624 inherently reduced. Actors can only inspect or modify sender- 1625 initiated traffic. Additional measures for content confidentiality 1626 may mitigate the impact further. This is discussed in Section 6.3. 1628 Further Pervasive Monitoring concerns are addressed in the following 1629 sections. 1631 11.1.1. Large-scale Data Gathering and Correlation 1633 Multicast QUIC sessions decouple sending and receiving participants. 1634 Session participation is subject to operations that allow an endpoint 1635 to join or leave a multicast group, typically IGMP [RFC3376] or MLD 1636 [RFC3810]. The propagation intent of these messages travelling 1637 deeper through a network hierarchy generally leads to the 1638 anonymisation of data if implemented as specified. It may be 1639 possible to gather user-identifiable messages close to the network 1640 edge, for example a router logging such messages. However, this 1641 would require wide-ranging access across Internet Service Provider 1642 networks. Therefore, while such attacks are feasible, it can be 1643 asserted that gathering and correlating user-identifiable traffic is 1644 difficult to perform covertly and at scale. 1646 11.1.2. Changing Content 1648 Sessions that use a symmetric key for packet protection are subject 1649 to the possibility of a malicious actor modifying traffic at some 1650 point in the network between a legitimate sender and one (or more) 1651 receivers. Receiver-side validation, as specified in Section 6 of 1652 the present document, and also in [QUIC-TRANSPORT], allows for the 1653 detection of such modification. Two approaches help mitigate the 1654 impact of modification; the first is application-level methods that 1655 protect data (Section 6.1) and metadata (Section 6.2); the second is 1656 reduction of the QUIC packet attack surface by means of removal of 1657 many frame types (Section 4.12 and Section 5.6). 1659 11.2. Protection of Discovery Mechanism 1661 Multicast QUIC session advertisements SHOULD be conveyed over a 1662 secure transport that guarantees authenticity and integrity in order 1663 to mitigate attacks related to a malicious service advertisement, for 1664 example a "man in the middle" directing endpoints to a service that 1665 may lead to other attacks or exploitations. 1667 *Authors' Note:* We invite review comments on mandating the use of 1668 a secure transport for advertising sessions. 1670 Endpoints that make use of multicast QUIC session advertisements 1671 SHOULD have reasonable assurance that the alternative service is 1672 under control of, and valid for, the whole origin, as described in 1673 Section 2.1 of [RFC7838]. Section 6.2 discusses measures that may be 1674 used to fulfil this requirement. 1676 11.3. Spoofing 1678 11.3.1. Spoofed Ack Attacks 1680 The Spoofed "ACK" attack described in Section 13.1 of 1681 [QUIC-TRANSPORT] is out of scope because use of the QUIC "ACK" frame 1682 is prohibited (Section 4.11) by the present document. 1684 11.3.2. Sender Spoofing 1686 A malicious actor may be able to stage a spoof attack by sending fake 1687 QUIC packets to a multicast QUIC session. This could affect the 1688 operation or behaviour of receivers. In a multicast scenario, this 1689 form of attack has the potential to scale massively. 1691 The feasibility of spoofing a multicast sender is governed by the 1692 characteristics of the multicast deployment and network 1693 infrastructure. The use of source-specific multicast [RFC4607] may 1694 reduce the feasibility. The use of content authenticity 1695 (Section 6.2) may mitigate concerns for the application-level 1696 messages. However, there remains the possibility for transport-level 1697 messages to be spoofed. Multicast applications should consider 1698 further mitigations to address this concern. 1700 11.3.3. Receiver Spoofing 1702 Client source address concerns discussed in Section 7.5 of 1703 [QUIC-TRANSPORT] are out of scope because the connection 1704 establishment is replaced with session establishment in the present 1705 document. Further, the impact that spoofed receivers would have on 1706 the sender is minimal. The impact of malicious participants on the 1707 network is discussed in Section 11.6.2. 1709 11.4. Replay Attacks 1711 Conventional QUIC strategies for protecting against replay attacks 1712 apply similarly here. 1714 Certain multicast QUIC sessions may use a shared key for transport- 1715 level encryption, which would allow an attacker to record, decrypt, 1716 repackage and replay QUIC packets. Section 6.2 discusses how the 1717 application-level contents may be protected from replay (by signing 1718 the "Date" HTTP header), which provides some mitigation to the 1719 success rate or effects of replay attacks. 1721 11.5. Message Deletion 1723 Since HTTP over multicast QUIC is designed to tolerate unreliable 1724 delivery, the impacts of message deletion attacks are presumed to be 1725 small. Deletion of packets carrying HTTP headers will cause a 1726 receiver to ignore subsequent packets carrying body data. 1727 Furthermore, the use of multicast QUIC sessions is opportunistic; 1728 disruption in service (for example, deleting packets and causing a 1729 receiver to fail in construction of a content object) is mitigated by 1730 falling back to a unicast service. Considerations for how this may 1731 affect the performance of the unicast service are given in 1732 Section 11.6.3. 1734 11.6. Denial of Service 1736 11.6.1. Unprotected Frames and Packets 1738 The handling of unprotected QUIC packets is discussed in section 1739 9.1.4 of [QUIC-TLS]. The profile described in the present document 1740 provides the means for a multicast sender to protect QUIC packets 1741 with a shared key, which is not a strong protection. The weak 1742 protection of QUIC packets could present a denial-of-service risk. 1743 To mitigate the impact of handling such QUIC packets, certain frames 1744 and packets are prohibited as described in (Section 4.12 and 1745 Section 5.6). 1747 The frame types that are allowed by this profile do not present a 1748 risk of denial of service. Concerns over authenticity and integrity 1749 are addressed by the application-layer protection mechanisms 1750 described in Section 6. 1752 11.6.2. Network Performance Degradation 1754 The possibility for malfunctioning or malicious participants to 1755 degrade the network is a broad issue and considered out of scope for 1756 this document. Guidelines and concerns discussed in UDP Best 1757 Practices [RFC8085] and other sources apply equally here. This 1758 specification does not preclude the use of network performance 1759 degradation mitigation solutions such as network circuit breakers. 1761 11.6.3. Unicast Repair Stampeding Herd 1763 Deployments that support the unicast repair mechanism described in 1764 Section 7.2 should be aware that a triggering of this behaviour 1765 (either deliberate, planned or unplanned) in a large population of 1766 multicast receivers may cause a stampeding herd of client requests to 1767 the unicast repair service. Service operators SHOULD mitigate the 1768 impact of stampeding herd on their deployment. 1770 11.7. Receiver Resource Usage 1772 The application of receiver-side validation, as defined in the 1773 present document and in [QUIC-TRANSPORT], adds some protection 1774 against allocating resource to the processing of bad data. 1776 11.8. Unicast Repair Information Leakage 1778 The unicast repair mechanism may lead to the leakage of user 1779 behaviour data. An attacker could gain insight into any receiver 1780 participating in a multicast QUIC session, for example by monitoring 1781 the TCP port of the unicast alternative. This alone is no worse than 1782 current abilities to monitor unicast interactions, for example 1783 observing the SNI field contained in a TLS ClientHello. The complete 1784 protection of unicast interactions is beyond the scope of this 1785 document. However, knowledge that a user (or group of users) has 1786 participated in a session is sensitive and may be obtained by 1787 correlation between with observable multicast and unicast traffic. 1789 To give an example, a malicious "man in the middle" could purposely 1790 cause all receivers to perform a unicast repair (by disrupting the 1791 QUIC traffic flow in some way). The disruption is untargeted and may 1792 be simple to orchestrate, but the correlation of user activity data, 1793 especially across a distributed repair service (e.g. a CDN), requires 1794 resources that may reduce the attractiveness of such an attack. 1796 The ability for an attacker to disrupt multicast QUIC sessions is 1797 mitigated by this profile (mainly the prohibition of frames and 1798 packets). Application-layer security measures described in Section 6 1799 reduce the feasibility further. 1801 Multicast receivers concerned about this form of leakage can 1802 eliminate this risk completely by disabling support for unicast 1803 repair, at the potential cost of reduced service quality. 1805 12. IANA Considerations 1807 12.1. Registration of Protocol Identification String 1809 This document creates a new registration for the identification of 1810 the HTTP over multicast QUIC protocol in the "Application-Layer 1811 Protocol Negotiation (ALPN) Protocol IDs" registry established by 1812 [RFC7301]. 1814 The "h3m" string identifies HTTP semantics expressed as HTTP mapped 1815 to a QUIC layer and carried over IP multicast: 1817 Protocol: Bulk data transport using HTTP over multicast QUIC 1819 Identification Sequence: 0x68 0x33 0x6D ("h3m") 1821 Specification: This document, Section 9 1823 This entry reserves an identifier that is not allowed to appear in 1824 TLS Application-Layer Protocol Negotiation. 1826 12.2. Registration of Alt-Svc parameters 1828 This document creates seven registrations for the identification of 1829 parameters for the "Hypertext Transfer Protocol (HTTP) Alt-Svc 1830 Parameter Registry" established by [RFC7838] 1831 (http://www.iana.org/assignments/tls-extensiontype-values/tls- 1832 extensiontype-values.xhtml#alpn-protocol-ids). 1834 12.2.1. Source Address 1836 Parameter name: source-address 1838 Specification: This document, Section 10.1 1840 12.2.2. Cipher Suite 1842 Parameter name: cipher-suite 1844 Specification: This document, Section 10.2.1 1846 12.2.3. Key 1848 Parameter name: key 1850 Specification: This document, Section 10.2.2 1852 12.2.4. Initialization Vector 1854 Parameter name: iv 1856 Specification: This document, Section 10.2.3 1858 12.2.5. Session Identifier 1860 Parameter name: session-id 1862 Specification: This document, Section 10.2.4 1864 12.2.6. Session Idle Timeout 1866 Parameter name: session-idle-timeout 1868 Specification: This document, Section 10.2.5 1870 12.2.7. Maximum Concurrent Resources 1872 Parameter name: max-concurrent-resources 1874 Specification: This document, Section 10.2.6 1876 12.2.8. Peak Flow Rate 1878 Parameter name: peak-flow-rate 1880 Specification: This document, Section 10.2.7 1882 12.2.9. Digest Algorithm 1884 Parameter name: digest-algorithm 1886 Specification: This document, Section 10.2.8 1888 12.2.10. Signature Algorithm 1890 Parameter name: signature-algorithm 1892 Specification: This document, Section 10.2.9 1894 12.2.11. Extension 1896 Parameter name: extension 1898 Specification: This document, Section 10.2.10 1900 13. References 1902 13.1. Normative References 1904 [I-D.cavage-http-signatures] 1905 Cavage, M. and M. Sporny, "Signing HTTP Messages", draft- 1906 cavage-http-signatures-12 (work in progress), October 1907 2019. 1909 [QUIC-HTTP] 1910 Bishop, M., Ed., "Hypertext Transfer Protocol Version 3 1911 (HTTP/3)", draft-ietf-quic-http-29 (work in progress). 1913 [QUIC-QPACK] 1914 Krasic, C., Ed., Bishop, M., Ed., and A. Frindell, Ed., 1915 "QPACK: Header Compression for HTTP over QUIC", draft- 1916 ietf-quic-qpack-16 (work in progress). 1918 [QUIC-TRANSPORT] 1919 Iyengar, J., Ed. and M. Thomson, Ed., "QUIC: A UDP-Based 1920 Multiplexed and Secure Transport", draft-ietf-quic- 1921 transport-29 (work in progress). 1923 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 1924 Requirement Levels", BCP 14, RFC 2119, 1925 DOI 10.17487/RFC2119, March 1997, 1926 . 1928 [RFC3168] Ramakrishnan, K., Floyd, S., and D. Black, "The Addition 1929 of Explicit Congestion Notification (ECN) to IP", 1930 RFC 3168, DOI 10.17487/RFC3168, September 2001, 1931 . 1933 [RFC3230] Mogul, J. and A. Van Hoff, "Instance Digests in HTTP", 1934 RFC 3230, DOI 10.17487/RFC3230, January 2002, 1935 . 1937 [RFC4607] Holbrook, H. and B. Cain, "Source-Specific Multicast for 1938 IP", RFC 4607, DOI 10.17487/RFC4607, August 2006, 1939 . 1941 [RFC5234] Crocker, D., Ed. and P. Overell, "Augmented BNF for Syntax 1942 Specifications: ABNF", STD 68, RFC 5234, 1943 DOI 10.17487/RFC5234, January 2008, 1944 . 1946 [RFC7230] Fielding, R., Ed. and J. Reschke, Ed., "Hypertext Transfer 1947 Protocol (HTTP/1.1): Message Syntax and Routing", 1948 RFC 7230, DOI 10.17487/RFC7230, June 2014, 1949 . 1951 [RFC7233] Fielding, R., Ed., Lafon, Y., Ed., and J. Reschke, Ed., 1952 "Hypertext Transfer Protocol (HTTP/1.1): Range Requests", 1953 RFC 7233, DOI 10.17487/RFC7233, June 2014, 1954 . 1956 [RFC7234] Fielding, R., Ed., Nottingham, M., Ed., and J. Reschke, 1957 Ed., "Hypertext Transfer Protocol (HTTP/1.1): Caching", 1958 RFC 7234, DOI 10.17487/RFC7234, June 2014, 1959 . 1961 [RFC7301] Friedl, S., Popov, A., Langley, A., and E. Stephan, 1962 "Transport Layer Security (TLS) Application-Layer Protocol 1963 Negotiation Extension", RFC 7301, DOI 10.17487/RFC7301, 1964 July 2014, . 1966 [RFC7405] Kyzivat, P., "Case-Sensitive String Support in ABNF", 1967 RFC 7405, DOI 10.17487/RFC7405, December 2014, 1968 . 1970 [RFC7838] Nottingham, M., McManus, P., and J. Reschke, "HTTP 1971 Alternative Services", RFC 7838, DOI 10.17487/RFC7838, 1972 April 2016, . 1974 [RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC 1975 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, 1976 May 2017, . 1978 13.2. Informative References 1980 [QUIC-RECOVERY] 1981 Iyengar, J., Ed. and I. Swett, Ed., "QUIC Loss Detection 1982 and Congestion Control", draft-ietf-quic-recovery-29 (work 1983 in progress). 1985 [QUIC-TLS] 1986 Thomson, M., Ed. and S. Turner, Ed, Ed., "Using Transport 1987 Layer Security (TLS) to Secure QUIC", draft-ietf-quic- 1988 tls-29 (work in progress). 1990 [RFC1112] Deering, S., "Host extensions for IP multicasting", STD 5, 1991 RFC 1112, DOI 10.17487/RFC1112, August 1989, 1992 . 1994 [RFC1191] Mogul, J. and S. Deering, "Path MTU discovery", RFC 1191, 1995 DOI 10.17487/RFC1191, November 1990, 1996 . 1998 [RFC2974] Handley, M., Perkins, C., and E. Whelan, "Session 1999 Announcement Protocol", RFC 2974, DOI 10.17487/RFC2974, 2000 October 2000, . 2002 [RFC3261] Rosenberg, J., Schulzrinne, H., Camarillo, G., Johnston, 2003 A., Peterson, J., Sparks, R., Handley, M., and E. 2004 Schooler, "SIP: Session Initiation Protocol", RFC 3261, 2005 DOI 10.17487/RFC3261, June 2002, 2006 . 2008 [RFC3376] Cain, B., Deering, S., Kouvelas, I., Fenner, B., and A. 2009 Thyagarajan, "Internet Group Management Protocol, Version 2010 3", RFC 3376, DOI 10.17487/RFC3376, October 2002, 2011 . 2013 [RFC3550] Schulzrinne, H., Casner, S., Frederick, R., and V. 2014 Jacobson, "RTP: A Transport Protocol for Real-Time 2015 Applications", STD 64, RFC 3550, DOI 10.17487/RFC3550, 2016 July 2003, . 2018 [RFC3810] Vida, R., Ed. and L. Costa, Ed., "Multicast Listener 2019 Discovery Version 2 (MLDv2) for IPv6", RFC 3810, 2020 DOI 10.17487/RFC3810, June 2004, 2021 . 2023 [RFC4566] Handley, M., Jacobson, V., and C. Perkins, "SDP: Session 2024 Description Protocol", RFC 4566, DOI 10.17487/RFC4566, 2025 July 2006, . 2027 [RFC4821] Mathis, M. and J. Heffner, "Packetization Layer Path MTU 2028 Discovery", RFC 4821, DOI 10.17487/RFC4821, March 2007, 2029 . 2031 [RFC5737] Arkko, J., Cotton, M., and L. Vegoda, "IPv4 Address Blocks 2032 Reserved for Documentation", RFC 5737, 2033 DOI 10.17487/RFC5737, January 2010, 2034 . 2036 [RFC5740] Adamson, B., Bormann, C., Handley, M., and J. Macker, 2037 "NACK-Oriented Reliable Multicast (NORM) Transport 2038 Protocol", RFC 5740, DOI 10.17487/RFC5740, November 2009, 2039 . 2041 [RFC6676] Venaas, S., Parekh, R., Van de Velde, G., Chown, T., and 2042 M. Eubanks, "Multicast Addresses for Documentation", 2043 RFC 6676, DOI 10.17487/RFC6676, August 2012, 2044 . 2046 [RFC6726] Paila, T., Walsh, R., Luby, M., Roca, V., and R. Lehtonen, 2047 "FLUTE - File Delivery over Unidirectional Transport", 2048 RFC 6726, DOI 10.17487/RFC6726, November 2012, 2049 . 2051 [RFC7258] Farrell, S. and H. Tschofenig, "Pervasive Monitoring Is an 2052 Attack", BCP 188, RFC 7258, DOI 10.17487/RFC7258, May 2053 2014, . 2055 [RFC7450] Bumgardner, G., "Automatic Multicast Tunneling", RFC 7450, 2056 DOI 10.17487/RFC7450, February 2015, 2057 . 2059 [RFC8085] Eggert, L., Fairhurst, G., and G. Shepherd, "UDP Usage 2060 Guidelines", BCP 145, RFC 8085, DOI 10.17487/RFC8085, 2061 March 2017, . 2063 [RFC8200] Deering, S. and R. Hinden, "Internet Protocol, Version 6 2064 (IPv6) Specification", STD 86, RFC 8200, 2065 DOI 10.17487/RFC8200, July 2017, 2066 . 2068 Appendix A. Acknowledgements 2070 The authors would like to thank the following for their contributions 2071 to the design described in the present document: Brandon Butterworth, 2072 Chris Poole, Craig Taylor and David Waring. 2074 We are also grateful to Thomas Swindells and Magnus Westerlund for 2075 their helpful review comments. 2077 Appendix B. Examples 2079 This appendix contains examples of multicast QUIC session 2080 advertisement and resource transfer (with and without application- 2081 layer content security). 2083 B.1. Session Advertisement 2085 This section shows several different examples of an HTTP service 2086 advertising a multicast QUIC session. Examples are given in IPv4 2087 form, using reserved address ranges as specified in [RFC5737] and 2088 [RFC6676]. 2090 B.1.1. Source-specific Multicast QUIC Session 2092 Advertisement of a multicast QUIC session operating on the source- 2093 specific multicast group address 232.0.0.1 on port 2000 with the 2094 source address 192.0.2.1. The session ID is 16 (0x10) and the idle 2095 timeout is one minute. At most 10 resources may be concurrently 2096 active in the session and the flow rate should not exceed 10 kbits/s. 2097 The multicast transport is unencrypted. 2099 HTTP Alternative Service header field: 2101 Alt-Svc: 2102 h3m="232.0.0.1:2000"; source-address="192.0.2.1"; 2103 session-id=10; session-idle-timeout=60; 2104 max-concurrent-resources=10; peak-flow-rate=10000 2106 B.1.2. Source-specific Multicast QUIC Session with Transport Encryption 2107 using a Symmetric Key 2109 Advertisement of a multicast QUIC session operating on the IPv6 2110 globally-scoped source-specific multicast group address ff3e::1234 on 2111 port 2000 with the source address 2001:db8::1. The session ID is 16 2112 (0x10) and the idle timeout is one minute. At most 10 resources may 2113 be concurrently active in the session and the flow rate should not 2114 exceed 10 kbits/s. The multicast transport is encrypted using the 2115 AEAD cipher suite 0x13,0x01 ("TLS_AES_128_GCM_SHA256") with the 2116 shared session key and IV provided. 2118 HTTP Alternative Service header field: 2120 Alt-Svc: 2121 h3m="[ff3e::1234]:2000"; source-address="2001:db8::1"; 2122 session-id=10; session-idle-timeout=60; 2123 max-concurrent-resources=10; peak-flow-rate=10000; 2124 cipher-suite=1301; key=4adf1eab9c2a37fd; 2125 iv=4dbe593acb4d1577ad6ba7dc3189834e 2127 B.1.3. Source-specific Multicast QUIC Session with Transport 2128 Encryption, Content Integrity and Authenticity 2130 Advertisement of a multicast QUIC session operating on the IPv6 2131 globally-scoped source-specific multicast group address ff3e::1234 on 2132 port 2000 with the source address 2001:db8::1. The session ID is 16 2133 (0x10) and the idle timeout is one minute. At most 10 resources may 2134 be concurrently active in the session and the flow rate should not 2135 exceed 10 kbits/s. The multicast transport is encrypted using the 2136 AEAD cipher suite 0x13,0x01 ("TLS_AES_128_GCM_SHA256") with the 2137 shared session key and IV provided. Content integrity is in use with 2138 the digest algorithm set restricted to SHA-256. Content authenticity 2139 is in use with the signature algorithm set restricted to rsa-sha256. 2141 HTTP Alternative Service header field: 2143 Alt-Svc: 2144 h3m="[ff3e::1234]:2000"; source-address="2001:db8::1"; 2145 session-id=10; session-idle-timeout=60; 2146 max-concurrent-resources=10; peak-flow-rate=10000; 2147 cipher-suite=1301; key=4adf1eab9c2a37fd; 2148 iv=4dbe593acb4d1577ad6ba7dc3189834e; 2149 digest-algorithm=SHA-256; signature-algorithm=rsa-sha256 2151 B.2. Resource Transfer 2153 This section shows several different examples of the HTTP message 2154 patterns for a single resource. 2156 Examples that show HTTP/3 "PUSH_PROMISE" or "HEADERS" frames describe 2157 the contents of enclosed header block fragments. 2159 B.2.1. Transfer without Content Integrity or Authenticity 2161 HTTP/3 "PUSH_PROMISE" frame: 2163 :method: GET 2164 :scheme: https 2165 :path: /files/example.txt 2166 :authority: example.org 2168 HTTP/3 "HEADERS" frame: 2170 :status: 200 2171 content-length: 100 2172 content-type: text/plain 2173 date: Fri, 20 Jan 2017 10:00:00 GMT 2175 HTTP/3 "DATA" frame containing 100 bytes of response body data: 2177 ... 2179 B.2.2. Transfer of Partial Content without Content Integrity or 2180 Authenticity 2182 In this example, partial content is transferred as described in 2183 Section 8. The "Range" request header is used to indicate the 2184 sender's original intention to transfer all 100 bytes of the 2185 representation. The "Content-Range" response header indicates that 2186 only the first 50 bytes were actually sent. 2188 HTTP/3 "PUSH_PROMISE" frame: 2190 :method: GET 2191 :scheme: https 2192 :path: /files/example.txt 2193 :authority: example.org 2194 range: bytes=0-* 2196 HTTP/3 "HEADERS" frame: 2198 :status: 206 2199 content-length: 100 2200 content-range: bytes 0-49/100 2201 content-type: text/plain 2202 date: Fri, 20 Jan 2017 10:00:00 GMT 2204 HTTP/3 "DATA" frame containing 50 bytes of response body data: 2206 ... 2208 B.2.3. Transfer with Content Integrity and without Authenticity 2210 In this example, content integrity is assured by the inclusion of the 2211 "Digest" response header, as described in Section 6.1. 2213 HTTP/3 "PUSH_PROMISE" frame: 2215 :method: GET 2216 :scheme: https 2217 :path: /files/example.txt 2218 :authority: example.org 2220 HTTP/3 "HEADERS" frame including the "Digest" header: 2222 :status: 200 2223 content-length: 100 2224 content-type: text/plain 2225 date: Fri, 20 Jan 2017 10:00:00 GMT 2226 digest: SHA-256=DieQ9zfRaDdyAilTVCvmBePuxMm+B6cNocP+QCrNSqo= 2228 HTTP/3 "DATA" frame containing 100 bytes of response body data: 2230 ... 2232 B.2.4. Partial Transfer with Content Integrity and without Authenticity 2234 In this example, partial content is transferred as described in 2235 Section 8. The "Range" request header is used to indicate the 2236 sender's intention to transfer all 100 bytes of the representation. 2237 The "Content-Range" response header indicates that only the first 50 2238 bytes were actually sent. Content integrity is assured by the 2239 inclusion of the "Digest" response header, as described in 2240 Section 6.1. 2242 HTTP/3 "PUSH_PROMISE" frame: 2244 :method: GET 2245 :scheme: https 2246 :path: /files/example.txt 2247 :authority: example.org 2248 range: bytes=0-* 2250 HTTP/3 "HEADERS" frame including the "Digest" header: 2252 :status: 206 2253 content-length: 100 2254 content-range: bytes 0-49/100 2255 content-type: text/plain 2256 date: Fri, 20 Jan 2017 10:00:00 GMT 2257 digest: SHA-256=DieQ9zfRaDdyAilTVCvmBePuxMm+B6cNocP+QCrNSqo= 2259 HTTP/3 "DATA" frame containing 50 bytes of response body data: 2261 ... 2263 B.2.5. Transfer with Content Integrity and Authenticity 2265 In this example, content integrity is assured by the inclusion of the 2266 "Digest" response header, as described in Section 6.1. Content 2267 authenticity is assured separately for the request and the response 2268 messages by the "Signature" header which protects the header fields 2269 described in further detail below. The "Signature" header parameter 2270 "keyId" contains the URL of a file containing the public key related 2271 to the multicast sender's private key used to create the digital 2272 signature. 2274 HTTP/3 "PUSH_PROMISE" frame including a "Signature" header protecting 2275 the ":method" and ":path" (the request target), as well as the 2276 ":scheme" and ":authority" of the pseudo-request: 2278 :method: GET 2279 :scheme: https 2280 :path: /files/example.txt 2281 :authority: example.org 2282 signature: keyId="https://example.org/mcast-sender.example.org.pem", 2283 algorithm=rsa-sha256, 2284 headers="(request-target) :scheme :authority", 2285 signature="MGQCMFTaFptaM2FhgzJq2i9AaChuFDHjp6GiXVtRnI8BsA" 2287 HTTP/3 "HEADERS" frame including a "Signature" header protecting the 2288 ":method", ":path", ":scheme" and ":authority" of the pseudo-request 2289 above, plus the "Date" and "Digest" of the response: 2291 :status: 200 2292 content-length: 100 2293 content-type: text/plain 2294 date: Fri, 20 Jan 2017 10:00:00 GMT 2295 digest: SHA-256=DieQ9zfRaDdyAilTVCvmBePuxMm+B6cNocP+QCrNSqo= 2296 signature: keyId="https://example.org/mcast-sender.example.org.pem", 2297 algorithm=rsa-sha256, 2298 headers="(request-target) :scheme :authority date digest", 2299 signature="MGUCMBgx6cuwTzg0W29zNUra8xfMsEcb3rFA3Y" 2301 HTTP/3 "DATA" frame containing response body data: 2303 ... 2305 B.2.6. Partial Transfer with Content Integrity and Authenticity 2307 In this example, partial content is transferred and the "Range" 2308 header (as described in Section 8) is used to indicate that 50 bytes 2309 out of 100 bytes were transferred. Content integrity is provided by 2310 the inclusion of the "Digest" header, as described in Section 6.1. 2311 Authenticity is provided by the "Signature" header which protects the 2312 header fields described in further detail. The "Signature" header 2313 parameter "keyId" contains the URL of a file containing the public 2314 key related to the multicast sender's private key used to create the 2315 digital signature. 2317 HTTP/3 "PUSH_PROMISE" frame: 2319 :method: GET 2320 :scheme: https 2321 :path: /files/example.txt 2322 :authority: example.org 2323 range: bytes=0-* 2324 signature: keyId="https://example.org/mcast-sender.example.org.pem", 2325 algorithm=rsa-sha256, 2326 headers="(request-target) :scheme :authority range", 2327 signature="MGQCMFTaFptaM2FhgzJq2i9AaChuFDHjp6GiXVtRnI8BsA" 2329 HTTP/3 "HEADERS" frame protecting the ":method", ":path", ":scheme" 2330 and ":authority" of the pseudo-request above, plus the "Date", 2331 "Digest" and "Content-Range" of the response: 2333 :status: 206 2334 content-length: 100 2335 content-range: bytes 0-49/100 2336 content-type: text/plain 2337 date: Fri, 20 Jan 2017 10:00:00 GMT 2338 digest: SHA-256=DieQ9zfRaDdyAilTVCvmBePuxMm+B6cNocP+QCrNSqo= 2339 signature: keyId="https://example.org/mcast-sender.example.org.pem", 2340 algorithm=rsa-sha256, 2341 headers="(request-target) :scheme :authority 2342 date digest content-range", 2343 signature="MGUCMBgx6cuwTzg0W29zNUra8xfMsEcb3rFA3Y" 2345 HTTP/3 "DATA" frame containing response body data: 2347 ... 2349 Appendix C. Summary of differences from unicast QUIC and HTTP/3 2350 +----------------+-----------------------+--------------------------+ 2351 | Protocol | Unicast QUIC | Multicast QUIC profile | 2352 | feature | | | 2353 +----------------+-----------------------+--------------------------+ 2354 | Packet number | QUIC transport | All packets are numbered | 2355 | spaces | packets are seperated | in the application data | 2356 | | into three distinct | packet number space. | 2357 | | packet number spaces: | | 2358 | | initial, handshake | | 2359 | | and application data. | | 2360 | | | | 2361 | Transport | Combined | Not used. | 2362 | handshake | cryptographic and | | 2363 | | transport handshake | | 2364 | | stream conveying TLS | | 2365 | | handshake messages in | | 2366 | | QUIC Initial and | | 2367 | | Handshake packets. | | 2368 | | | | 2369 | TLS cipher | Client's preferred | Cipher suite optionally | 2370 | suite | cipher suite included | advertised out of band | 2371 | | in Client Hello | via Alt-Svc "cipher- | 2372 | | message. | suite" parameter. | 2373 | | | Default cipher suite is | 2374 | | | "0x00,0x00 | 2375 | | | (NULL_WITH_NULL_NULL)". | 2376 | | | | 2377 | TLS session | Session key included | Session key optionally | 2378 | key | in Server Hello | advertised out of band | 2379 | | message. | via Alt-Svc "key" | 2380 | | | parameter. | 2381 | | | | 2382 | TLS | Initialization vector | Initialization vector | 2383 | initialization | included in Server | optionally advertised | 2384 | vector | Hello message. | out of band via Alt-Svc | 2385 | | | "iv" parameter. | 2386 +----------------+-----------------------+--------------------------+ 2388 Table 1: Cryptography and Transport 2390 +----------------------------+----------------+---------------------+ 2391 | Protocol feature | Unicast QUIC | Multicast QUIC | 2392 | | | profile | 2393 +----------------------------+----------------+---------------------+ 2394 | "initial_max_data" | Connection- | Not used. Peak flow | 2395 | | level flow | rate of a session | 2396 | | control window | optionally | 2397 | | size. | advertised out of | 2398 | | | band via Alt-Svc | 2399 | | | "peak-flow-rate" | 2400 | | | parameter. | 2401 | | | | 2402 | "initial_max_stream_data_b | Locally- | Not used. No | 2403 | idi_local" | initiated | bidirectional | 2404 | | bidirectional | streams in this | 2405 | | stream flow | profile. | 2406 | | control window | | 2407 | | size. | | 2408 | | | | 2409 | "initial_max_stream_data_b | Remotely- | Not used. No | 2410 | idi_remote" | initiated | bidirectional | 2411 | | bidirectional | streams in this | 2412 | | stream flow | profile. | 2413 | | control window | | 2414 | | size. | | 2415 | | | | 2416 | "initial_max_stream_data_u | Unidirectional | Not used. Peak flow | 2417 | ni" | stream flow | rate of a session | 2418 | | control window | optionally | 2419 | | size. | advertised out of | 2420 | | | band via Alt-Svc | 2421 | | | "peak-flow-rate | 2422 | | | parameter". | 2423 | | | | 2424 | "initial_max_streams_bidi" | Maximum stream | Not used. Maximum | 2425 | and | concurrency. | concurrent | 2426 | "initial_max_streams_uni" | | resources in a | 2427 | | | session optionally | 2428 | | | advertised out of | 2429 | | | band via Alt-Svc | 2430 | | | "max-concurrent- | 2431 | | | resources" | 2432 | | | parameter. | 2433 +----------------------------+----------------+---------------------+ 2435 Table 2: Required Transport Parameters 2437 +------------------------------+---------------+--------------------+ 2438 | Protocol feature | Unicast QUIC | Multicast QUIC | 2439 | | | profile | 2440 +------------------------------+---------------+--------------------+ 2441 | "original_destination_connec | The value of | Not used. No | 2442 | tion_id" | the | client | 2443 | | Destination | interaction. | 2444 | | Connection ID | | 2445 | | field from | | 2446 | | the first | | 2447 | | Initial | | 2448 | | packet sent | | 2449 | | by the | | 2450 | | client. | | 2451 | | | | 2452 | "max_idle_timeout" | How long to | Not used. | 2453 | | keep an idle | Advertised out of | 2454 | | connection | band via Alt-Svc | 2455 | | open for | "session-idle- | 2456 | | before | timeout" | 2457 | | closing. | parameter; | 2458 | | Takes a | defaults to 0 | 2459 | | default of 0 | (never close on | 2460 | | (never close | idle) if not | 2461 | | on idle) if | specified. | 2462 | | not | | 2463 | | specified. | | 2464 | | | | 2465 | "stateless_reset_token" | Used in | Not used. | 2466 | | verifying a | Stateless reset is | 2467 | | stateless | not used by this | 2468 | | reset. | profile. | 2469 | | | | 2470 | "max_udp_payload_size" | Limit of the | Not used. Maximum | 2471 | | size of | packet size for a | 2472 | | packets that | session optionally | 2473 | | an endpoint | advertised out of | 2474 | | is willing to | band via Alt-Svc | 2475 | | receive. | "max-packet-size" | 2476 | | | parameter. | 2477 | | | | 2478 | "ack_delay_exponent" | The exponent | Not used. "ACK" | 2479 | | used to | frames are | 2480 | | decode the | prohibited by this | 2481 | | ACK Delay | profile. | 2482 | | field in the | | 2483 | | "ACK" frame. | | 2484 | | | | 2485 | "max_ack_delay" | Maximum time | Not used. "ACK" | 2486 | | in | frames are | 2487 | | milliseconds | prohibited by this | 2488 | | by which an | profile. | 2489 | | endpoint will | | 2490 | | delay sending | | 2491 | | acknowledgeme | | 2492 | | nts. | | 2493 | | | | 2494 | "disable_active_migration" | Signals if an | Not used. Session | 2495 | | endpoint does | migration not | 2496 | | not support | currently | 2497 | | connection | supported by this | 2498 | | migration. | profile. | 2499 | | | | 2500 | "preferred_address" | Used to | Not used. No | 2501 | | effect a | handshake in this | 2502 | | change in | profile. | 2503 | | server | | 2504 | | address at | | 2505 | | the end of | | 2506 | | the | | 2507 | | handshake. | | 2508 | | | | 2509 | "active_connection_id_limit" | | Not used. Only a | 2510 | | | single session | 2511 | | | identifier is used | 2512 | | | in this profile. | 2513 | | | | 2514 | "initial_source_connection_i | The value | Not used. No | 2515 | d" | that an | client | 2516 | | endpoint | interaction. | 2517 | | included in | | 2518 | | the Source | | 2519 | | Connection ID | | 2520 | | field of the | | 2521 | | first Initial | | 2522 | | packet it | | 2523 | | sent for the | | 2524 | | connection | | 2525 | | | | 2526 | "retry_source_connection_id" | The value | Not used. Retry | 2527 | | that the | packets are not | 2528 | | server | used in this | 2529 | | included in | profile. | 2530 | | the Source | | 2531 | | Connection ID | | 2532 | | field of a | | 2533 | | retry packet | | 2534 +------------------------------+---------------+--------------------+ 2536 Table 3: Optional Transport Parameters 2538 +-------------+---------------------+-------------------------------+ 2539 | Protocol | Unicast QUIC | Multicast QUIC profile | 2540 | feature | | | 2541 +-------------+---------------------+-------------------------------+ 2542 | Maximum | Determined by path | Determined by path MTU | 2543 | packet size | MTU discovery or | discovery or other heuristic. | 2544 | | other heuristic. | | 2545 | | | | 2546 | Long header | Used for packets | Prohibited. | 2547 | packet | that are sent prior | | 2548 | | to the completion | | 2549 | | of version | | 2550 | | negotiation and | | 2551 | | before packet | | 2552 | | protection keys are | | 2553 | | established. | | 2554 | | | | 2555 | Version | Protocol version | Not permitted. | 2556 | negotiation | negotiation between | | 2557 | packet | initiating client | | 2558 | | and server. | | 2559 | | | | 2560 | Stateless | Used by a peer to | Not permitted. (Potential | 2561 | reset | terminate a | denial-of-service attack | 2562 | packet | connection that has | vector.) | 2563 | | become unusable. | | 2564 | | | | 2565 | Short | Used for packets | Used to convey QUIC frames | 2566 | header | that are sent once | (see below). | 2567 | packet | a connection has | | 2568 | | been established. | | 2569 | | Used to convey QUIC | | 2570 | | frames (see below). | | 2571 | | | | 2572 | Source | Connection IDs | Source Connection ID not | 2573 | Connection | negotiated between | used. Destination Connection | 2574 | ID field, | client and server | ID redefined to be a | 2575 | Destination | during handshake | Multicast Session ID which is | 2576 | Connection | and may be changed | optionally advertised out of | 2577 | ID field | subsequently using | band via the Alt-Svc | 2578 | | the | "session-id" parameter. May | 2579 | | "NEW_CONNECTION_ID" | be omitted from packets if | 2580 | | frame. | the address/port tuple is | 2581 | | | sufficient to identify the | 2582 | | | session, in which case it is | 2583 | | | not advertised. | 2584 +-------------+---------------------+-------------------------------+ 2586 Table 4: QUIC Packet Layer 2588 +------------------------+----------------------+---------------------+ 2589 | Protocol feature | Unicast QUIC | Multicast QUIC | 2590 | | | profile | 2591 +------------------------+----------------------+---------------------+ 2592 | "PADDING" frame | Used to pad out a | Permitted, but | 2593 | | QUIC packet with | wasteful of network | 2594 | | zero bytes. (The | capacity. | 2595 | | first packet sent on | | 2596 | | a connection must be | | 2597 | | at least 1200 bytes | | 2598 | | long to prove that | | 2599 | | the network can | | 2600 | | transmit packets of | | 2601 | | at least this size.) | | 2602 | | | | 2603 | "PING" frame | Used by an endpoint | Used by the | 2604 | | to verify that its | multicast sender as | 2605 | | peer is still alive. | a session keep- | 2606 | | Acknowledged using a | alive notification. | 2607 | | regular "ACK" frame. | Never acknowledged. | 2608 | | | | 2609 | "ACK" frames | Used by a receiver | Both "ACK" frame | 2610 | | to acknowledge | types are | 2611 | | receipt of data from | prohibited. | 2612 | | its peer. | | 2613 | | | | 2614 | "RESET_STREAM" frame | Request by receiver | Indication to | 2615 | | for sender to | receivers that the | 2616 | | terminate a stream | multicast sender | 2617 | | transmission | has prematurely | 2618 | | prematurely. | terminated a stream | 2619 | | | transmission. | 2620 | | | Prohibited for | 2621 | | | receivers to send. | 2622 | | | | 2623 | "STOP_SENDING" frame | Flow control back | Prohibited. | 2624 | | pressure. Used to | | 2625 | | signal to a peer | | 2626 | | that incoming data | | 2627 | | on a stream is being | | 2628 | | discarded on receipt | | 2629 | | at the application's | | 2630 | | request. This | | 2631 | | abruptly terminates | | 2632 | | a stream. | | 2633 | | | | 2634 | "CRYPTO" frame | Used to transmit | Prohibited. | 2635 | | cryptographic | | 2636 | | handshake messages. | | 2637 | | | | 2638 | "NEW_TOKEN" frame | Used by a server to | Prohibited. Session | 2639 | | supply a token to | migration not | 2640 | | its client to be | currently supported | 2641 | | sent in the header | by this profile. | 2642 | | of an initial packet | | 2643 | | for a future | | 2644 | | connection. Used to | | 2645 | | facilitate | | 2646 | | connection | | 2647 | | migration. | | 2648 | | | | 2649 | "STREAM" frame | Conveys application- | Conveys | 2650 | | layer payloads (see | application-layer | 2651 | | HTTP/3 mapping | payloads (see | 2652 | | below). | HTTP/3 mapping | 2653 | | | below). | 2654 | | | | 2655 | "FIN" bit on "STREAM" | Indication by sender | Indication by the | 2656 | frame | to its peer that a | multicast sender | 2657 | | stream transmission | that a stream | 2658 | | has finished. | transmission has | 2659 | | | finished. | 2660 | | | | 2661 | "MAX_DATA" frame | Flow control update | Prohibited. | 2662 | | notification. | | 2663 | | | | 2664 | "MAX_STREAM_DATA" | Flow control update | Prohibited. | 2665 | frame | notification. | | 2666 | | | | 2667 | "MAX_STREAMS" frame | Used by an endpoint | Prohibited. | 2668 | | to inform a peer of | | 2669 | | the maximum stream | | 2670 | | ID that it is | | 2671 | | permitted to open. | | 2672 | | | | 2673 | "DATA_BLOCKED" frame | Notification to | Prohibited. | 2674 | | receiver that | | 2675 | | sender's | | 2676 | | transmission is | | 2677 | | blocked pending an | | 2678 | | update to its flow | | 2679 | | control window by | | 2680 | | peer. | | 2681 | | | | 2682 | "STREAM_DATA_BLOCKED" | Notification to | Prohibited. | 2683 | frame | receiver that | | 2684 | | sender's | | 2685 | | transmission of a | | 2686 | | single stream is | | 2687 | | blocked pending an | | 2688 | | update to its flow | | 2689 | | control window by | | 2690 | | peer. | | 2691 | | | | 2692 | "STREAMS_BLOCKED" | Notification to | Prohibited. | 2693 | frames | receiver that the | | 2694 | | sender wishes to | | 2695 | | open a stream but is | | 2696 | | unable to do so | | 2697 | | because the maximum | | 2698 | | stream ID has been | | 2699 | | reached for a given | | 2700 | | stream type. | | 2701 | | | | 2702 | "NEW_CONNECTION_ID" | Used to provide a | Prohibited. Session | 2703 | frame | peer with | migration not | 2704 | | alternative | currently supported | 2705 | | connection IDs that | by this profile. | 2706 | | can be used to break | | 2707 | | linkability when | | 2708 | | migrating | | 2709 | | connections. | | 2710 | | | | 2711 | "RETIRE_CONNECTION_ID" | Indicates that an | Prohibited. Session | 2712 | frame | endpoint will no | migration not | 2713 | | longer use a | currently supported | 2714 | | connection ID that | by this profile. | 2715 | | was issued by its | | 2716 | | peer. | | 2717 | | | | 2718 | "PATH_CHALLENGE" frame | Used to check | Prohibited. | 2719 | | reachability to a | | 2720 | | peer and for path | | 2721 | | validation during | | 2722 | | connection | | 2723 | | migration. | | 2724 | | | | 2725 | "PATH_RESPONSE" frame | Sent in response to | Prohibited. | 2726 | | a "PATH_CHALLENGE" | | 2727 | | frame. | | 2728 | | | | 2729 | "CONNECTION_CLOSE" | Notification (by | Prohibited. Use | 2730 | frame | either peer) of | HTTP explicit | 2731 | | graceful connection | session tear-down | 2732 | | shutdown. | instead (see | 2733 | | | Section 5.4). | 2734 | | | | 2735 | "HANDSHAKE_DONE" frame | Used by a server to | Prohibited. | 2736 | | inform a client that | | 2737 | | the cryptographic | | 2738 | | handshake has | | 2739 | | completed. | | 2740 +------------------------+----------------------+---------------------+ 2742 Table 5: QUIC Framing Layer 2744 +----------------+------------------+-------------------------------+ 2745 | Protocol | Unicast HTTP/3 | Multicast HTTP/3 profile | 2746 | feature | | | 2747 +----------------+------------------+-------------------------------+ 2748 | Stream Type | Type of | Only Server Push type is | 2749 | | unidirectional | permitted. | 2750 | | stream. | | 2751 | | | | 2752 | Push ID | Identifies a | Identifies a promised | 2753 | | promised | resource conveyed in an | 2754 | | resource | earlier "PUSH_PROMISE" frame. | 2755 | | conveyed in an | | 2756 | | earlier | | 2757 | | "PUSH_PROMISE" | | 2758 | | frame. | | 2759 | | | | 2760 | "DATA" frame | Carriage of HTTP | Carriage of HTTP response | 2761 | | request/response | message body. | 2762 | | message body. | | 2763 | | | | 2764 | "HEADERS" | Carriage of HTTP | Carriage of HTTP response | 2765 | frame | request/response | message metadata. Trailing | 2766 | | message | "HEADERS" frame is permitted. | 2767 | | metadata. | | 2768 | | Trailing | | 2769 | | "HEADERS" frame | | 2770 | | is permitted. | | 2771 | | | | 2772 | "CANCEL_PUSH" | Used to request | Permitted only for senders. | 2773 | frame | cancellation of | | 2774 | | server push | | 2775 | | prior to the | | 2776 | | push stream | | 2777 | | being created. | | 2778 | | | | 2779 | "SETTINGS" | Negotiation of | Prohibited. | 2780 | frame | HTTP/3 | | 2781 | | connection | | 2782 | | settings. | | 2783 | | | | 2784 | "PUSH_PROMISE" | Carriage of HTTP | Carriage of HTTP pseudo- | 2785 | frame | pseudo-request | request message metadata. All | 2786 | | message | HTTP representation transfers | 2787 | | metadata. | over multicast begin this | 2788 | | | way. Stream ID of the first | 2789 | | | client-initiated | 2790 | | | bidirectional stream is | 2791 | | | reserved and all | 2792 | | | "PUSH_PROMISE" frames | 2793 | | | reference this as the client | 2794 | | | request from which they are | 2795 | | | notionally derived. This | 2796 | | | stream remains open while a | 2797 | | | sender is participating in | 2798 | | | the multicast QUIC session. | 2799 | | | | 2800 | "GOAWAY" frame | Early | Prohibited. Use HTTP explicit | 2801 | | notification (by | session tear-down instead. | 2802 | | either endpoint) | | 2803 | | of future | | 2804 | | connection | | 2805 | | closure, | | 2806 | | allowing for | | 2807 | | orderly | | 2808 | | completion of | | 2809 | | open streams. | | 2810 | | | | 2811 | "MAX_PUSH_ID" | Used by a | Prohibited. | 2812 | frame | receiver to | | 2813 | | control the | | 2814 | | number of server | | 2815 | | pushes that a | | 2816 | | sender can | | 2817 | | initiate. | | 2818 | | | | 2819 | "ALTSVC" | Signalling | Prohibited. | 2820 | HTTP/2 | alternative | | 2821 | extension | service for | | 2822 | frame | HTTP/3 session. | | 2823 | | | | 2824 | Other HTTP/2 | | Prohibited. | 2825 | extension | | | 2826 | frames | | | 2827 +----------------+------------------+-------------------------------+ 2829 Table 6: HTTP/3 Mapping 2831 +-------------+----------------------------------+------------------+ 2832 | Protocol | Unicast HTTP/3 | Multicast HTTP/3 | 2833 | feature | | profile | 2834 +-------------+----------------------------------+------------------+ 2835 | Huffman | Header blocks may use Huffman | Header blocks | 2836 | string | codes to compress literal string | may use Huffman | 2837 | compression | values. | codes to | 2838 | | | compress literal | 2839 | | | string values. | 2840 | | | | 2841 | Static | Header blocks may refer to | Header blocks | 2842 | table | indexed entries in the static | may refer to | 2843 | | table. | indexed entries | 2844 | | | in the static | 2845 | | | table. | 2846 | | | | 2847 | Dynamic | Header blocks may insert entries | Prohibited, size | 2848 | table | into the dynamic table and | is currently | 2849 | | subsequent header blocks may | locked to 0. | 2850 | | refer to their indexes. Unused | | 2851 | | as size is currently locked to | | 2852 | | 0. | | 2853 +-------------+----------------------------------+------------------+ 2855 Table 7: HTTP Metadata Compression Layer 2857 Appendix D. Changelog 2859 *RFC Editor's Note:* Please remove this section prior to 2860 publication of a final version of this document. 2862 D.1. Since draft-pardue-quic-http-mcast-06 2864 o Update references to QUIC I-Ds. 2866 o Clarify that only the first source-address parameter should be 2867 used if duplicated. 2869 o Fix source-address example to not be a quoted string. 2871 o Fix bytes in the ALPN identification sequence following change to 2872 h3m. 2874 o Update language around QUIC Connection IDs to reflect the core 2875 specs. 2877 o Update frame and transport parameter names throughout to match 2878 core specifications. 2880 o Remove Author's Note about reserved stream ID for "PUSH_PROMISE" 2881 frames. 2883 o Update language around QPACK static and dynamic table indexing to 2884 more closely align with the core spec. 2886 o Update Session Idle Timeout to match core specs, including 2887 removing limitation of 600 seconds and expressing in milliseconds, 2888 not seconds. 2890 o Preface Session Termination with a statement clarifying that 2891 participants may leave at any time. 2893 D.2. Since draft-pardue-quic-http-mcast-05 2895 o Update references to QUIC I-Ds. 2897 o Sender packet number size is now fixed for the duration of a 2898 session. 2900 o Change how to handle multiple session IDs: sessions are now only 2901 allowed a single ID. 2903 o Remove incompatible requirements set by [QUIC-TRANSPORT]'s 2904 "Required Operations". 2906 o Additionally ban "HANDSHAKE_DONE". 2908 o Remove Version Negotiation now that the "quic" Alt-Svc parameter 2909 has been removed (examples also updated). 2911 o Remove HTTP Prioritization references. 2913 o Add new "extensions" Alt-Svc parameter. 2915 o Broaden peak flow rate to QUIC payload to encompass all frame 2916 types. 2918 o Change ALPN identifier to h3m. 2920 D.3. Since draft-pardue-quic-http-mcast-04 2922 o Update references to QUIC I-Ds, remove QUIC-SPIN. (draft-ietf- 2923 quic-transport-20) 2925 o Update session ID length to match new connection ID length. 2926 (draft-ietf-quic-transport-22) 2928 o Clarify the mapping for the new "active_connection_id_limit" 2929 session parameter. (draft-ietf-quic-transport-21) 2931 o Update text to conform with latest version negotiation text from 2932 [QUIC-TRANSPORT]. 2934 o Update stream types for server push in accordance with draft-ietf- 2935 quic-http-19. 2937 o Fix some idnits warnings to do with line lengths in Alt-Svc 2938 examples. 2940 o Update IPv6 informative reference to RFC 8200 as it obsoletes RFC 2941 2460. 2943 o Clarify difference between connection and session migration. 2945 o Move GOAWAY frame to HTTP/3 profile. 2947 o Renamed Session Shutdown to Connection Shutdown to mirror concept 2948 in [QUIC-TRANSPORT]. 2950 o Clarify the layer of each frame type when referred to. 2952 D.4. Since draft-pardue-quic-http-mcast-03 2954 o Update references to QUIC I-Ds. 2956 o Change crypto handshake text now that it's no longer done on 2957 Stream ID 0. 2959 o Update to reference Source and Destination Connection IDs. 2961 o Prohibit the use of connection coalescing, migration and ECN. 2963 o Update allowed and disallowed packets and frames to match the core 2964 specs. 2966 o Remove references to the PONG frame. (draft-ietf-quic-transport- 2967 10) 2969 o Change HTTP/QUIC to HTTP/3. (draft-ietf-quic-http-17) 2971 o Change HPACK to QPACK. (draft-ietf-quic-http-10) 2973 o Prohibit the DUPLICATE_PUSH frame. 2975 o Clarify packet number space (only use application data space, not 2976 initial or handshake). 2978 o Add statement on QUIC latency spin bit. 2980 o Removed sentence stating that multiple Connection IDs cannot be 2981 used concurrently in a unicast QUIC session, in accordance with 2982 [QUIC-TRANSPORT] section 5.1.2. 2984 D.5. Since draft-pardue-quic-http-mcast-02 2986 o No changes. 2988 D.6. Since draft-pardue-quic-http-mcast-01 2990 o Explicit guidance on maximum stream ID value permitted. 2992 o Updated guidance on PING (and PONG) frame. 2994 o Added a comparison table to appendix. 2996 o Remove invalid use of trailing headers. 2998 o Use the new HTTP/QUIC DATA frame. 3000 o Prohibit APPLICATION CLOSE frame, and move GOAWAY frame to HTTP/ 3001 QUIC section. 3003 o Redefine server push to reflect core document changes. 3005 o Remove default idle time out value. 3007 o Clarify session parameter requirements (session-idle-timeout 3008 became mandatory). 3010 o Update frame notation convention. 3012 D.7. Since draft-pardue-quic-http-mcast-00 3014 o Update references to QUIC I-Ds. 3016 o Relax session leaving requirements language. 3018 o Clarify handling of omitted session parameter advertisements. 3020 o Rename "Idle" state to "Quiescent". 3022 o Add digest algorithm session parameter. 3024 o Add signature algorithm session parameter. 3026 o Add Initialization Vector session parameter. 3028 o Replace COPT tag-value-pairs with TransportParameter values. 3030 o Add example of an advertisement for a session with content 3031 authenticity and integrity. 3033 Authors' Addresses 3035 Lucas Pardue 3037 Email: lucaspardue.24.7@gmail.com 3039 Richard Bradbury 3040 BBC Research & Development 3042 Email: richard.bradbury@bbc.co.uk 3044 Sam Hurst 3045 BBC Research & Development 3047 Email: sam.hurst@bbc.co.uk