idnits 2.17.1 draft-pardue-quic-http-mcast-06.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 are 1 instance of lines with multicast IPv4 addresses in the document. If these are generic example addresses, they should be changed to use the 233.252.0.x range defined in RFC 5771 Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year == The document seems to lack the recommended RFC 2119 boilerplate, even if it appears to use RFC 2119 keywords -- however, there's a paragraph with a matching beginning. Boilerplate error? (The document does seem to have the reference to RFC 2119 which the ID-Checklist requires). -- The document date (February 7, 2020) is 1532 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-25 == Outdated reference: A later version (-21) exists of draft-ietf-quic-qpack-12 == Outdated reference: A later version (-34) exists of draft-ietf-quic-transport-25 ** Obsolete normative reference: RFC 3230 (Obsoleted by RFC 9530) ** Obsolete normative reference: RFC 7230 (Obsoleted by RFC 9110, RFC 9112) ** Obsolete normative reference: RFC 7233 (Obsoleted by RFC 9110) ** Obsolete normative reference: RFC 7234 (Obsoleted by RFC 9111) == Outdated reference: A later version (-34) exists of draft-ietf-quic-recovery-25 == Outdated reference: A later version (-34) exists of draft-ietf-quic-tls-22 -- Obsolete informational reference (is this intentional?): RFC 4566 (Obsoleted by RFC 8866) Summary: 5 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: August 10, 2020 S. Hurst 6 BBC Research & Development 7 February 7, 2020 9 Hypertext Transfer Protocol (HTTP) over multicast QUIC 10 draft-pardue-quic-http-mcast-06 12 Abstract 14 This document specifies a profile of the QUIC protocol and the HTTP/3 15 mapping that facilitates the transfer of HTTP resources over 16 multicast IP using the QUIC transport as its framing and 17 packetisation layer. Compatibility with the QUIC protocol's syntax 18 and semantics is maintained as far as practical and additional 19 features are specified where this is not possible. 21 Status of This Memo 23 This Internet-Draft is submitted in full conformance with the 24 provisions of BCP 78 and BCP 79. 26 Internet-Drafts are working documents of the Internet Engineering 27 Task Force (IETF). Note that other groups may also distribute 28 working documents as Internet-Drafts. The list of current Internet- 29 Drafts is at https://datatracker.ietf.org/drafts/current/. 31 Internet-Drafts are draft documents valid for a maximum of six months 32 and may be updated, replaced, or obsoleted by other documents at any 33 time. It is inappropriate to use Internet-Drafts as reference 34 material or to cite them other than as "work in progress." 36 This Internet-Draft will expire on August 10, 2020. 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 . . . . . . . . . . . . . . . . 22 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 . . . . . . . . . . . . . . . . . 26 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 . . . . . . . . 29 112 10.2. Session Parameter Advertisement . . . . . . . . . . . . 30 113 10.2.1. Cipher Suite . . . . . . . . . . . . . . . . . . . . 30 114 10.2.2. Session Key . . . . . . . . . . . . . . . . . . . . 30 115 10.2.3. Session Cipher Initialization Vector . . . . . . . . 31 116 10.2.4. Session Identification . . . . . . . . . . . . . . . 31 117 10.2.5. Session Idle Timeout Period . . . . . . . . . . . . 31 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 . . . . . . . . . . . . . . . . . . . . . 33 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 . . . . . . . . . . . 37 138 11.7. Receiver Resource Usage . . . . . . . . . . . . . . . . 38 139 11.8. Unicast Repair Information Leakage . . . . . . . . . . . 38 140 12. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 38 141 12.1. Registration of Protocol Identification String . . . . . 38 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 . . . . . . . . . . . . . . . 39 147 12.2.5. Session Identifier . . . . . . . . . . . . . . . . . 39 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 . . . . . . . . . . . . . . . . . . . . . . . . . 40 155 13.1. Normative References . . . . . . . . . . . . . . . . . . 40 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 . . . . . . . 44 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 . . . . . . . . . . . . . . . . . . . . 47 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-05 . . . . . . . . . . 61 179 D.2. Since draft-pardue-quic-http-mcast-04 . . . . . . . . . . 62 180 D.3. Since draft-pardue-quic-http-mcast-03 . . . . . . . . . . 62 181 D.4. Since draft-pardue-quic-http-mcast-02 . . . . . . . . . . 63 182 D.5. Since draft-pardue-quic-http-mcast-01 . . . . . . . . . . 63 183 D.6. Since draft-pardue-quic-http-mcast-00 . . . . . . . . . . 64 184 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 64 186 1. Introduction 188 The means to bulk transfer resources over multicast IP [RFC1112] 189 using HTTP semantics presents an opportunity to more efficiently 190 deliver services at scale, while leveraging the wealth of existing 191 HTTP-related standards, tools and applications. Audio-visual 192 segmented media, in particular, would benefit from this mode of 193 transmission. 195 The carriage of HTTP over multicast IP may be satisfied using 196 existing technologies, for example the Real-time Transport Protocol 197 (RTP) [RFC3550], File Delivery over Unidirectional Transport (FLUTE) 198 [RFC6726], and NACK-Oriented Reliable Multicast (NORM) [RFC5740]. 199 However, such protocols typically require the translation or 200 encapsulation of HTTP. This introduces concerns for providers of 201 services, such as defining the translation, additional workload, 202 complication of workflows, manageability issues, versioning issues, 203 and so on. 205 In contrast, this document describes a simpler and more direct 206 expression of HTTP semantics over multicast IP. HTTP over multicast 207 QUIC is a profile of the QUIC protocol [QUIC-TRANSPORT] (Section 4) 208 and the HTTP/3 mapping [QUIC-HTTP] (Section 5). This includes the 209 repurposing of certain QUIC packet fields and changes to some 210 protocol procedures (e.g. prohibition of the usage of certain frame 211 types) which, in turn, change the behavioural expectations of 212 endpoints. However, the profile purposely limits the scope of change 213 in order to preserve maximum syntactic and semantic compatibility 214 with conventional QUIC. For the reader's convenience, the 215 differences between this specification and conventional QUIC are 216 summarised in Appendix C. 218 This profile prohibits the transmission of QUIC packets from receiver 219 to sender via multicast IP. The use of side-channel or out-of-band 220 feedback mechanisms is not prohibited by this specification, but is 221 out of scope and these are not considered further by the present 222 document. 224 Experience indicates that a generally available multicast deployment 225 is difficult to achieve on the Internet notwithstanding the 226 improvements that IPv6 [RFC8200] makes in this area. There is 227 evidence that discretely referenced multicast "islands" can more 228 pragmatically be deployed. Discovery of such islands by receivers, 229 as they become available, is typically difficult, however. To 230 address the problem, this document describes an HTTP-based discovery 231 mechanism that uses HTTP Alternative Services [RFC7838] to advertise 232 the existence of multicast QUIC sessions (Section 3). This provides 233 the means for multicast-capable endpoints to learn about and make use 234 of them in an opportunistic and user-imperceptible manner. This 235 mechanism results in a common HTTP application layer for both the 236 discovery and delivery of services across unicast and multicast 237 networks. This provides support for users and devices accessing 238 services over a heterogeneous network. This is a departure from 239 conventional multicast discovery technologies such as SDP [RFC4566] 240 and SAP [RFC2974]. 242 The discovery mechanism also addresses some of the issues related to 243 using QUIC over a unidirectional network association by replacing 244 connection establishment aspects that depend on a bidirectional 245 transport. 247 The present document includes a number of optional features. It is 248 anticipated that further specifications will define interoperability 249 profiles suited to particular application domains. 251 1.1. Notational Conventions 253 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 254 "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and 255 "OPTIONAL" in this document are to be interpreted as described in BCP 256 14 [RFC2119] [RFC8174] when, and only when, they appear in all 257 captials, as shown here. 259 This document uses the Augmented BNF defined in [RFC5234] and updated 260 by [RFC7405] along with the "#rule" extension defined in Section 7 of 261 [RFC7230]. The rules below are defined in [RFC5234], [RFC7230], and 262 [RFC7234]: 264 o quoted-string = 266 o token = 268 o uri-host = 270 1.2. Definitions 272 Definitions of terms that are used in this document: 274 o endpoint: A host capable of being a participant in a multicast 275 QUIC session. 277 o multicast QUIC session: A logical unidirectional flow of metadata 278 and data over multicast IP, framed according to this 279 specification. The lifetime of a session is independent of any 280 endpoint. 282 o participant: A sender or receiver that is taking part in a 283 multicast QUIC session. 285 o sender: A participant sending multicast traffic according to this 286 specification. 288 o receiver: A participant receiving multicast traffic according to 289 this specification. 291 o session: See multicast QUIC session. 293 o session ID: The identifier for a multicast QUIC session. 295 o session parameter: Characteristic of a multicast QUIC session. 297 2. Multicast QUIC Sessions 299 A QUIC connection [QUIC-TRANSPORT] carried over bidirectional unicast 300 is defined as a conversation between two QUIC endpoints that 301 multiplexes several logical streams within a single encryption 302 context. This is a one-to-one relationship. Furthermore, QUIC 303 connections achieve decoupling from the underlying network (IP and 304 port) by means of a pair of Connection IDs, each uniquely identifying 305 the flow in one direction. Use of a consistent connection identifier 306 allows QUIC connections to survive changes to the network 307 connectivity. The establishment of a QUIC connection relies upon an 308 up-front, in-band exchange (and possible negotiation) of 309 cryptographic and transport parameters (conveyed in QUIC handshake 310 messages). 312 The mapping of HTTP semantics over the QUIC transport protocol 313 [QUIC-HTTP] facilitates the transfer of hypermedia over QUIC 314 connections. The establishment of a HTTP/3 connection relies upon 315 all the requirements stipulated for the transport, as well as 316 communication of HTTP-specific settings (conveyed in HTTP/3 317 "SETTINGS" frames). Such parameters may be required or optional and 318 may be used by either endpoint to control the characteristics of 319 connection usage. 321 This concept of a connection does not suit the carriage of HTTP/3 322 over unidirectional network associations such as multicast IP. In 323 fact, there is no requirement for either endpoint (multicast sender 324 or receiver) to be in existence in order for the other to start or 325 join this one-sided conversation. The term "connection" is 326 misleading in this context; therefore we introduce an alternative 327 term "multicast QUIC session" or simply "session", which is defined 328 as the logical entity describing the characteristics of the 329 anticipated unidirectional flow of metadata and data. Such 330 characteristics are expressed as "session parameters", described in 331 Section 2.2. Advertisement of multicast QUIC sessions, specified in 332 Section 3, allows for the senders and receivers to discover a session 333 and to form multicast IP network associations that permit traffic 334 flow. 336 2.1. Session States 338 The lifecycle of a multicast QUIC session is decoupled from the 339 lifecycle of any particular endpoint. Multicast receivers or senders 340 that take part in a session are called participants. The state of a 341 session is influenced by the actions of participants. The loose 342 coupling of participants means that they are unlikely to have a 343 consistent shared view of the current state of a session. There is 344 no requirement for a participant to know the session state and the 345 present document does not define a method to explicitly determine it. 346 The definitions of session states provided below are intended to 347 assist higher-level operational treatment of sessions: 349 o Quiescent: the session has no participants and is ready to accept 350 them. 352 o Half-established: the session has a participant. 354 o Fully-established: the session has a sender and at least one 355 receiver participant. 357 o Finished: the session has ended, and there are no participants. 359 Permitted states transitions are shown in Figure 1 below. 361 The transmission of QUIC packets is expected to occur only during the 362 Half-Established and Fully-Established states. 364 +-----------+ +------------------+ +-------------------+ 365 | |-------->| |------->| | 366 | Quiescent | | Half-Established | | Fully-Established | 367 | |<--------| |<-------| | 368 +-----------+ +------------------+ +-------------------+ 369 | | 370 | v 371 | +----------+ 372 | | | 373 +------------------>| Finished | 374 | | 375 +----------+ 377 Figure 1: Multicast QUIC session states 379 2.1.1. Session Establishment 381 A session begins in the Quiescent state. A typical session 382 establishment sequence would see the transition from Quiescent to 383 Half-Established when a sender joins the session. The transition 384 from Half-Established to Fully-Established occurs when at least one 385 receiver joins the session. 387 It is equally valid for a receiver to join a session in the Quiescent 388 state, triggering the transition to Half-Established. In this case, 389 the transition to Fully-Established takes place only when a sender 390 joins the session. 392 2.1.2. Session Termination 394 A session enters the Finished state when all participants leave it. 395 The methods for leaving a session are either explicit shutdown 396 (Section 5.4), implicit shutdown (i.e. idle timeout, Section 3.3) or 397 migration away (described in the next section). 399 In a typical case, a session that is in the Fully-Established state 400 would be closed in two stages. In the first stage the sender sends 401 explicit shutdown messages to the multicast group and subsequently 402 stops transmitting packets. This causes the session to transition 403 from Fully-Established to Half-Established. In the second stage, 404 receivers that have received explicit shutdown messages leave the 405 multicast group. Once all receivers have left the session it 406 transitions from Half-Established to Finished. 408 The transition from Quiescent to Finished could also occur in 409 response to out-of-band actions, for example the availability of a 410 session being withdrawn without any participants having made use of 411 it. 413 2.1.3. Session Migration 415 Endpoints MAY migrate between multicast QUIC sessions (for example, 416 to make use of alternate session parameters that are preferred). 417 Session migration requires participants to leave the current session 418 and join the new session. These actions affect the state of the 419 respective sessions as explained above. 421 The discovery of multicast QUIC sessions is described in Section 3. 423 2.2. Session Parameters 425 The characteristics of multicast QUIC sessions are expressed as 426 session parameters, which cover cryptographic and transport 427 parameters, HTTP-specific settings and multicast-specific 428 configuration. 430 Session parameter exchange over IP multicast is difficult: 432 o In-band exchanges are one-way, and so the client does not have the 433 means to send session parameters. 435 o The lifecycle of any multicast sender is independent of the 436 multicast receiver. It is therefore unlikely that all receivers 437 will have joined a session in time to receive parameters sent at 438 the start of a multicast session. 440 A range of strategies exists to mitigate these points. However, each 441 has the possibility to add complexity to deployment and 442 manageability, transmission overhead, or other such concerns. This 443 document defines a solution that relies on the one-way announcement 444 of session parameters in advance of session establishment. This is 445 achieved using HTTP Alternative Services [RFC7838] and is explained 446 in Section 3. Other advertisement solutions are not prohibited but 447 are not explored in this document. 449 Session parameters MUST NOT change during the lifetime of a session. 450 This restriction also applies to HTTP-level settings (see 451 Section 5.1). 453 2.3. Session Identification 455 This document defines an optional session identifier used to identify 456 a session. This "Session ID" affords independence from multicast IP, 457 creating the possibility for a session to span multiple multicast 458 groups, or to migrate a session to a different multicast group. 459 Assignment of Session ID is considered out of this document's scope. 461 The Session ID is carried in the Destination Connection ID field of 462 the QUIC packet (see Section 4.3). Source Connection IDs are not 463 used. 465 The maximum size of a Session ID is 160 bits. The size of the 466 Destination Connection ID field used to convey the Session ID SHALL 467 be the smallest number of full bytes required to represent the full 468 Session ID value advertised in the "session-id" session parameter 469 (Section 10.2.4). If no "session-id" parameter is advertised, then 470 this session has no explicit session ID, and the Destination 471 Connection ID field SHALL be omitted from all QUIC packets related to 472 the session. 474 A multicast sender participating in a session with an advertised 475 "session-id" session parameter MUST send QUIC packets with a matching 476 Session ID. Conversely, a multicast sender participating in a 477 session without an advertised "session-id" session parameter MUST NOT 478 send QUIC packets with a Destination Connection ID field. 480 A multicast receiver participating in a session with an advertised 481 "session-id" session parameter MUST validate that the Session ID of 482 received QUIC packets matches that advertised in the session 483 parameters (Section 10.2.4) before any HTTP-level processing is done. 484 In the case of validation failure, the receiver SHOULD ignore the 485 packet in order to protect itself from denial-of-service attacks. 487 2.4. Session Security 489 *Authors' Note:* Security handshake (as described in WG documents) 490 is in flux. This section will track developments and will be 491 updated accordingly. 493 The QUIC cryptographic handshake ([QUIC-TRANSPORT] and [QUIC-TLS]) 494 sets out methods to achieve the goals of authenticated key exchange 495 and QUIC packet protection between two endpoints forming a QUIC 496 connection. The design facilitates low-latency connection; 1-RTT or 497 0-RTT. This specification replaces the in-band security handshake, 498 achieving similar goals through the use of session parameters 499 described in Section 3.1. 501 Integrity and authenticity concerns are addressed in Section 6.1 and 502 Section 6.2 respectively. In order to protect themselves from attack 503 vectors, endpoints SHOULD NOT participate in sessions for which they 504 cannot establish reasonable confidence over the cipher suite or key 505 in use for that session. Participants MAY leave any session that 506 fails to successfully match anticipated security characteristics. 508 3. Session Advertisement 510 In this specification, connection negotiation is replaced with a 511 session advertisement mechanism based on HTTP Alternative Services 512 (Alt-Svc) [RFC7838]. This document specifies how the parameters of a 513 multicast QUIC session are expressed as Alt-Svc parameters. The 514 following sections provide a high-level view of these; further 515 details are provided in Section 10.2, with examples provided in 516 Appendix B.1. QUIC connection parameters not defined as, or related 517 to, Alt-Svc parameters are not used. 519 The definition of a session (including the session ID and its 520 parameters) is not the responsibility of any endpoint. Rather, 521 endpoints SHOULD use session advertisements to determine if they are 522 capable of participating in a given session. This document does not 523 specify which party is responsible for defining and/or advertising 524 multicast QUIC sessions. 526 Endpoints SHOULD NOT become participants in sessions where the 527 advertisement requirements set out in the present document are 528 unfulfilled. 530 The freshness of Alt-Svc multicast QUIC session advertisements is as 531 described in section 2.2 of [RFC7838]. 533 It is RECOMMENDED that session advertisements are carried over a 534 secure transport (such as HTTPS) which can guarantee the authenticity 535 and integrity of the Alt-Svc information. This addresses some of the 536 concerns around the protection of session establishment described in 537 Section 11.2. 539 *Authors' Note:* We invite review comments on mandating the use of 540 a secure transport for advertising sessions. 542 Senders MAY also advertise the availability of alternative sessions 543 by carrying Alt-Svc in a multicast QUIC session. 545 3.1. Security Context 547 *Authors' Note:* Security handshake (as described in WG documents) 548 is in flux. This section will track developments and will be 549 updated accordingly. 551 This specification replaces the in-band security handshake. The 552 session parameters "cipher suite", "key" and "iv" (described below) 553 allow for the establishment of a security context. In order to 554 protect themselves, endpoints SHOULD NOT participate in sessions for 555 which they cannot establish reasonable confidence over the cipher 556 suite, key, or IV in use for that session. Endpoints SHOULD leave 557 any sessions which fail to successfully match anticipated security 558 characteristics. 560 3.1.1. Cipher Suite 562 Cipher suite negotiation is replaced with a "cipher suite" session 563 parameter, which is advertised as the Alt-Svc parameter "cipher- 564 suite" (Section 10.2.1). 566 The Alt-Svc "cipher-suite" parameter is OPTIONAL. If present, this 567 parameter MUST contain only one value that corresponds to an entry in 568 the TLS Cipher Suite Registry (see http://www.iana.org/assignments/ 569 tls-parameters/tls-parameters.xhtml#tls-parameters-4). Session 570 advertisements that omit this parameter imply that the session is 571 operating with cipher suite 0x00,0x00 (NULL_WITH_NULL_NULL). 573 3.1.2. Key Exchange 575 Key exchange is replaced with a "key" session parameter, which is 576 advertised as the Alt-Svc parameter "key" (Section 10.2.2). The 577 parameter carries a variable-length hex-encoded key for use with the 578 session cipher suite. 580 The Alt-Svc "key" parameter is OPTIONAL. Session advertisements that 581 omit this parameter imply that the key may be available via an out- 582 of-band method not described in this document. 584 3.1.3. Initialization Vector 586 Initialization Vector (IV) exchange is replaced with an "iv" session 587 parameter, which is advertised as the Alt-Svc parameter "iv" 588 (Section 10.2.3). The parameter carries a variable-length hex- 589 encoded IV for use with the session cipher suite and key. 591 The Alt-Svc "iv" parameter is OPTIONAL. Session advertisements that 592 omit this parameter imply that the IV may be available via an out-of- 593 band method not described in this document. 595 3.2. Session Identification 597 [QUIC-TRANSPORT] specifies how the QUIC connection identifiers are 598 used, in particular the independent selection of these identifiers by 599 each endpoint for its peer. In a unidirectional multicast 600 environment, there is no meaningful way for an endpoint to generate a 601 connection identifier for its peer to use. This document defines a 602 "session identifier" session parameter, which is advertised as the 603 Alt-Svc parameter "session-id" (Section 10.2.4). The requirements 604 for the usage of session identifiers have already been described in 605 Section 2.3. 607 The Alt-Svc "session-id" parameter is optional. Session 608 advertisements MAY contain at most one instance of a "session-id" 609 parameter. Session advertisements that identify the same Any Source 610 Multicast group {G} or Source Specific Multicast group {S,G} indicate 611 that multiple sessions are multiplexed in the same multicast group 612 and each such advertisement must carry a unique "session-id". 614 3.3. Session Idle Timeout 616 Conventional QUIC connections may be implicitly terminated following 617 a period of idleness (lack of network activity). The optional QUIC 618 TransportParameter "max_idle_timeout" provides a means for endpoints 619 to specify the timeout period. This document defines a "session idle 620 timeout" session parameter, which is advertised as the Alt-Svc 621 parameter "session-idle-timeout" (Section 10.2.5). This session 622 parameter mimics the behaviour of "max_idle_timeout", providing a 623 means for multicast QUIC sessions to define their own idle timeout 624 periods. 626 Session idle timeout may be prevented by keep-alive strategies 627 Section 4.10. 629 The Alt-Svc "session-idle-timeout" parameter is optional. Session 630 advertisements MAY contain zero or more instances of this parameter. 631 If it is repeated, the first occurrence MUST be used and subsequent 632 occurrences MUST be ignored. Session advertisements that omit the 633 "session-idle-timeout" parameter, or set it to zero never time out. 635 Receiving participants SHOULD leave multicast QUIC sessions when the 636 session idle timeout period has elapsed (Section 4.7). Leaving 637 participants MUST use the silent close method, in which no QUIC 638 "CONNECTION_CLOSE" frame is sent. 640 3.4. Session Peak Flow Rate 642 [QUIC-TRANSPORT] specifies a credit-based stream- and connection- 643 level flow control scheme which prevents a fast sender from 644 overwhelming a slow receiver at the stream level, as well as an 645 aggregate level of all streams. Window size connection parameters 646 are exchanged on connection establishment using the required QUIC 647 TransportParameters "initial_max_data", 648 "initial_max_stream_data_bidi_local", 649 "initial_max_stream_data_bidi_remote" and 650 "initial_max_stream_data_uni". In a unidirectional multicast 651 environment, such a scheme is infeasible. 653 This document defines a "peak flow rate" session parameter, expressed 654 in units of bits per second, which is advertised as the Alt-Svc 655 parameter "peak-flow-rate" (Section 10.2.7). This completely 656 replaces the transport parameters listed above, instead indicating 657 the maximum bit rate of QUIC payloads transmitted on all multicast 658 groups comprising the session. It applies at the aggregate level, 659 and is not specific to any single stream. 661 The Alt-Svc "peak-flow-rate" parameter is OPTIONAL. If the parameter 662 is repeated the first occurrence MUST be used and subsequent 663 occurrences MUST be ignored. Session advertisements that omit the 664 parameter imply that the flow rate is unlimited. 666 A multicast sender SHOULD NOT cause the advertised peak flow rate of 667 a session to be exceeded. A receiver MAY leave any session where the 668 advertised peak flow rate is exceeded. 670 3.5. Resource Concurrency 672 [QUIC-TRANSPORT] considers concurrency in terms of the number of 673 active incoming streams, which is varied by the receiving endpoint 674 adjusting the maximum Stream ID. The initial value of maximum Stream 675 ID is controlled by the relevant required QUIC TransportParameters 676 "initial_max_streams_bidi" and "initial_max_streams_uni". They are 677 increased during the lifetime of a QUIC connection by the QUIC 678 "MAX_STREAMS" frame. In a unidirectional multicast environment, 679 there is no way for a receiver to specify an initial limit nor to 680 increase it. Therefore in multicast QUIC, the maximum Stream ID 681 (initial and always) is 2^62. This mechanism is not used to manage 682 concurrency in multicast QUIC. 684 Due to the profiling of maximum Stream ID, there is no role for the 685 QUIC "STREAMS_BLOCKED" frame and it is prohibited. Participants MUST 686 NOT send this frame type. Reception of this frame type MUST be 687 handled as described in Section 4.12. 689 This document specifies a "maximum concurrent resources" session 690 parameter, which is advertised as the Alt-Svc parameter "max- 691 concurrent-resources" (Section 10.2.6). This parameter replaces 692 "initial_max_stream_id_bidi" and "initial_max_stream_id_uni". It 693 advertises the maximum number of concurrent active resources 694 generated by a sender in a given multicast QUIC session. 696 The Alt-Svc "max-concurrent-resources" parameter is OPTIONAL. If the 697 parameter is repeated the first occurrence MUST be used and 698 subsequent occurrences MUST be ignored. Session advertisements that 699 omit the parameter imply that the maximum concurrency is unlimited. 701 A multicast sender participating in a session MUST NOT cause the 702 advertised "max-concurrent-resources" to be exceeded. A receiver MAY 703 leave any session where the advertised limit is exceeded, in order to 704 protect itself from denial-of-service attacks. 706 3.6. Additional TransportParameter Considerations 708 *Authors' Note:* This section will consider TransportParameters 709 that have not already been addressed, as required. It will track 710 developments and issues that may arise. 712 Section 19.21 of [QUIC-TRANSPORT] defines a mechanism for endpoints 713 to show willingness to receive one or more extension frame types. It 714 is not possible for multicast QUIC receivers to signal this 715 information to senders. 717 This document defines an "extensions" session parameter, which is 718 advertised as the Alt-Svc parameter "extensions" Section 10.2.10 and 719 replaces the transport parameter exchange detailed above. The Alt- 720 Svc "extensions" parameter is optional. Session advertisements MAY 721 contain zero or more instances of this parameter. The parameter 722 lists transport parameter values present in the QUIC Transport 723 Parameter Registry as specified in Section 22.2 of [QUIC-TRANSPORT]. 725 Only transport parameters which expressly reference Multicast QUIC 726 are considered valid extension parameters. 728 *Authors' Note:* The authors welcome suggestions for how to map 729 these extension types more cleanly into this document. 731 Participants SHOULD NOT join sessions advertising extensions that 732 they do not support, as QUIC frames are not self-describing. 734 3.7. Digest Algorithm 736 A method to provide content integrity is described in Section 6.1. 737 This specifies the means to convey a value computed by a particular 738 digest algorithm. The identity of the selected algorithm is also 739 indicated. Valid digest algorithms are collected in the IANA HTTP 740 Digest Algorithm Values registry (http://www.iana.org/assignments/ 741 http-dig-alg/http-dig-alg.xhtml#http-dig-alg-1). 743 This document specifies a "digest algorithm" session parameter, which 744 is advertised as the Alt-Svc parameter "digest-algorithm" 745 (Section 10.2.8). 747 *Authors' Note:* Section 6.1 contains an author's note on the 748 potential for content integrity to become mandatory. This section 749 will be updated in line with the outcome of that decision. 751 The Alt-Svc "digest-algorithm" parameter is OPTIONAL. Repetition of 752 the "digest algorithm" parameter in a single advertisement describes 753 an algorithm set that MAY be used across the session. Session 754 advertisements that omit the Alt-Svc parameter "digest-algorithm" 755 imply that either: 757 o the session does not use the content integrity mechanism, or 759 o the algorithm set is unrestricted, i.e. a sender may vary the 760 algorithm as it so chooses. This may lead to undesirable results 761 if receivers do not support a chosen algorithm. 763 Advertising the algorithm set for a session gives receivers the 764 opportunity to selectively join sessions where the algorithms are 765 known to be supported. This may help to mitigate latency issues in 766 the receiver resulting from joining a session only to discover some 767 of its parameters are not supported. 769 A multicast sender participating in a session MUST NOT use algorithms 770 outside the signalled digest algorithm set. A receiver MAY leave any 771 session where an algorithm outside the digest algorithm set is used. 773 3.8. Signature Algorithm 775 A method to provide content authenticity is described in Section 6.2. 776 This specifies the means to convey a value computed by a particular 777 signature algorithm. The identity of the selected algorithm is also 778 indicated. Valid signature algorithms are collected in the IANA 779 Signature Algorithms registry (http://www.iana.org/assignments/ 780 signature-algorithms). 782 This document specifies a "signature algorithm" session parameter, 783 which is advertised as the Alt-Svc parameter "signature-algorithm" 784 (Section 10.2.9). 786 *Authors' Note:* Section 6.2 contains an author's note on the 787 potential for content authenticity to become mandatory. This 788 section will be updated in line with the outcome of that decision. 790 The Alt-Svc "signature-algorithm" parameter is OPTIONAL. Repetition 791 of the "signature algorithm" parameter in a single advertisement 792 describes an algorithm set that MAY be used across the session. 793 Session advertisements that omit the Alt-Svc parameter "signature- 794 algorithm" imply that either: 796 o the session does not use the content authenticity mechanism, or 798 o the algorithm set is unrestricted i.e. a sender may vary the 799 algorithm as it so chooses. This may lead to undesirable results 800 if receivers do not support a chosen algorithm. 802 Advertising the algorithm set for a session gives receivers the 803 opportunity to selectively join sessions where the algorithms are 804 known to be supported. This may help to mitigate latency issues in 805 the receiver resulting from joining a session only to discover some 806 of its parameters are not supported. 808 A multicast sender participating in a session MUST NOT use algorithms 809 outside the signalled signature algorithm set. A receiver MAY leave 810 any session where an algorithm outside the signature algorithm set is 811 used. 813 4. QUIC Profile 815 *Authors' Note:* The QUIC transport document is subject to change. 816 This section is based on our best understanding of draft-ietf- 817 quic-transport-25. The authors will track developments and will 818 update this section accordingly. 820 The profile of [QUIC-TRANSPORT] is presented in this section. In 821 order to preserve compatibility with conventional QUIC, the 822 specification works with a limited scope of change. However, the 823 nature of unidirectional multicast communications means that some 824 protocol procedures or behaviours need to be modified. 826 Section 5.4 of [QUIC-TRANSPORT] defines a set of required actions 827 that a QUIC server and QUIC client must be able to perform. Due to 828 the limitations of this profile, all of the requirements in 829 Section 5.4 of [QUIC-TRANSPORT] are removed except for: 831 o Configuring the minimum and total number of permitted streams of 832 each type is described in Section 3.5. 834 o Multicast QUIC senders may still send "PING" frames to stop a 835 session from expiring as described in Section 4.10. 837 4.1. Packet Size 839 The means for determining an appropriate size for QUIC packets are 840 described in Section 14 of [QUIC-TRANSPORT]. Implementations of this 841 specification SHOULD bear in mind that the Path Maximum Transmission 842 Unit (PTMU) may be affected by multicast IP technologies such as 843 Automatic Multicast Tunneling (AMT) [RFC7450]. Additionally, 844 consideration should be given toward the applicability of maximum 845 transmission unit discovery methods (such as PLPMTUD [RFC4821] and 846 PMTUD [RFC1191]) to multicast IP. 848 4.2. Packet Format 850 Endpoints implementing this specification MUST only send QUIC packets 851 with the short header form. As short header packets do not include a 852 length, senders MUST NOT attempt to coalesce any QUIC packets in the 853 same UDP datagram. Therefore, all UDP datagrams sent by senders 854 conforming to this profile contain exactly one QUIC packet. 856 4.2.1. Packet Numbers 858 All packets for this profile SHALL be numbered in the application 859 data packet number space. The initial and handshake packet number 860 spaces are not used by this profile, as the handshake is replaced by 861 an out-of-band mechanism (see Section 2.4). 863 The encoding of packet numbers in QUIC packets is described in 864 Section 17.1 of [QUIC-TRANSPORT]. Senders must always use the same 865 number of bytes to represent the packet number for all packets sent 866 to a session. Because a receiver may join a session after the sender 867 has already sent several packets, it MUST NOT assume that the first 868 packet number will be 0. 870 4.2.2. Spin Bit 872 [QUIC-TRANSPORT] specifies a bit in the short packet header as the 873 latency spin bit that may be used to measure network round trip 874 latency between a client and a server. This mechanism is not usable 875 in a unidirectional multicast packet flow. Senders SHALL set the 876 spin bit to zero in all packets. Receivers SHOULD ignore the spin 877 bit. 879 *Authors' Note:* The authors welcome suggestions for the use of 880 the spin bit in a multicast context. 882 4.3. Connection Identifier 884 The Destination Connection ID field MUST be present in every QUIC 885 packet if the session was advertised with a "session-id" session 886 parameter (Section 10.2.4). If there is no Session ID session 887 parameter, then the Destination Connection ID MUST NOT be present in 888 any QUIC packet for that session. In the case where multiple 889 sessions are multiplexed on the same 5-tuple network association, the 890 Destination Connection ID field MUST be present in every QUIC packet 891 and must be distinct for each session. 893 4.4. Stream Identifier 895 The maximum Stream ID of a multicast QUIC session is 2^62, as 896 explained in Section 3.5. With the exception of the first client- 897 initiated request Stream ID, which is reserved as described in 898 Section 5.2, all Stream ID values SHALL be of the server-initiated 899 unidirectional stream type. 901 4.5. Flow Control 903 Conventional QUIC provides stream- and connection-level flow control, 904 and endpoints manage this by sending QUIC "MAX_DATA" or 905 "MAX_STREAM_DATA" frames as required. When a sender is blocked from 906 sending flow-controlled frames, it sends an informational QUIC 907 "BLOCKED" or "STREAM_BLOCKED" frame. 909 In a unidirectional environment, the sender never has a receive 910 window and the receiver cannot send in-band updates. Therefore, the 911 management of flow-control windows and transmission of blockage 912 information is not supported by this profile. The QUIC "MAX_DATA", 913 "MAX_STREAM_DATA", "BLOCKED" and "STREAM_BLOCKED" frames are 914 prohibited by this profile. Participants MUST NOT send these frame 915 types. Reception of these frame types MUST be handled as described 916 in Section 4.12. 918 4.6. Stream Termination 920 A sender MAY prematurely terminate the transmission on any unreserved 921 QUIC Stream ID by setting the "FIN" bit of a QUIC "STREAM" frame, or 922 by sending a QUIC "RESET_STREAM" frame (as specified in 923 [QUIC-TRANSPORT] and [QUIC-HTTP]). 925 Receiving participants MUST NOT make any attempt to send QUIC 926 "RESET_STREAM" frames to the multicast group. 928 4.7. Connection Shutdown 930 Explicit shutdown of a multicast QUIC session using QUIC methods is 931 not supported by this profile. 933 The QUIC "APPLICATION_CLOSE" and "CONNECTION_CLOSE" frames, and the 934 Stateless Reset packet are prohibited. Participants MUST NOT send 935 these and reception MUST be handled as described in Section 4.12. 937 Explicit session tear-down using HTTP semantics is allowed, as 938 described in Section 5.4. 940 Implicit shutdown by means of silent close is also supported, as 941 described in Section 3.3. 943 4.8. Connection Migration 945 [QUIC-TRANSPORT] has a connection migration feature that allows a 946 connection to survive changes to endpoint addresses. This profile 947 does not currently support connection migration, and as such the QUIC 948 "NEW_CONNECTION_ID" and "RETIRE_CONNECTION_ID" frames are prohibited. 949 Similarly, the QUIC "PATH_CHALLENGE" and "PATH_RESPONSE" frames are 950 also prohibited, but additionally because they require bidirectional 951 capability that this profile does not provide. 953 Endpoints participating in a session conforming to this profile MUST 954 only use a single session ID for the duration of the session, and as 955 such there is no mapping for the "active_connection_id_limit" 956 transport parameter specified in section 5.1.1 of [QUIC-TRANSPORT] in 957 this profile. 959 *Author's Note*: Seamless migration from one multicast QUIC 960 session to another is described in Section 2.1.3. 962 4.9. Explicit Congestion Notification 964 [QUIC-TRANSPORT] specifies that clients may use Explicit Congestion 965 Notification (ECN) [RFC3168]. ECN allows receivers to inform senders 966 of impending congestion before packets are dropped, and the sender 967 may then reduce its transmission rate. As ECN requires bidirectional 968 communication for the receiver to inform the sender of the 969 congestion, the use of ECN for this profile is prohibited. 971 *Author's Note*: It is the responsibility of a receiver to 972 determine whether network conditions permit the uncongested 973 reception of a given session based on the advertised "peak-flow- 974 rate" parameter. 976 4.10. Session Keep-alive 978 The flow of traffic in a multicast QUIC session is driven by a 979 sender. There may be periods where the sender has no application 980 data to send for a period longer than the session idle timeout. This 981 profile repurposes the QUIC "PING" frame to act as a unidirectional 982 keep-alive message that may be sent in order to inform receivers that 983 the session should remain in the Fully-established state. 984 [QUIC-TRANSPORT] contains guidance on the sending frequency of QUIC 985 "PING" frames. 987 Senders MAY send a QUIC "PING" frame at any time in order to inform 988 receivers that the session traffic flow has not fallen idle. This 989 frame MUST NOT be acknowledged. Indeed, QUIC "ACK" frames are 990 prohibited by this profile (Section 4.11). 992 Receiving participants MUST NOT make any attempt to send QUIC "PING" 993 frames. 995 4.11. Loss Detection and Recovery 997 Receivers implementing this profile MUST NOT make any attempt to 998 acknowledge the reception of QUIC packets. The QUIC "ACK" frame is 999 prohibited for both senders and receivers. Reception of this frame 1000 MUST be handled as described in Section 4.12. 1002 Section 7 specifies alternative strategies for loss recovery. 1004 4.12. Prohibited QUIC Frames and Packets 1006 The following QUIC packets MUST NOT be transmitted by participants: 1007 Any packets with a long header (Initial, 0-RTT Protected, Handshake, 1008 Retry), Version Negotiation, Stateless Reset. 1010 The following QUIC frames MUST NOT be transmitted by participants: 1011 "ACK", "CONNECTION_CLOSE", "CRYPTO", "DATA_BLOCKED", 1012 "HANDSHAKE_DONE", "MAX_DATA", "MAX_STREAM_DATA", "MAX_STREAMS", 1013 "NEW_CONNECTION_ID", "NEW_TOKEN", "PATH_CHALLENGE", "PATH_RESPONSE", 1014 "RETIRE_CONNECTION_ID", "STOP_SENDING", "STREAM_DATA_BLOCKED", 1015 "STREAMS_BLOCKED". 1017 In addition, any QUIC extension frames not advertised in the session 1018 advertisement Section 3.6 MUST NOT be transmitted by participants. 1020 The following QUIC frames MUST NOT be transmitted by receivers: 1021 "PING", "RESET_STREAM". 1023 Reception of a prohibited or non-advertised QUIC frame or packet is a 1024 protocol error. Receivers MUST ignore all prohibited QUIC frames and 1025 packets. 1027 5. HTTP/3 Profile 1029 *Authors' Note:* The HTTP/3 mapping document is subject to change. 1030 This section is based on our best understanding of draft-ietf- 1031 quic-http-25. The authors will track developments and will update 1032 this section accordingly. 1034 HTTP over multicast QUIC depends on HTTP server push, as described in 1035 Section 4.4 of [QUIC-HTTP]. Section 5.2 below applies an additional 1036 constraint on the use of server push. A multicast sender 1037 participating in a session pushes resources as a series of QUIC 1038 "STREAM" frames carrying HTTP/3 "PUSH_PROMISE", "HEADERS" and "DATA" 1039 frames. Examples of this are provided in Appendix B.2. Senders MUST 1040 comply with the requirements of the session parameters, as described 1041 earlier in Section 3. 1043 The profile of HTTP/3 specified in this section places additional 1044 constraints on the use of metadata compression (Section 5.3). 1046 5.1. HTTP Connection Settings 1048 The HTTP/3 "SETTINGS" frame is prohibited by this profile. 1049 Participants MUST NOT make any attempt to send this frame type. 1050 Reception of this frame MUST be handled as described in Section 5.6. 1052 5.2. Server Push 1054 Server push is, by default, disabled for HTTP/3 connections. A 1055 conventional HTTP/3 client enables and manages server push by 1056 controlling the maximum Push ID ([QUIC-HTTP], Section 7.2.7), 1057 achieved by sending the HTTP/3 "MAX_PUSH_ID" frame. 1059 This profile mandates the use of server push, and specifies no means 1060 to disable it. The maximum Push ID for multicast QUIC sessions 1061 (initial and always) is 2^62. Values of Push ID SHALL be allocated 1062 in accordance with [QUIC-HTTP]. 1064 Server push concurrency in multicast QUIC is described in 1065 Section 3.5. There is no role for the HTTP/3 "MAX_PUSH_ID" frame and 1066 it is prohibited. Participants MUST NOT send this frame type. 1067 Reception of this frame type MUST be handled as described in 1068 Section 5.6. 1070 For this profile, the Stream Type for any new server-initiated 1071 unidirectional stream MUST be Server Push ("0x01"). 1073 The HTTP/3 "CANCEL_PUSH" frame MAY be used by sending participants to 1074 abort sending a response for the identified server push. Usage of 1075 this frame SHALL follow the guidance for servers in [QUIC-HTTP]. 1077 Receiving participants MUST NOT make any attempt to send HTTP/3 1078 "CANCEL_PUSH" frames to the multicast group. 1080 Conventionally, pushed responses are associated with an explicit 1081 request from a client. This is not possible when using a 1082 unidirectional transport such as multicast IP. This profile reserves 1083 the first client-initiated, bidirectional QUIC stream. HTTP/3 1084 "PUSH_PROMISE" frames MUST be sent on this reserved Stream ID. 1086 *Authors' Note:* The exact value of this Stream ID is currently in 1087 flux. This section will track developments and will be updated 1088 accordingly. It is currently expected to be Stream ID 0. 1090 5.3. Metadata Compression 1092 The compression of HTTP header fields is considered in QPACK 1093 [QUIC-QPACK], which describes two methods for the compression of HTTP 1094 header fields: indexing (via static or dynamic tables) and Huffman 1095 encoding. 1097 A multicast QUIC session, as described in the present document, does 1098 not provide the assurances (receiver participation, transport 1099 reliability) required to sufficiently maintain the dynamic decoding 1100 context. Therefore, this document requires that endpoints SHALL NOT 1101 use dynamic indexing. It is RECOMMENDED that endpoints use static 1102 indexing and/or Huffman encoding in order to benefit from the 1103 remaining compression methods available. 1105 5.4. Session Tear-down 1107 A multicast QUIC session MAY be explicitly torn down by means of the 1108 "Connection: close" HTTP header described in section 6.6 of 1109 [RFC7230]. A sender intending to leave the session SHOULD include 1110 the "Connection: close" header in its response metadata. A sender 1111 SHOULD transmit all outstanding frames related to remaining request/ 1112 response exchanges before ending transmission to the multicast group. 1113 A receiver SHOULD continue to receive and process frames until all 1114 outstanding request/response exchanges are complete. 1116 The HTTP/3 "GOAWAY" frame is prohibited. Participants MUST NOT send 1117 this and reception MUST be handled as described in Section 5.6. 1119 5.5. HTTP/3 Extension frames 1121 HTTP/3 extension frames (e.g. "ALTSVC") are prohibited by this 1122 profile. Participants MUST NOT make any attempt to send extension 1123 frame types. Reception of these MUST be handled as described in 1124 Section 5.6. 1126 5.6. Prohibited HTTP/3 Frames 1128 The following HTTP/3 frames MUST NOT be transmitted by participants: 1129 "DUPLICATE_PUSH", "GOAWAY", "MAX_PUSH_ID", "SETTINGS". 1131 In addition, all HTTP/3 extension frame types MUST NOT be transmitted 1132 by participants. 1134 The following HTTP/3 frames MUST NOT be transmitted by receivers: 1135 "CANCEL_PUSH". 1137 Reception of a prohibited HTTP/3 frame is a protocol error. 1138 Receivers MUST ignore prohibited HTTP/3 frames. 1140 6. Application-Layer Security 1142 As already described in Section 3.1, the implicit cipher suite used 1143 by a multicast QUIC session makes very limited provision for security 1144 in the transport and session layers. This section profiles the use 1145 of some additional features to provide equivalent functionality at 1146 the application-layer. 1148 6.1. Content Integrity 1150 In many applications, it is important to ensure that an HTTP 1151 representation has been received intact (i.e. has not suffered from 1152 transmission loss or random bit errors) before passing the received 1153 object on to the receiving application. A mechanism is therefore 1154 specified here to provide end-to-end content integrity protection for 1155 HTTP representations in transit. The use of this content integrity 1156 mechanism is RECOMMENDED. 1158 *Authors' Note:* We invite review comments on mandating the use of 1159 this content integrity mechanism. 1161 [RFC3230] specifies an instance digest HTTP header called "Digest". 1162 A sender MAY include this header in the HTTP/3 "HEADERS" frame of any 1163 representation it transmits and a receiver MAY use this header to 1164 validate the integrity of the received representation once it has 1165 been reassembled. Where this validation fails, the receiver SHOULD 1166 discard the representation without processing it further. 1168 Note that the digest value protects a whole HTTP instance (i.e. the 1169 representation of a resource at the point of transmission as opposed 1170 to the body of a particular HTTP message). In cases where partial 1171 representations are fragmented over one or more HTTP response 1172 messages, the digest value is computed over the complete 1173 representation prior to fragmentation into partial responses. 1175 Any of the algorithms specified in the IANA registry of digest 1176 algorithms (http://www.iana.org/assignments/http-dig-alg/http-dig- 1177 alg.xhtml#http-dig-alg-1) MAY be used in conjunction with the 1178 "Digest" header. There is no requirement for participants to support 1179 the full set of algorithms. 1181 6.2. Content Authenticity 1183 In some applications, it is important for a receiver to reassure 1184 itself that an HTTP representation has been received from an 1185 authentic source. It is also sometimes useful for a receiver to know 1186 that the information has not been tampered with in transit by a 1187 malicious intermediate actor. A mechanism is therefore specified 1188 here to prove the authenticity of HTTP messages in transit. The use 1189 of this content authenticity mechanism is RECOMMENDED for senders 1190 implementing this specification. 1192 *Authors' Note:* We invite review comments on mandating the use of 1193 this content authenticity mechanism. 1195 [I-D.cavage-http-signatures] specifies a means of securely signing 1196 metadata associated with any HTTP message. The resulting digital 1197 signature is conveyed in the "Signature" header of the message 1198 itself. The "Signature" header also conveys a list of HTTP header 1199 fields over which the signature was computed. A receiver MAY verify 1200 the "Signature" header in order to validate the authenticity of 1201 received metadata. Where this validation fails, the receiver SHOULD 1202 discard or ignore any related metadata and/or data without processing 1203 it further. 1205 Note that the signature proves the authenticity of the metadata in a 1206 single HTTP message. A "Signature" header MAY be included separately 1207 in the HTTP/3 "PUSH_PROMISE" frame (protecting the request metadata) 1208 and in the final (or only) HTTP/3 "HEADERS" frame relating to a 1209 particular resource (protecting the response metadata). In order to 1210 provide an additional level of protection, however, it is RECOMMENDED 1211 that the signature be computed over the combined request metadata 1212 (from the HTTP/3 "PUSH_PROMISE" frame) and the corresponding response 1213 metadata (from the HTTP/3 "HEADERS" frames) of the same resource. 1214 This binds the request metadata and response metadata together, 1215 providing the receiver with additional reassurance of authenticity. 1216 In this latter case, the combined digital signature SHALL be conveyed 1217 in the final (or only) HTTP/3 "HEADERS" frame. 1219 In applications where the detection of replay attacks is a 1220 requirement, it is RECOMMENDED that the "Date" header be included in 1221 the scope of the signature. It is RECOMMENDED that receivers use the 1222 value of the "Date" header for replay detection using appropriate 1223 strategies (e.g. checking for freshness). The definition of such 1224 strategies is beyond the scope of this document. 1226 In applications where the authenticity and integrity of the 1227 transmission are both important, it is RECOMMENDED that the "Digest" 1228 header specified in Section 6.1 above is included in the scope of the 1229 signature. By signing the instance digest, the authenticity and 1230 integrity of the HTTP message body are also assured in addition to 1231 that of the metadata. 1233 Any of the algorithms specified in the IANA registry of signature 1234 algorithms (http://www.iana.org/assignments/signature-algorithms) MAY 1235 be used in conjunction with the "Signature" header. There is no 1236 requirement for participants to support the full set of algorithms. 1238 6.3. Content Confidentiality 1240 In applications where there is a requirement for the content itself 1241 to remain confidential, appropriate steps SHOULD be taken to protect 1242 the application payload, for example by encrypting it. This document 1243 does not preclude the use of application-level encryption, but does 1244 not specify a mechanism for the distribution of content decryption 1245 keys. 1247 7. Loss Recovery 1249 Because the acknowledgement of received packets to multicast groups 1250 is prohibited by this specification (Section 4.11) the detection of 1251 discarded or corrupted packets is the sole responsibility of the 1252 receiver, and such losses must be recovered by means other than the 1253 retransmission mechanism specified in [QUIC-TRANSPORT] and 1254 [QUIC-RECOVERY]. 1256 7.1. Forward Error Correction 1258 *Authors' Note:* A simple parity-based Forward Error Correction 1259 scheme was removed from the experimental QUIC wire protocol 1260 specification in version Q032. The IETF's QUIC Working Group is 1261 chartered to specify one (or more) new FEC schemes in the future. 1262 This section will track developments in this area, and will be 1263 updated accordingly. 1265 A sender MAY make use of a suitable Forward Error Correction scheme 1266 to allow a receiver to reconstruct lost packets from those that have 1267 been successfully received. 1269 7.2. Unicast Repair 1271 In the case where a lost QUIC packet cannot be recovered using 1272 Forward Error Correction, either because the number of packets lost 1273 exceeds the scheme's threshold for reconstruction, or because FEC is 1274 not in use on the multicast QUIC session, a receiver MAY instead 1275 recover the missing payload data using conventional unicast HTTP 1276 requests to an origin server. 1278 o The total size of the resource is indicated in the "content- 1279 length" response header carried in the HTTP/3 "HEADERS" frame. 1281 o The location of the missing data can be determined by examining 1282 the Offset field in the QUIC "STREAM" frame headers of 1283 successfully received QUIC packets. 1285 Using this information, a receiver MAY compose an efficient HTTP 1286 range request [RFC7233] to the origin server indicated in the URL. 1287 Several disjoint ranges MAY be combined into a single HTTP request. 1288 A receiver MAY direct its request to an alternative server using Alt- 1289 Svc information received on the multicast QUIC session, or else 1290 received as part of a previous unicast HTTP response according to the 1291 rules in [RFC7838]. 1293 8. Transmission of Partial Content 1295 Under certain circumstances, a sender may not be in full possession 1296 of a resource body when transmission begins, or may not be able to 1297 guarantee that a transmission will complete. In such cases, the 1298 sender MAY employ the syntax of an HTTP range request [RFC7233] to 1299 indicate partial content, as specified below. All receivers SHALL 1300 implement support for such HTTP range requests. 1302 If partial content is to be transmitted: 1304 o The "range" header (Section 3.1 of [RFC7233]) SHALL be present in 1305 the HTTP/3 "PUSH_PROMISE" frame. 1307 o The corresponding HTTP/3 "HEADERS" frame SHALL indicate HTTP 1308 status code 206. 1310 * The range being transmitted SHALL be indicated in a "content- 1311 range" header field and the size of the complete resource 1312 indicated in a "content-length" header field. 1314 9. Protocol Identifier 1316 The HTTP over multicast QUIC protocol specified in this document is 1317 identified by the application-layer protocol negotiation (ALPN) 1318 [RFC7301] identifier "h3m". The IANA registration of this protocol 1319 identifier can be found in Section 12.1. This reserves the ALPN 1320 identifier space but describes a protocol that does not use TLS. The 1321 usage of the "h3m" identifier for discoverability is described in 1322 Section 10. 1324 9.1. Draft Version Identification 1326 *RFC Editor's Note:* Please remove this section prior to 1327 publication of a final version of this document. 1329 Only implementations of the final, published RFC can identify 1330 themselves as "h3m". Until such an RFC exists, implementations MUST 1331 NOT identify themselves using this string. 1333 Implementations of draft versions of the protocol MUST add the string 1334 "-" and the corresponding draft number to the identifier. For 1335 example, draft-pardue-quic-http-mcast-06 is identified using the 1336 string "h3m-06". 1338 Non-compatible experiments that are based on these draft versions 1339 MUST append the string "-" and an experiment name to the identifier. 1340 For example, an experimental implementation based on draft-pardue- 1341 quic-http-mcast-06 which uses extension features not registered with 1342 the appropriate IANA registry might identify itself as "h3m-06- 1343 extension-foo". Note that any label MUST conform to the "token" 1344 syntax defined in Section 3.2.6 of [RFC7230]. Experimenters are 1345 encouraged to coordinate their experiments. 1347 10. Discovery of Multicast QUIC Sessions 1349 The announcement and discovery of services operating over multicast 1350 IP has previously been specified by the Session Description Protocol 1351 (SDP) [RFC4566], Session Announcement Protocol [RFC2974] and Session 1352 Initiation Protocol [RFC3261]. These are typically deployed together 1353 and in conjunction with a multicast-friendly transport such as the 1354 Real-time Transport Protocol (RTP) [RFC3550]. 1356 In contrast, the present document specifies a mechanism for 1357 advertising services that is built into HTTP metadata and is 1358 consistent across unicast and multicast resource delivery modes. 1359 This means that a single application-layer can be used for service 1360 advertisement/discovery, and for bulk data transmission/reception. 1361 Specifically, the "Alt-Svc" HTTP header is specified as the means to 1362 advertise multicast services from a unicast service. A unicast HTTP 1363 response MAY be decorated with an Alt-Svc value that hints to the 1364 client about the availability of the resource via a multicast QUIC 1365 session. A client that supports such a multicast QUIC session MAY 1366 then transparently switch to it. 1368 Symmetrically, the "Alt-Svc" header can also be used to advertise the 1369 unicast service from a multicast service. A resource transmitted as 1370 part of a multicast QUIC session MAY be decorated with an Alt-Svc 1371 value that hints to the client about the availability of the resource 1372 via an alternative unicast HTTP server. A receiver MAY then use this 1373 HTTP server for unicast resource patching (Section 7.2). 1375 Where HTTP over multicast QUIC sessions are advertised using Alt-Svc, 1376 the protocol identifier SHALL be "h3m", as specified in Section 9. 1378 10.1. Source-specific Multicast Advertisement 1380 Source-specific multicast (SSM) [RFC4607] MAY be used for the 1381 delivery of multicast services. 1383 *Authors' Note:* We invite review comments on mandating the use of 1384 source-specific multicast only. 1386 This document specifies the "source-address" parameter for Alt-Svc, 1387 which is used to provide the SSM source address to endpoints. 1389 Syntax: 1391 source-address = uri-host; see RFC7230, Section 2.7 1393 For example: 1395 source-address="192.0.2.1" 1397 When a multicast QUIC session is provided using SSM, the "source- 1398 address" parameter MUST be advertised. 1400 10.2. Session Parameter Advertisement 1402 The concept of session parameters is introduced in Section 2.2. This 1403 section details how the session parameters are expressed as Alt-Svc 1404 parameters. 1406 10.2.1. Cipher Suite 1408 This document specifies the "cipher-suite" parameter for Alt-Svc, 1409 which carries the cipher suite in use by a multicast QUIC session. 1410 "cipher-suite" MUST contain one of the values contained in the TLS 1411 Cipher Suite Registry (http://www.iana.org/assignments/tls- 1412 parameters/tls-parameters.xhtml#tls-parameters-4): 1414 Syntax: 1416 cipher-suite = 4*4 HEXDIG 1418 For example, the following specifies cipher suite 0x13,0x01 1419 ("TLS_AES_128_GCM_SHA256"): 1421 cipher-suite=1301 1423 The requirements for endpoint usage of "cipher-suite" are described 1424 in Section 3.1. 1426 10.2.2. Session Key 1428 This document specifies the "key" parameter for Alt-Svc, which 1429 carries the cryptographic key in use by the multicast QUIC session. 1431 Syntax: 1433 key = *HEXDIG 1434 For example: 1436 key=4adf1eab9c2a37fd 1438 The requirements for endpoint usage of "key" are described in 1439 Section 3.1. 1441 10.2.3. Session Cipher Initialization Vector 1443 This document specifies the "iv" parameter for Alt-Svc, which carries 1444 the cipher Initialization Vector (IV) in use by the multicast QUIC 1445 session. 1447 Syntax: 1449 iv = *HEXDIG 1451 For example: 1453 iv=4dbe593acb4d1577ad6ba7dc3189834e 1455 The requirements for endpoint usage of "iv" are described in 1456 Section 3.1. 1458 10.2.4. Session Identification 1460 This document defines the "session-id" parameter for Alt-Svc, which 1461 carries the multicast QUIC session identifier. 1463 Syntax: 1465 session-id = *HEXDIG 1467 For example, the following specifies session 101 (0x65 hexadecimal): 1469 session-id=65 1471 The requirements for endpoint usage of "session-id" are described in 1472 Section 2.3. In the above example, the Destination Connection ID 1473 field in every QUIC packet header would be one byte in size. For a 1474 session-id of BADBEEF then then Destintation Connection ID field in 1475 every QUIC packet header would be four bytes in size. 1477 10.2.5. Session Idle Timeout Period 1479 This document specifies the "session-idle-timeout" parameter for Alt- 1480 Svc, which carries the idle timeout period of a multicast QUIC 1481 session. 1483 Syntax: 1485 session-idle-timeout = *DIGIT ; number of seconds between 0 and 600 1487 For example, the following specifies a one-minute session idle 1488 timeout period: 1490 session-idle-timeout=60 1492 The requirements for endpoint usage of "session-idle-timeout" are 1493 described in Section 3.3. 1495 10.2.6. Resource Concurrency 1497 This document specifies the "max-concurrent-resources" parameter for 1498 Alt-Svc, which expresses the maximum number of concurrent active 1499 resources from the sender in a multicast QUIC session. 1501 Syntax: 1503 max-concurrent-resources = *DIGIT ; unsigned 32-bit integer 1505 For example, the following specifies that no more than 12 (decimal) 1506 resources will be concurrently active in the session: 1508 max-concurrent-resources=12 1510 The requirements for endpoint usage of "max-concurrent-resources" are 1511 described in Section 3.5. 1513 10.2.7. Session Peak Flow Rate 1515 This document specifies the "peak-flow-rate" parameter for Alt-Svc, 1516 which expresses the expected maximum aggregate transfer rate of data 1517 from all sources of the multicast QUIC session. 1519 Syntax: 1521 peak-flow-rate = *DIGIT ; bits per second 1523 For example, the following specifies a peak flow rate of 550 kbits/s 1524 in the session: 1526 peak-flow-rate=550000 1528 The requirements for endpoint usage of "peak-flow-rate" are described 1529 in Section 3.4. 1531 10.2.8. Digest Algorithm 1533 This document specifies the "digest-algorithm" parameter for Alt-Svc, 1534 which carries the digest algorithm in use by a multicast QUIC 1535 session. "digest-algorithm" MUST contain one of the values defined in 1536 the HTTP Digest Algorithm Values registry 1537 (https://www.iana.org/assignments/http-dig-alg/http-dig- 1538 alg.xhtml#http-dig-alg-1). 1540 Syntax: 1542 digest-algorithm = token 1544 For example, the following specifies a digest algorithm of SHA-256: 1546 digest-algorithm=SHA-256 1548 The requirements for endpoint usage of "digest-algorithm" are 1549 described in Section 3.7. 1551 10.2.9. Signature Algorithm 1553 This document specifies the "signature-algorithm" parameter for Alt- 1554 Svc, which carries the signature algorithm in use by a multicast QUIC 1555 session. "signature-algorithm" MUST contain one of the values defined 1556 in the Signature Algorithms registry 1557 (http://www.iana.org/assignments/signature-algorithms). 1559 Syntax: 1561 signature-algorithm = token 1563 For example, the following specifies a signature algorithm of SHA- 1564 256: 1566 signature-algorithm=rsa-sha256 1568 The requirements for endpoint usage of "signature-algorithm" are 1569 described in Section 3.8. 1571 10.2.10. Extensions 1573 This document specifies the "extensions" parameter for Alt-Svc, which 1574 carries a list of extension types potentially in use by a multicast 1575 QUIC session. "extensions" MUST only contain values from the QUIC 1576 Transport Parameter registry ([QUIC-TRANSPORT], section 22.2) that 1577 have explicit support for multicast QUIC. Each entry in the list 1578 consists of a key identifying the transport parameter, and an 1579 optional value. Both the key and the value are hex-encoded. 1581 Syntax: 1583 extensions = DQUOTE ext-transport-param 1584 *[ "," ext-transport-param ] DQUOTE 1585 ext-transport-param = ext-key [ "=" ext-value ] 1586 ext-key = 4*4HEXDIG; Transport Parameter key 1587 ext-value = *HEXDIG; Optional Transport Parameter value 1589 For example, the following specifies two extensions: 1591 extensions="0094,0d0d=f00" 1593 The requirements for endpoint usage of "extensions" are described in 1594 Section 3.6 1596 11. Security and Privacy Considerations 1598 This document specifies a profile of QUIC and HTTP/3 that changes the 1599 security model. In order to address this, application-level security 1600 methods are described in Section 6. This document does not preclude 1601 the use of secure multicast approaches that may provide additional 1602 security assurances required for certain use cases. 1604 The use of side-channel or out-of-band technologies (potentially 1605 bidirectional interactions) to support multicast QUIC sessions are 1606 considered out of this document's scope. Services using such 1607 technologies should apply their security considerations accordingly. 1609 11.1. Pervasive Monitoring 1611 Certain multicast deployment architectures may require the use of a 1612 session decryption key shared by all participants. Furthermore, the 1613 discovery mechanism described in this document provides a means for a 1614 receiver to obtain a session decryption key without joining the 1615 session. The act of removing packet protection in order to inspect 1616 or modify application contents may, in certain deployments, be 1617 trivial. The exploration of restricting key learning or session 1618 joining to authorised participants goes beyond the scope of this 1619 document. 1621 Because in-band multicast interactions are unidirectional, the impact 1622 of Pervasive Monitoring [RFC7258] on in-band traffic flows is 1623 inherently reduced. Actors can only inspect or modify sender- 1624 initiated traffic. Additional measures for content confidentiality 1625 may mitigate the impact further. This is discussed in Section 6.3. 1627 Further Pervasive Monitoring concerns are addressed in the following 1628 sections. 1630 11.1.1. Large-scale Data Gathering and Correlation 1632 Multicast QUIC sessions decouple sending and receiving participants. 1633 Session participation is subject to operations that allow an endpoint 1634 to join or leave a multicast group, typically IGMP [RFC3376] or MLD 1635 [RFC3810]. The propagation intent of these messages travelling 1636 deeper through a network hierarchy generally leads to the 1637 anonymisation of data if implemented as specified. It may be 1638 possible to gather user-identifiable messages close to the network 1639 edge, for example a router logging such messages. However, this 1640 would require wide-ranging access across Internet Service Provider 1641 networks. Therefore, while such attacks are feasible, it can be 1642 asserted that gathering and correlating user-identifiable traffic is 1643 difficult to perform covertly and at scale. 1645 11.1.2. Changing Content 1647 Sessions that use a symmetric key for packet protection are subject 1648 to the possibility of a malicious actor modifying traffic at some 1649 point in the network between a legitimate sender and one (or more) 1650 receivers. Receiver-side validation, as specified in Section 6 of 1651 the present document, and also in [QUIC-TRANSPORT], allows for the 1652 detection of such modification. Two approaches help mitigate the 1653 impact of modification; the first is application-level methods that 1654 protect data (Section 6.1) and metadata (Section 6.2); the second is 1655 reduction of the QUIC packet attack surface by means of removal of 1656 many frame types (Section 4.12 and Section 5.6). 1658 11.2. Protection of Discovery Mechanism 1660 Multicast QUIC session advertisements SHOULD be conveyed over a 1661 secure transport that guarantees authenticity and integrity in order 1662 to mitigate attacks related to a malicious service advertisement, for 1663 example a "man in the middle" directing endpoints to a service that 1664 may lead to other attacks or exploitations. 1666 *Authors' Note:* We invite review comments on mandating the use of 1667 a secure transport for advertising sessions. 1669 Endpoints that make use of multicast QUIC session advertisements 1670 SHOULD have reasonable assurance that the alternative service is 1671 under control of, and valid for, the whole origin, as described in 1672 Section 2.1 of [RFC7838]. Section 6.2 discusses measures that may be 1673 used to fulfil this requirement. 1675 11.3. Spoofing 1677 11.3.1. Spoofed Ack Attacks 1679 The Spoofed "ACK" attack described in Section 13.1 of 1680 [QUIC-TRANSPORT] is out of scope because use of the QUIC "ACK" frame 1681 is prohibited (Section 4.11) by the present document. 1683 11.3.2. Sender Spoofing 1685 A malicious actor may be able to stage a spoof attack by sending fake 1686 QUIC packets to a multicast QUIC session. This could affect the 1687 operation or behaviour of receivers. In a multicast scenario, this 1688 form of attack has the potential to scale massively. 1690 The feasibility of spoofing a multicast sender is governed by the 1691 characteristics of the multicast deployment and network 1692 infrastructure. The use of source-specific multicast [RFC4607] may 1693 reduce the feasibility. The use of content authenticity 1694 (Section 6.2) may mitigate concerns for the application-level 1695 messages. However, there remains the possibility for transport-level 1696 messages to be spoofed. Multicast applications should consider 1697 further mitigations to address this concern. 1699 11.3.3. Receiver Spoofing 1701 Client source address concerns discussed in Section 7.5 of 1702 [QUIC-TRANSPORT] are out of scope because the connection 1703 establishment is replaced with session establishment in the present 1704 document. Further, the impact that spoofed receivers would have on 1705 the sender is minimal. The impact of malicious participants on the 1706 network is discussed in Section 11.6.2. 1708 11.4. Replay Attacks 1710 Conventional QUIC strategies for protecting against replay attacks 1711 apply similarly here. 1713 Certain multicast QUIC sessions may use a shared key for transport- 1714 level encryption, which would allow an attacker to record, decrypt, 1715 repackage and replay QUIC packets. Section 6.2 discusses how the 1716 application-level contents may be protected from replay (by signing 1717 the "Date" HTTP header), which provides some mitigation to the 1718 success rate or effects of replay attacks. 1720 11.5. Message Deletion 1722 Since HTTP over multicast QUIC is designed to tolerate unreliable 1723 delivery, the impacts of message deletion attacks are presumed to be 1724 small. Deletion of packets carrying HTTP headers will cause a 1725 receiver to ignore subsequent packets carrying body data. 1726 Furthermore, the use of multicast QUIC sessions is opportunistic; 1727 disruption in service (for example, deleting packets and causing a 1728 receiver to fail in construction of a content object) is mitigated by 1729 falling back to a unicast service. Considerations for how this may 1730 affect the performance of the unicast service are given in 1731 Section 11.6.3. 1733 11.6. Denial of Service 1735 11.6.1. Unprotected Frames and Packets 1737 The handling of unprotected QUIC packets is discussed in section 1738 9.1.4 of [QUIC-TLS]. The profile described in the present document 1739 provides the means for a multicast sender to protect QUIC packets 1740 with a shared key, which is not a strong protection. The weak 1741 protection of QUIC packets could present a denial-of-service risk. 1742 To mitigate the impact of handling such QUIC packets, certain frames 1743 and packets are prohibited as described in (Section 4.12 and 1744 Section 5.6). 1746 The frame types that are allowed by this profile do not present a 1747 risk of denial of service. Concerns over authenticity and integrity 1748 are addressed by the application-layer protection mechanisms 1749 described in Section 6. 1751 11.6.2. Network Performance Degradation 1753 The possibility for malfunctioning or malicious participants to 1754 degrade the network is a broad issue and considered out of scope for 1755 this document. Guidelines and concerns discussed in UDP Best 1756 Practices [RFC8085] and other sources apply equally here. This 1757 specification does not preclude the use of network performance 1758 degradation mitigation solutions such as network circuit breakers. 1760 11.6.3. Unicast Repair Stampeding Herd 1762 Deployments that support the unicast repair mechanism described in 1763 Section 7.2 should be aware that a triggering of this behaviour 1764 (either deliberate, planned or unplanned) in a large population of 1765 multicast receivers may cause a stampeding herd of client requests to 1766 the unicast repair service. Service operators SHOULD mitigate the 1767 impact of stampeding herd on their deployment. 1769 11.7. Receiver Resource Usage 1771 The application of receiver-side validation, as defined in the 1772 present document and in [QUIC-TRANSPORT], adds some protection 1773 against allocating resource to the processing of bad data. 1775 11.8. Unicast Repair Information Leakage 1777 The unicast repair mechanism may lead to the leakage of user 1778 behaviour data. An attacker could gain insight into any receiver 1779 participating in a multicast QUIC session, for example by monitoring 1780 the TCP port of the unicast alternative. This alone is no worse than 1781 current abilities to monitor unicast interactions, for example 1782 observing the SNI field contained in a TLS ClientHello. The complete 1783 protection of unicast interactions is beyond the scope of this 1784 document. However, knowledge that a user (or group of users) has 1785 participated in a session is sensitive and may be obtained by 1786 correlation between with observable multicast and unicast traffic. 1788 To give an example, a malicious "man in the middle" could purposely 1789 cause all receivers to perform a unicast repair (by disrupting the 1790 QUIC traffic flow in some way). The disruption is untargeted and may 1791 be simple to orchestrate, but the correlation of user activity data, 1792 especially across a distributed repair service (e.g. a CDN), requires 1793 resources that may reduce the attractiveness of such an attack. 1795 The ability for an attacker to disrupt multicast QUIC sessions is 1796 mitigated by this profile (mainly the prohibition of frames and 1797 packets). Application-layer security measures described in Section 6 1798 reduce the feasibility further. 1800 Multicast receivers concerned about this form of leakage can 1801 eliminate this risk completely by disabling support for unicast 1802 repair, at the potential cost of reduced service quality. 1804 12. IANA Considerations 1806 12.1. Registration of Protocol Identification String 1808 This document creates a new registration for the identification of 1809 the HTTP over multicast QUIC protocol in the "Application-Layer 1810 Protocol Negotiation (ALPN) Protocol IDs" registry established by 1811 [RFC7301]. 1813 The "h3m" string identifies HTTP semantics expressed as HTTP mapped 1814 to a QUIC layer and carried over IP multicast: 1816 Protocol: Bulk data transport using HTTP over multicast QUIC 1817 Identification Sequence: 0x68 0x71 0x6D ("h3m") 1819 Specification: This document, Section 9 1821 This entry reserves an identifier that is not allowed to appear in 1822 TLS Application-Layer Protocol Negotiation. 1824 12.2. Registration of Alt-Svc parameters 1826 This document creates seven registrations for the identification of 1827 parameters for the "Hypertext Transfer Protocol (HTTP) Alt-Svc 1828 Parameter Registry" established by [RFC7838] 1829 (http://www.iana.org/assignments/tls-extensiontype-values/tls- 1830 extensiontype-values.xhtml#alpn-protocol-ids). 1832 12.2.1. Source Address 1834 Parameter name: source-address 1836 Specification: This document, Section 10.1 1838 12.2.2. Cipher Suite 1840 Parameter name: cipher-suite 1842 Specification: This document, Section 10.2.1 1844 12.2.3. Key 1846 Parameter name: key 1848 Specification: This document, Section 10.2.2 1850 12.2.4. Initialization Vector 1852 Parameter name: iv 1854 Specification: This document, Section 10.2.3 1856 12.2.5. Session Identifier 1858 Parameter name: session-id 1860 Specification: This document, Section 10.2.4 1862 12.2.6. Session Idle Timeout 1864 Parameter name: session-idle-timeout 1866 Specification: This document, Section 10.2.5 1868 12.2.7. Maximum Concurrent Resources 1870 Parameter name: max-concurrent-resources 1872 Specification: This document, Section 10.2.6 1874 12.2.8. Peak Flow Rate 1876 Parameter name: peak-flow-rate 1878 Specification: This document, Section 10.2.7 1880 12.2.9. Digest Algorithm 1882 Parameter name: digest-algorithm 1884 Specification: This document, Section 10.2.8 1886 12.2.10. Signature Algorithm 1888 Parameter name: signature-algorithm 1890 Specification: This document, Section 10.2.9 1892 12.2.11. Extension 1894 Parameter name: extension 1896 Specification: This document, Section 10.2.10 1898 13. References 1900 13.1. Normative References 1902 [I-D.cavage-http-signatures] 1903 Cavage, M. and M. Sporny, "Signing HTTP Messages", draft- 1904 cavage-http-signatures-12 (work in progress), October 1905 2019. 1907 [QUIC-HTTP] 1908 Bishop, M., Ed., "Hypertext Transfer Protocol Version 3 1909 (HTTP/3)", draft-ietf-quic-http-25 (work in progress). 1911 [QUIC-QPACK] 1912 Krasic, C., Ed., Bishop, M., Ed., and A. Frindell, Ed., 1913 "QPACK: Header Compression for HTTP over QUIC", draft- 1914 ietf-quic-qpack-12 (work in progress). 1916 [QUIC-TRANSPORT] 1917 Iyengar, J., Ed. and M. Thomson, Ed., "QUIC: A UDP-Based 1918 Multiplexed and Secure Transport", draft-ietf-quic- 1919 transport-25 (work in progress). 1921 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 1922 Requirement Levels", BCP 14, RFC 2119, 1923 DOI 10.17487/RFC2119, March 1997, 1924 . 1926 [RFC3168] Ramakrishnan, K., Floyd, S., and D. Black, "The Addition 1927 of Explicit Congestion Notification (ECN) to IP", 1928 RFC 3168, DOI 10.17487/RFC3168, September 2001, 1929 . 1931 [RFC3230] Mogul, J. and A. Van Hoff, "Instance Digests in HTTP", 1932 RFC 3230, DOI 10.17487/RFC3230, January 2002, 1933 . 1935 [RFC4607] Holbrook, H. and B. Cain, "Source-Specific Multicast for 1936 IP", RFC 4607, DOI 10.17487/RFC4607, August 2006, 1937 . 1939 [RFC5234] Crocker, D., Ed. and P. Overell, "Augmented BNF for Syntax 1940 Specifications: ABNF", STD 68, RFC 5234, 1941 DOI 10.17487/RFC5234, January 2008, 1942 . 1944 [RFC7230] Fielding, R., Ed. and J. Reschke, Ed., "Hypertext Transfer 1945 Protocol (HTTP/1.1): Message Syntax and Routing", 1946 RFC 7230, DOI 10.17487/RFC7230, June 2014, 1947 . 1949 [RFC7233] Fielding, R., Ed., Lafon, Y., Ed., and J. Reschke, Ed., 1950 "Hypertext Transfer Protocol (HTTP/1.1): Range Requests", 1951 RFC 7233, DOI 10.17487/RFC7233, June 2014, 1952 . 1954 [RFC7234] Fielding, R., Ed., Nottingham, M., Ed., and J. Reschke, 1955 Ed., "Hypertext Transfer Protocol (HTTP/1.1): Caching", 1956 RFC 7234, DOI 10.17487/RFC7234, June 2014, 1957 . 1959 [RFC7301] Friedl, S., Popov, A., Langley, A., and E. Stephan, 1960 "Transport Layer Security (TLS) Application-Layer Protocol 1961 Negotiation Extension", RFC 7301, DOI 10.17487/RFC7301, 1962 July 2014, . 1964 [RFC7405] Kyzivat, P., "Case-Sensitive String Support in ABNF", 1965 RFC 7405, DOI 10.17487/RFC7405, December 2014, 1966 . 1968 [RFC7838] Nottingham, M., McManus, P., and J. Reschke, "HTTP 1969 Alternative Services", RFC 7838, DOI 10.17487/RFC7838, 1970 April 2016, . 1972 [RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC 1973 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, 1974 May 2017, . 1976 13.2. Informative References 1978 [QUIC-RECOVERY] 1979 Iyengar, J., Ed. and I. Swett, Ed., "QUIC Loss Detection 1980 and Congestion Control", draft-ietf-quic-recovery-25 (work 1981 in progress). 1983 [QUIC-TLS] 1984 Thomson, M., Ed. and S. Turner, Ed, Ed., "Using Transport 1985 Layer Security (TLS) to Secure QUIC", draft-ietf-quic- 1986 tls-22 (work in progress). 1988 [RFC1112] Deering, S., "Host extensions for IP multicasting", STD 5, 1989 RFC 1112, DOI 10.17487/RFC1112, August 1989, 1990 . 1992 [RFC1191] Mogul, J. and S. Deering, "Path MTU discovery", RFC 1191, 1993 DOI 10.17487/RFC1191, November 1990, 1994 . 1996 [RFC2974] Handley, M., Perkins, C., and E. Whelan, "Session 1997 Announcement Protocol", RFC 2974, DOI 10.17487/RFC2974, 1998 October 2000, . 2000 [RFC3261] Rosenberg, J., Schulzrinne, H., Camarillo, G., Johnston, 2001 A., Peterson, J., Sparks, R., Handley, M., and E. 2002 Schooler, "SIP: Session Initiation Protocol", RFC 3261, 2003 DOI 10.17487/RFC3261, June 2002, 2004 . 2006 [RFC3376] Cain, B., Deering, S., Kouvelas, I., Fenner, B., and A. 2007 Thyagarajan, "Internet Group Management Protocol, Version 2008 3", RFC 3376, DOI 10.17487/RFC3376, October 2002, 2009 . 2011 [RFC3550] Schulzrinne, H., Casner, S., Frederick, R., and V. 2012 Jacobson, "RTP: A Transport Protocol for Real-Time 2013 Applications", STD 64, RFC 3550, DOI 10.17487/RFC3550, 2014 July 2003, . 2016 [RFC3810] Vida, R., Ed. and L. Costa, Ed., "Multicast Listener 2017 Discovery Version 2 (MLDv2) for IPv6", RFC 3810, 2018 DOI 10.17487/RFC3810, June 2004, 2019 . 2021 [RFC4566] Handley, M., Jacobson, V., and C. Perkins, "SDP: Session 2022 Description Protocol", RFC 4566, DOI 10.17487/RFC4566, 2023 July 2006, . 2025 [RFC4821] Mathis, M. and J. Heffner, "Packetization Layer Path MTU 2026 Discovery", RFC 4821, DOI 10.17487/RFC4821, March 2007, 2027 . 2029 [RFC5737] Arkko, J., Cotton, M., and L. Vegoda, "IPv4 Address Blocks 2030 Reserved for Documentation", RFC 5737, 2031 DOI 10.17487/RFC5737, January 2010, 2032 . 2034 [RFC5740] Adamson, B., Bormann, C., Handley, M., and J. Macker, 2035 "NACK-Oriented Reliable Multicast (NORM) Transport 2036 Protocol", RFC 5740, DOI 10.17487/RFC5740, November 2009, 2037 . 2039 [RFC6676] Venaas, S., Parekh, R., Van de Velde, G., Chown, T., and 2040 M. Eubanks, "Multicast Addresses for Documentation", 2041 RFC 6676, DOI 10.17487/RFC6676, August 2012, 2042 . 2044 [RFC6726] Paila, T., Walsh, R., Luby, M., Roca, V., and R. Lehtonen, 2045 "FLUTE - File Delivery over Unidirectional Transport", 2046 RFC 6726, DOI 10.17487/RFC6726, November 2012, 2047 . 2049 [RFC7258] Farrell, S. and H. Tschofenig, "Pervasive Monitoring Is an 2050 Attack", BCP 188, RFC 7258, DOI 10.17487/RFC7258, May 2051 2014, . 2053 [RFC7450] Bumgardner, G., "Automatic Multicast Tunneling", RFC 7450, 2054 DOI 10.17487/RFC7450, February 2015, 2055 . 2057 [RFC8085] Eggert, L., Fairhurst, G., and G. Shepherd, "UDP Usage 2058 Guidelines", BCP 145, RFC 8085, DOI 10.17487/RFC8085, 2059 March 2017, . 2061 [RFC8200] Deering, S. and R. Hinden, "Internet Protocol, Version 6 2062 (IPv6) Specification", STD 86, RFC 8200, 2063 DOI 10.17487/RFC8200, July 2017, 2064 . 2066 Appendix A. Acknowledgements 2068 The authors would like to thank the following for their contributions 2069 to the design described in the present document: Brandon Butterworth, 2070 Chris Poole, Craig Taylor and David Waring. 2072 We are also grateful to Thomas Swindells and Magnus Westerlund for 2073 their helpful review comments. 2075 Appendix B. Examples 2077 This appendix contains examples of multicast QUIC session 2078 advertisement and resource transfer (with and without application- 2079 layer content security). 2081 B.1. Session Advertisement 2083 This section shows several different examples of an HTTP service 2084 advertising a multicast QUIC session. Examples are given in IPv4 2085 form, using reserved address ranges as specified in [RFC5737] and 2086 [RFC6676]. 2088 B.1.1. Source-specific Multicast QUIC Session 2090 Advertisement of a multicast QUIC session operating on the source- 2091 specific multicast group address 232.0.0.1 on port 2000 with the 2092 source address 192.0.2.1. The session ID is 16 (0x10) and the idle 2093 timeout is one minute. At most 10 resources may be concurrently 2094 active in the session and the flow rate should not exceed 10 kbits/s. 2095 The multicast transport is unencrypted. 2097 HTTP Alternative Service header field: 2099 Alt-Svc: 2100 h3m="232.0.0.1:2000"; source-address="192.0.2.1"; 2101 session-id=10; session-idle-timeout=60; 2102 max-concurrent-resources=10; peak-flow-rate=10000 2104 B.1.2. Source-specific Multicast QUIC Session with Transport Encryption 2105 using a Symmetric Key 2107 Advertisement of a multicast QUIC session operating on the IPv6 2108 globally-scoped source-specific multicast group address ff3e::1234 on 2109 port 2000 with the source address 2001:db8::1. The session ID is 16 2110 (0x10) and the idle timeout is one minute. At most 10 resources may 2111 be concurrently active in the session and the flow rate should not 2112 exceed 10 kbits/s. The multicast transport is encrypted using the 2113 AEAD cipher suite 0x13,0x01 ("TLS_AES_128_GCM_SHA256") with the 2114 shared session key and IV provided. 2116 HTTP Alternative Service header field: 2118 Alt-Svc: 2119 h3m="[ff3e::1234]:2000"; source-address="2001:db8::1"; 2120 session-id=10; session-idle-timeout=60; 2121 max-concurrent-resources=10; peak-flow-rate=10000; 2122 cipher-suite=1301; key=4adf1eab9c2a37fd; 2123 iv=4dbe593acb4d1577ad6ba7dc3189834e 2125 B.1.3. Source-specific Multicast QUIC Session with Transport 2126 Encryption, Content Integrity and Authenticity 2128 Advertisement of a multicast QUIC session operating on the IPv6 2129 globally-scoped source-specific multicast group address ff3e::1234 on 2130 port 2000 with the source address 2001:db8::1. The session ID is 16 2131 (0x10) and the idle timeout is one minute. At most 10 resources may 2132 be concurrently active in the session and the flow rate should not 2133 exceed 10 kbits/s. The multicast transport is encrypted using the 2134 AEAD cipher suite 0x13,0x01 ("TLS_AES_128_GCM_SHA256") with the 2135 shared session key and IV provided. Content integrity is in use with 2136 the digest algorithm set restricted to SHA-256. Content authenticity 2137 is in use with the signature algorithm set restricted to rsa-sha256. 2139 HTTP Alternative Service header field: 2141 Alt-Svc: 2142 h3m="[ff3e::1234]:2000"; source-address="2001:db8::1"; 2143 session-id=10; session-idle-timeout=60; 2144 max-concurrent-resources=10; peak-flow-rate=10000; 2145 cipher-suite=1301; key=4adf1eab9c2a37fd; 2146 iv=4dbe593acb4d1577ad6ba7dc3189834e; 2147 digest-algorithm=SHA-256; signature-algorithm=rsa-sha256 2149 B.2. Resource Transfer 2151 This section shows several different examples of the HTTP message 2152 patterns for a single resource. 2154 Examples that show HTTP/3 "PUSH_PROMISE" or "HEADERS" frames describe 2155 the contents of enclosed header block fragments. 2157 B.2.1. Transfer without Content Integrity or Authenticity 2159 HTTP/3 "PUSH_PROMISE" frame: 2161 :method: GET 2162 :scheme: https 2163 :path: /files/example.txt 2164 :authority: example.org 2166 HTTP/3 "HEADERS" frame: 2168 :status: 200 2169 content-length: 100 2170 content-type: text/plain 2171 date: Fri, 20 Jan 2017 10:00:00 GMT 2173 HTTP/3 "DATA" frame containing 100 bytes of response body data: 2175 ... 2177 B.2.2. Transfer of Partial Content without Content Integrity or 2178 Authenticity 2180 In this example, partial content is transferred as described in 2181 Section 8. The "Range" request header is used to indicate the 2182 sender's original intention to transfer all 100 bytes of the 2183 representation. The "Content-Range" response header indicates that 2184 only the first 50 bytes were actually sent. 2186 HTTP/3 "PUSH_PROMISE" frame: 2188 :method: GET 2189 :scheme: https 2190 :path: /files/example.txt 2191 :authority: example.org 2192 range: bytes=0-* 2194 HTTP/3 "HEADERS" frame: 2196 :status: 206 2197 content-length: 100 2198 content-range: bytes 0-49/100 2199 content-type: text/plain 2200 date: Fri, 20 Jan 2017 10:00:00 GMT 2202 HTTP/3 "DATA" frame containing 50 bytes of response body data: 2204 ... 2206 B.2.3. Transfer with Content Integrity and without Authenticity 2208 In this example, content integrity is assured by the inclusion of the 2209 "Digest" response header, as described in Section 6.1. 2211 HTTP/3 "PUSH_PROMISE" frame: 2213 :method: GET 2214 :scheme: https 2215 :path: /files/example.txt 2216 :authority: example.org 2218 HTTP/3 "HEADERS" frame including the "Digest" header: 2220 :status: 200 2221 content-length: 100 2222 content-type: text/plain 2223 date: Fri, 20 Jan 2017 10:00:00 GMT 2224 digest: SHA-256=DieQ9zfRaDdyAilTVCvmBePuxMm+B6cNocP+QCrNSqo= 2226 HTTP/3 "DATA" frame containing 100 bytes of response body data: 2228 ... 2230 B.2.4. Partial Transfer with Content Integrity and without Authenticity 2232 In this example, partial content is transferred as described in 2233 Section 8. The "Range" request header is used to indicate the 2234 sender's intention to transfer all 100 bytes of the representation. 2235 The "Content-Range" response header indicates that only the first 50 2236 bytes were actually sent. Content integrity is assured by the 2237 inclusion of the "Digest" response header, as described in 2238 Section 6.1. 2240 HTTP/3 "PUSH_PROMISE" frame: 2242 :method: GET 2243 :scheme: https 2244 :path: /files/example.txt 2245 :authority: example.org 2246 range: bytes=0-* 2248 HTTP/3 "HEADERS" frame including the "Digest" header: 2250 :status: 206 2251 content-length: 100 2252 content-range: bytes 0-49/100 2253 content-type: text/plain 2254 date: Fri, 20 Jan 2017 10:00:00 GMT 2255 digest: SHA-256=DieQ9zfRaDdyAilTVCvmBePuxMm+B6cNocP+QCrNSqo= 2257 HTTP/3 "DATA" frame containing 50 bytes of response body data: 2259 ... 2261 B.2.5. Transfer with Content Integrity and Authenticity 2263 In this example, content integrity is assured by the inclusion of the 2264 "Digest" response header, as described in Section 6.1. Content 2265 authenticity is assured separately for the request and the response 2266 messages by the "Signature" header which protects the header fields 2267 described in further detail below. The "Signature" header parameter 2268 "keyId" contains the URL of a file containing the public key related 2269 to the multicast sender's private key used to create the digital 2270 signature. 2272 HTTP/3 "PUSH_PROMISE" frame including a "Signature" header protecting 2273 the ":method" and ":path" (the request target), as well as the 2274 ":scheme" and ":authority" of the pseudo-request: 2276 :method: GET 2277 :scheme: https 2278 :path: /files/example.txt 2279 :authority: example.org 2280 signature: keyId="https://example.org/mcast-sender.example.org.pem", 2281 algorithm=rsa-sha256, 2282 headers="(request-target) :scheme :authority", 2283 signature="MGQCMFTaFptaM2FhgzJq2i9AaChuFDHjp6GiXVtRnI8BsA" 2285 HTTP/3 "HEADERS" frame including a "Signature" header protecting the 2286 ":method", ":path", ":scheme" and ":authority" of the pseudo-request 2287 above, plus the "Date" and "Digest" of the response: 2289 :status: 200 2290 content-length: 100 2291 content-type: text/plain 2292 date: Fri, 20 Jan 2017 10:00:00 GMT 2293 digest: SHA-256=DieQ9zfRaDdyAilTVCvmBePuxMm+B6cNocP+QCrNSqo= 2294 signature: keyId="https://example.org/mcast-sender.example.org.pem", 2295 algorithm=rsa-sha256, 2296 headers="(request-target) :scheme :authority date digest", 2297 signature="MGUCMBgx6cuwTzg0W29zNUra8xfMsEcb3rFA3Y" 2299 HTTP/3 "DATA" frame containing response body data: 2301 ... 2303 B.2.6. Partial Transfer with Content Integrity and Authenticity 2305 In this example, partial content is transferred and the "Range" 2306 header (as described in Section 8) is used to indicate that 50 bytes 2307 out of 100 bytes were transferred. Content integrity is provided by 2308 the inclusion of the "Digest" header, as described in Section 6.1. 2309 Authenticity is provided by the "Signature" header which protects the 2310 header fields described in further detail. The "Signature" header 2311 parameter "keyId" contains the URL of a file containing the public 2312 key related to the multicast sender's private key used to create the 2313 digital signature. 2315 HTTP/3 "PUSH_PROMISE" frame: 2317 :method: GET 2318 :scheme: https 2319 :path: /files/example.txt 2320 :authority: example.org 2321 range: bytes=0-* 2322 signature: keyId="https://example.org/mcast-sender.example.org.pem", 2323 algorithm=rsa-sha256, 2324 headers="(request-target) :scheme :authority range", 2325 signature="MGQCMFTaFptaM2FhgzJq2i9AaChuFDHjp6GiXVtRnI8BsA" 2327 HTTP/3 "HEADERS" frame protecting the ":method", ":path", ":scheme" 2328 and ":authority" of the pseudo-request above, plus the "Date", 2329 "Digest" and "Content-Range" of the response: 2331 :status: 206 2332 content-length: 100 2333 content-range: bytes 0-49/100 2334 content-type: text/plain 2335 date: Fri, 20 Jan 2017 10:00:00 GMT 2336 digest: SHA-256=DieQ9zfRaDdyAilTVCvmBePuxMm+B6cNocP+QCrNSqo= 2337 signature: keyId="https://example.org/mcast-sender.example.org.pem", 2338 algorithm=rsa-sha256, 2339 headers="(request-target) :scheme :authority 2340 date digest content-range", 2341 signature="MGUCMBgx6cuwTzg0W29zNUra8xfMsEcb3rFA3Y" 2343 HTTP/3 "DATA" frame containing response body data: 2345 ... 2347 Appendix C. Summary of differences from unicast QUIC and HTTP/3 2348 +----------------+-----------------------+--------------------------+ 2349 | Protocol | Unicast QUIC | Multicast QUIC profile | 2350 | feature | | | 2351 +----------------+-----------------------+--------------------------+ 2352 | Packet number | QUIC transport | All packets are numbered | 2353 | spaces | packets are seperated | in the application data | 2354 | | into three distinct | packet number space. | 2355 | | packet number spaces: | | 2356 | | initial, handshake | | 2357 | | and application data. | | 2358 | | | | 2359 | Transport | Combined | Not used. | 2360 | handshake | cryptographic and | | 2361 | | transport handshake | | 2362 | | stream conveying TLS | | 2363 | | handshake messages in | | 2364 | | QUIC Initial and | | 2365 | | Handshake packets. | | 2366 | | | | 2367 | TLS cipher | Client's preferred | Cipher suite optionally | 2368 | suite | cipher suite included | advertised out of band | 2369 | | in Client Hello | via Alt-Svc "cipher- | 2370 | | message. | suite" parameter. | 2371 | | | Default cipher suite is | 2372 | | | "0x00,0x00 | 2373 | | | (NULL_WITH_NULL_NULL)". | 2374 | | | | 2375 | TLS session | Session key included | Session key optionally | 2376 | key | in Server Hello | advertised out of band | 2377 | | message. | via Alt-Svc "key" | 2378 | | | parameter. | 2379 | | | | 2380 | TLS | Initialization vector | Initialization vector | 2381 | initialization | included in Server | optionally advertised | 2382 | vector | Hello message. | out of band via Alt-Svc | 2383 | | | "iv" parameter. | 2384 +----------------+-----------------------+--------------------------+ 2386 Table 1: Cryptography and Transport 2388 +----------------------------+----------------+---------------------+ 2389 | Protocol feature | Unicast QUIC | Multicast QUIC | 2390 | | | profile | 2391 +----------------------------+----------------+---------------------+ 2392 | "initial_max_data" | Connection- | Not used. Peak flow | 2393 | | level flow | rate of a session | 2394 | | control window | optionally | 2395 | | size. | advertised out of | 2396 | | | band via Alt-Svc | 2397 | | | "peak-flow-rate" | 2398 | | | parameter. | 2399 | | | | 2400 | "initial_max_stream_data_b | Locally- | Not used. No | 2401 | idi_local" | initiated | bidirectional | 2402 | | bidirectional | streams in this | 2403 | | stream flow | profile. | 2404 | | control window | | 2405 | | size. | | 2406 | | | | 2407 | "initial_max_stream_data_b | Remotely- | Not used. No | 2408 | idi_remote" | initiated | bidirectional | 2409 | | bidirectional | streams in this | 2410 | | stream flow | profile. | 2411 | | control window | | 2412 | | size. | | 2413 | | | | 2414 | "initial_max_stream_data_u | Unidirectional | Not used. Peak flow | 2415 | ni" | stream flow | rate of a session | 2416 | | control window | optionally | 2417 | | size. | advertised out of | 2418 | | | band via Alt-Svc | 2419 | | | "peak-flow-rate | 2420 | | | parameter". | 2421 | | | | 2422 | "initial_max_streams_bidi" | Maximum stream | Not used. Maximum | 2423 | and | concurrency. | concurrent | 2424 | "initial_max_streams_uni" | | resources in a | 2425 | | | session optionally | 2426 | | | advertised out of | 2427 | | | band via Alt-Svc | 2428 | | | "max-concurrent- | 2429 | | | resources" | 2430 | | | parameter. | 2431 +----------------------------+----------------+---------------------+ 2433 Table 2: Required Transport Parameters 2435 +-------------------------+------------------+----------------------+ 2436 | Protocol feature | Unicast QUIC | Multicast QUIC | 2437 | | | profile | 2438 +-------------------------+------------------+----------------------+ 2439 | "original_connection_id | The value of the | Not used. No client | 2440 | " | Destination | interaction. | 2441 | | Connection ID | | 2442 | | field from the | | 2443 | | first Initial | | 2444 | | packet sent by | | 2445 | | the client. | | 2446 | | | | 2447 | "max_idle_timeout" | How long to keep | Not used. Advertised | 2448 | | an idle | out of band via Alt- | 2449 | | connection open | Svc "session-idle- | 2450 | | for before | timeout" parameter; | 2451 | | closing. Takes a | defaults to 0 (never | 2452 | | default of 0 | close on idle) if | 2453 | | (never close on | not specified. | 2454 | | idle) if not | | 2455 | | specified. | | 2456 | | | | 2457 | "stateless_reset_token" | Used in | Not used. Stateless | 2458 | | verifying a | reset is not used by | 2459 | | stateless reset. | this profile. | 2460 | | | | 2461 | "max_packet_size" | Limit of the | Not used. Maximum | 2462 | | size of packets | packet size for a | 2463 | | that an endpoint | session optionally | 2464 | | is willing to | advertised out of | 2465 | | receive. | band via Alt-Svc | 2466 | | | "max-packet-size" | 2467 | | | parameter. | 2468 | | | | 2469 | "ack_delay_exponent" | The exponent | Not used. "ACK" | 2470 | | used to decode | frames are | 2471 | | the ACK Delay | prohibited by this | 2472 | | field in the | profile. | 2473 | | "ACK" frame. | | 2474 | | | | 2475 | "max_ack_delay" | Maximum time in | Not used. "ACK" | 2476 | | milliseconds by | frames are | 2477 | | which an | prohibited by this | 2478 | | endpoint will | profile. | 2479 | | delay sending ac | | 2480 | | knowledgements. | | 2481 | | | | 2482 | "disable_active_migrati | Signals if an | Not used. Session | 2483 | on" | endpoint does | migration not | 2484 | | not support | currently supported | 2485 | | connection | by this profile. | 2486 | | migration. | | 2487 | | | | 2488 | "preferred_address" | Used to effect a | Not used. No | 2489 | | change in server | handshake in this | 2490 | | address at the | profile. | 2491 | | end of the | | 2492 | | handshake. | | 2493 +-------------------------+------------------+----------------------+ 2495 Table 3: Optional Transport Parameters 2497 +-------------+---------------------+-------------------------------+ 2498 | Protocol | Unicast QUIC | Multicast QUIC profile | 2499 | feature | | | 2500 +-------------+---------------------+-------------------------------+ 2501 | Maximum | Determined by path | Determined by path MTU | 2502 | packet size | MTU discovery or | discovery or other heuristic. | 2503 | | other heuristic. | | 2504 | | | | 2505 | Long header | Used for packets | Prohibited. | 2506 | packet | that are sent prior | | 2507 | | to the completion | | 2508 | | of version | | 2509 | | negotiation and | | 2510 | | before packet | | 2511 | | protection keys are | | 2512 | | established. | | 2513 | | | | 2514 | Version | Protocol version | Not permitted. | 2515 | negotiation | negotiation between | | 2516 | packet | initiating client | | 2517 | | and server. | | 2518 | | | | 2519 | Stateless | Used by a peer to | Not permitted. (Potential | 2520 | reset | terminate a | denial-of-service attack | 2521 | packet | connection that has | vector.) | 2522 | | become unusable. | | 2523 | | | | 2524 | Short | Used for packets | Used to convey QUIC frames | 2525 | header | that are sent once | (see below). | 2526 | packet | a connection has | | 2527 | | been established. | | 2528 | | Used to convey QUIC | | 2529 | | frames (see below). | | 2530 | | | | 2531 | Source | Connection IDs | Source Connection ID not | 2532 | Connection | negotiated between | used. Destination Connection | 2533 | ID field, | client and server | ID redefined to be a | 2534 | Destination | during handshake | Multicast Session ID which is | 2535 | Connection | and may be changed | optionally advertised out of | 2536 | ID field | subsequently using | band via the Alt-Svc | 2537 | | the | "session-id" parameter. May | 2538 | | "NEW_CONNECTION_ID" | be omitted from packets if | 2539 | | frame. | the address/port tuple is | 2540 | | | sufficient to identify the | 2541 | | | session, in which case it is | 2542 | | | not advertised. | 2543 +-------------+---------------------+-------------------------------+ 2545 Table 4: QUIC Packet Layer 2547 +------------------------+----------------------+---------------------+ 2548 | Protocol feature | Unicast QUIC | Multicast QUIC | 2549 | | | profile | 2550 +------------------------+----------------------+---------------------+ 2551 | "PADDING" frame | Used to pad out a | Permitted, but | 2552 | | QUIC packet with | wasteful of network | 2553 | | zero bytes. (The | capacity. | 2554 | | first packet sent on | | 2555 | | a connection must be | | 2556 | | at least 1200 bytes | | 2557 | | long to prove that | | 2558 | | the network can | | 2559 | | transmit packets of | | 2560 | | at least this size.) | | 2561 | | | | 2562 | "PING" frame | Used by an endpoint | Used by the | 2563 | | to verify that its | multicast sender as | 2564 | | peer is still alive. | a session keep- | 2565 | | Acknowledged using a | alive notification. | 2566 | | regular "ACK" frame. | Never acknowledged. | 2567 | | | | 2568 | "ACK" frame | Used by a receiver | Both "ACK" frame | 2569 | | to acknowledge | types are | 2570 | | receipt of data from | prohibited. | 2571 | | its peer. | | 2572 | | | | 2573 | "RESET_STREAM" frame | Request by receiver | Indication to | 2574 | | for sender to | receivers that the | 2575 | | terminate a stream | multicast sender | 2576 | | transmission | has prematurely | 2577 | | prematurely. | terminated a stream | 2578 | | | transmission. | 2579 | | | Prohibited for | 2580 | | | receivers to send. | 2581 | | | | 2582 | "STOP_SENDING" frame | Flow control back | Prohibited. | 2583 | | pressure. Used to | | 2584 | | signal to a peer | | 2585 | | that incoming data | | 2586 | | on a stream is being | | 2587 | | discarded on receipt | | 2588 | | at the application's | | 2589 | | request. This | | 2590 | | abruptly terminates | | 2591 | | a stream. | | 2592 | | | | 2593 | "CRYPTO" frame | Used to transmit | Prohibited. | 2594 | | cryptographic | | 2595 | | handshake messages. | | 2596 | | | | 2597 | "NEW_TOKEN" frame | Used by a server to | Prohibited. Session | 2598 | | supply a token to | migration not | 2599 | | its client to be | currently supported | 2600 | | sent in the header | by this profile. | 2601 | | of an initial packet | | 2602 | | for a future | | 2603 | | connection. Used to | | 2604 | | facilitate | | 2605 | | connection | | 2606 | | migration. | | 2607 | | | | 2608 | "STREAM" frame | Conveys application- | Conveys | 2609 | | layer payloads (see | application-layer | 2610 | | HTTP/3 mapping | payloads (see | 2611 | | below). | HTTP/3 mapping | 2612 | | | below). | 2613 | | | | 2614 | "FIN" bit on "STREAM" | Indication by sender | Indication by the | 2615 | frame | to its peer that a | multicast sender | 2616 | | stream transmission | that a stream | 2617 | | has finished. | transmission has | 2618 | | | finished. | 2619 | | | | 2620 | "MAX_DATA" frame | Flow control update | Prohibited. | 2621 | | notification. | | 2622 | | | | 2623 | "MAX_STREAM_DATA" | Flow control update | Prohibited. | 2624 | frame | notification. | | 2625 | | | | 2626 | "MAX_STREAMS" frame | Used by an endpoint | Prohibited. | 2627 | | to inform a peer of | | 2628 | | the maximum stream | | 2629 | | ID that it is | | 2630 | | permitted to open. | | 2631 | | | | 2632 | "DATA_BLOCKED" frame | Notification to | Prohibited. | 2633 | | receiver that | | 2634 | | sender's | | 2635 | | transmission is | | 2636 | | blocked pending an | | 2637 | | update to its flow | | 2638 | | control window by | | 2639 | | peer. | | 2640 | | | | 2641 | "STREAM_DATA_BLOCKED" | Notification to | Prohibited. | 2642 | frame | receiver that | | 2643 | | sender's | | 2644 | | transmission of a | | 2645 | | single stream is | | 2646 | | blocked pending an | | 2647 | | update to its flow | | 2648 | | control window by | | 2649 | | peer. | | 2650 | | | | 2651 | "STREAMS_BLOCKED" | Notification to | Prohibited. | 2652 | frames | receiver that the | | 2653 | | sender wishes to | | 2654 | | open a stream but is | | 2655 | | unable to do so | | 2656 | | because the maximum | | 2657 | | stream ID has been | | 2658 | | reached for a given | | 2659 | | stream type. | | 2660 | | | | 2661 | "NEW_CONNECTION_ID" | Used to provide a | Prohibited. Session | 2662 | frame | peer with | migration not | 2663 | | alternative | currently supported | 2664 | | connection IDs that | by this profile. | 2665 | | can be used to break | | 2666 | | linkability when | | 2667 | | migrating | | 2668 | | connections. | | 2669 | | | | 2670 | "RETIRE_CONNECTION_ID" | Indicates that an | Prohibited. Session | 2671 | frame | endpoint will no | migration not | 2672 | | longer use a | currently supported | 2673 | | connection ID that | by this profile. | 2674 | | was issued by its | | 2675 | | peer. | | 2676 | | | | 2677 | "PATH_CHALLENGE" frame | Used to check | Prohibited. | 2678 | | reachability to a | | 2679 | | peer and for path | | 2680 | | validation during | | 2681 | | connection | | 2682 | | migration. | | 2683 | | | | 2684 | "PATH_RESPONSE" frame | Sent in response to | Prohibited. | 2685 | | a "PATH_CHALLENGE" | | 2686 | | frame. | | 2687 | | | | 2688 | "CONNECTION_CLOSE" | Notification (by | Prohibited. Use | 2689 | frame | either peer) of | HTTP explicit | 2690 | | graceful connection | session tear-down | 2691 | | shutdown. | instead (see | 2692 | | | Section 5.4). | 2693 | | | | 2694 | "HANDSHAKE_DONE" frame | Used by a server to | Prohibited. | 2695 | | inform a client that | | 2696 | | the cryptographic | | 2697 | | handshake has | | 2698 | | completed. | | 2699 +------------------------+----------------------+---------------------+ 2701 Table 5: QUIC Framing Layer 2703 +------------------+------------------+-----------------------------+ 2704 | Protocol feature | Unicast HTTP/3 | Multicast HTTP/3 profile | 2705 +------------------+------------------+-----------------------------+ 2706 | Stream Type | Type of | Only Server Push type is | 2707 | | unidirectional | permitted. | 2708 | | stream. | | 2709 | | | | 2710 | Push ID | Identifies a | Identifies a promised | 2711 | | promised | resource conveyed in an | 2712 | | resource | earlier "PUSH_PROMISE" | 2713 | | conveyed in an | frame. | 2714 | | earlier | | 2715 | | "PUSH_PROMISE" | | 2716 | | frame. | | 2717 | | | | 2718 | "DATA" frame | Carriage of HTTP | Carriage of HTTP response | 2719 | | request/response | message body. | 2720 | | message body. | | 2721 | | | | 2722 | "HEADERS" frame | Carriage of HTTP | Carriage of HTTP response | 2723 | | request/response | message metadata. Trailing | 2724 | | message | "HEADERS" frame is | 2725 | | metadata. | permitted. | 2726 | | Trailing | | 2727 | | "HEADERS" frame | | 2728 | | is permitted. | | 2729 | | | | 2730 | "CANCEL_PUSH" | Used to request | Permitted only for senders. | 2731 | frame | cancellation of | | 2732 | | server push | | 2733 | | prior to the | | 2734 | | push stream | | 2735 | | being created. | | 2736 | | | | 2737 | "SETTINGS" frame | Negotiation of | Prohibited. | 2738 | | HTTP/3 | | 2739 | | connection | | 2740 | | settings. | | 2741 | | | | 2742 | "PUSH_PROMISE" | Carriage of HTTP | Carriage of HTTP pseudo- | 2743 | frame | pseudo-request | request message metadata. | 2744 | | message | All HTTP representation | 2745 | | metadata. | transfers over multicast | 2746 | | | begin this way. Stream ID | 2747 | | | of the first client- | 2748 | | | initiated bidirectional | 2749 | | | stream is reserved and all | 2750 | | | "PUSH_PROMISE" frames | 2751 | | | reference this as the | 2752 | | | client request from which | 2753 | | | they are notionally | 2754 | | | derived. This stream | 2755 | | | remains open while a sender | 2756 | | | is participating in the | 2757 | | | multicast QUIC session. | 2758 | | | | 2759 | "GOAWAY" frame | Early | Prohibited. Use HTTP | 2760 | | notification (by | explicit session tear-down | 2761 | | either endpoint) | instead. | 2762 | | of future | | 2763 | | connection | | 2764 | | closure, | | 2765 | | allowing for | | 2766 | | orderly | | 2767 | | completion of | | 2768 | | open streams. | | 2769 | | | | 2770 | "MAX_PUSH_ID" | Used by a | Prohibited. | 2771 | frame | receiver to | | 2772 | | control the | | 2773 | | number of server | | 2774 | | pushes that a | | 2775 | | sender can | | 2776 | | initiate. | | 2777 | | | | 2778 | "DUPLICATE_PUSH" | Used by servers | Prohibited. | 2779 | frame | to indicate that | | 2780 | | an existing | | 2781 | | pushed resource | | 2782 | | is related to | | 2783 | | multiple client | | 2784 | | requests. | | 2785 | | | | 2786 | "ALTSVC" HTTP/2 | Signalling | Prohibited. | 2787 | extension frame | alternative | | 2788 | | service for | | 2789 | | HTTP/3 session. | | 2790 | | | | 2791 | Other HTTP/2 | | Prohibited. | 2792 | extension frames | | | 2793 +------------------+------------------+-----------------------------+ 2795 Table 6: HTTP/3 Mapping 2797 +-------------+----------------------------------+------------------+ 2798 | Protocol | Unicast HTTP/3 | Multicast HTTP/3 | 2799 | feature | | profile | 2800 +-------------+----------------------------------+------------------+ 2801 | Huffman | Header blocks may use Huffman | Header blocks | 2802 | string | codes to compress literal string | may use Huffman | 2803 | compression | values. | codes to | 2804 | | | compress literal | 2805 | | | string values. | 2806 | | | | 2807 | Static | Header blocks may refer to | Header blocks | 2808 | table | indexed entries in the static | may refer to | 2809 | | table. | indexed entries | 2810 | | | in the static | 2811 | | | table. | 2812 | | | | 2813 | Dynamic | Header blocks may insert entries | Prohibited, size | 2814 | table | into the dynamic table and | is currently | 2815 | | subsequent header blocks may | locked to 0. | 2816 | | refer to their indexes. Unused | | 2817 | | as size is currently locked to | | 2818 | | 0. | | 2819 +-------------+----------------------------------+------------------+ 2821 Table 7: HTTP Metadata Compression Layer 2823 Appendix D. Changelog 2825 *RFC Editor's Note:* Please remove this section prior to 2826 publication of a final version of this document. 2828 D.1. Since draft-pardue-quic-http-mcast-05 2830 o Update references to QUIC I-Ds. 2832 o Sender packet number size is now fixed for the duration of a 2833 session. 2835 o Change how to handle multiple session IDs: sessions are now only 2836 allowed a single ID. 2838 o Remove incompatible requirements set by [QUIC-TRANSPORT]'s 2839 "Required Operations". 2841 o Additionally ban "HANDSHAKE_DONE". 2843 o Remove Version Negotiation now that the "quic" Alt-Svc parameter 2844 has been removed (examples also updated). 2846 o Remove HTTP Prioritization references. 2848 o Add new "extensions" Alt-Svc parameter. 2850 o Broaden peak flow rate to QUIC payload to encompass all frame 2851 types. 2853 o Change ALPN identifier to h3m. 2855 D.2. Since draft-pardue-quic-http-mcast-04 2857 o Update references to QUIC I-Ds, remove QUIC-SPIN. (draft-ietf- 2858 quic-transport-20) 2860 o Update session ID length to match new connection ID length. 2861 (draft-ietf-quic-transport-22) 2863 o Clarify the mapping for the new "active_connection_id_limit" 2864 session parameter. (draft-ietf-quic-transport-21) 2866 o Update text to conform with latest version negotiation text from 2867 [QUIC-TRANSPORT]. 2869 o Update stream types for server push in accordance with draft-ietf- 2870 quic-http-19. 2872 o Fix some idnits warnings to do with line lengths in Alt-Svc 2873 examples. 2875 o Update IPv6 informative reference to RFC 8200 as it obsoletes RFC 2876 2460. 2878 o Clarify difference between connection and session migration. 2880 o Move GOAWAY frame to HTTP/3 profile. 2882 o Renamed Session Shutdown to Connection Shutdown to mirror concept 2883 in [QUIC-TRANSPORT]. 2885 o Clarify the layer of each frame type when referred to. 2887 D.3. Since draft-pardue-quic-http-mcast-03 2889 o Update references to QUIC I-Ds. 2891 o Change crypto handshake text now that it's no longer done on 2892 Stream ID 0. 2894 o Update to reference Source and Destination Connection IDs. 2896 o Prohibit the use of connection coalescing, migration and ECN. 2898 o Update allowed and disallowed packets and frames to match the core 2899 specs. 2901 o Remove references to the PONG frame. (draft-ietf-quic-transport- 2902 10) 2904 o Change HTTP/QUIC to HTTP/3. (draft-ietf-quic-http-17) 2906 o Change HPACK to QPACK. (draft-ietf-quic-http-10) 2908 o Prohibit the DUPLICATE_PUSH frame. 2910 o Clarify packet number space (only use application data space, not 2911 initial or handshake). 2913 o Add statement on QUIC latency spin bit. 2915 o Removed sentence stating that multiple Connection IDs cannot be 2916 used concurrently in a unicast QUIC session, in accordance with 2917 [QUIC-TRANSPORT] section 5.1.2. 2919 D.4. Since draft-pardue-quic-http-mcast-02 2921 o No changes. 2923 D.5. Since draft-pardue-quic-http-mcast-01 2925 o Explicit guidance on maximum stream ID value permitted. 2927 o Updated guidance on PING (and PONG) frame. 2929 o Added a comparison table to appendix. 2931 o Remove invalid use of trailing headers. 2933 o Use the new HTTP/QUIC DATA frame. 2935 o Prohibit APPLICATION CLOSE frame, and move GOAWAY frame to HTTP/ 2936 QUIC section. 2938 o Redefine server push to reflect core document changes. 2940 o Remove default idle time out value. 2942 o Clarify session parameter requirements (session-idle-timeout 2943 became mandatory). 2945 o Update frame notation convention. 2947 D.6. Since draft-pardue-quic-http-mcast-00 2949 o Update references to QUIC I-Ds. 2951 o Relax session leaving requirements language. 2953 o Clarify handling of omitted session parameter advertisements. 2955 o Rename "Idle" state to "Quiescent". 2957 o Add digest algorithm session parameter. 2959 o Add signature algorithm session parameter. 2961 o Add Initialization Vector session parameter. 2963 o Replace COPT tag-value-pairs with TransportParameter values. 2965 o Add example of an advertisement for a session with content 2966 authenticity and integrity. 2968 Authors' Addresses 2970 Lucas Pardue 2972 Email: lucaspardue.24.7@gmail.com 2974 Richard Bradbury 2975 BBC Research & Development 2977 Email: richard.bradbury@bbc.co.uk 2979 Sam Hurst 2980 BBC Research & Development 2982 Email: sam.hurst@bbc.co.uk