idnits 2.17.1 draft-pardue-quic-http-mcast-05.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 (August 8, 2019) is 1721 days in the past. Is this intentional? Checking references for intended status: Informational ---------------------------------------------------------------------------- == Outdated reference: A later version (-12) exists of draft-cavage-http-signatures-11 == Outdated reference: A later version (-34) exists of draft-ietf-quic-http-22 == Outdated reference: A later version (-21) exists of draft-ietf-quic-qpack-09 == Outdated reference: A later version (-34) exists of draft-ietf-quic-transport-22 ** 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-22 == 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 (~~), 9 warnings (==), 2 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Network Working Group L. Pardue 3 Internet-Draft 4 Intended status: Informational R. Bradbury 5 Expires: February 9, 2020 S. Hurst 6 BBC Research & Development 7 August 8, 2019 9 Hypertext Transfer Protocol (HTTP) over multicast QUIC 10 draft-pardue-quic-http-mcast-05 12 Abstract 14 This document specifies a profile of the QUIC protocol and the HTTP/3 15 mapping that facilitates the transfer of HTTP resources over 16 multicast IP using the QUIC transport as its framing and 17 packetisation layer. Compatibility with the QUIC protocol's syntax 18 and semantics is maintained as far as practical and additional 19 features are specified where this is not possible. 21 Status of This Memo 23 This Internet-Draft is submitted in full conformance with the 24 provisions of BCP 78 and BCP 79. 26 Internet-Drafts are working documents of the Internet Engineering 27 Task Force (IETF). Note that other groups may also distribute 28 working documents as Internet-Drafts. The list of current Internet- 29 Drafts is at https://datatracker.ietf.org/drafts/current/. 31 Internet-Drafts are draft documents valid for a maximum of six months 32 and may be updated, replaced, or obsoleted by other documents at any 33 time. It is inappropriate to use Internet-Drafts as reference 34 material or to cite them other than as "work in progress." 36 This Internet-Draft will expire on February 9, 2020. 38 Copyright Notice 40 Copyright (c) 2019 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. Version Advertisement . . . . . . . . . . . . . . . . . . 12 68 3.2. Security Context . . . . . . . . . . . . . . . . . . . . 13 69 3.2.1. Cipher Suite . . . . . . . . . . . . . . . . . . . . 13 70 3.2.2. Key Exchange . . . . . . . . . . . . . . . . . . . . 13 71 3.2.3. Initialization Vector . . . . . . . . . . . . . . . . 13 72 3.3. Session Identification . . . . . . . . . . . . . . . . . 14 73 3.4. Session Idle Timeout . . . . . . . . . . . . . . . . . . 14 74 3.5. Session Peak Flow Rate . . . . . . . . . . . . . . . . . 15 75 3.6. Resource Concurrency . . . . . . . . . . . . . . . . . . 15 76 3.7. Additional TransportParameter Considerations . . . . . . 16 77 3.8. Digest Algorithm . . . . . . . . . . . . . . . . . . . . 16 78 3.9. Signature Algorithm . . . . . . . . . . . . . . . . . . . 17 79 4. QUIC Profile . . . . . . . . . . . . . . . . . . . . . . . . 18 80 4.1. Packet Size . . . . . . . . . . . . . . . . . . . . . . . 18 81 4.2. Packet Format . . . . . . . . . . . . . . . . . . . . . . 18 82 4.2.1. Packet Numbers . . . . . . . . . . . . . . . . . . . 18 83 4.2.2. Spin Bit . . . . . . . . . . . . . . . . . . . . . . 19 84 4.3. Connection Identifier . . . . . . . . . . . . . . . . . . 19 85 4.4. Stream Identifier . . . . . . . . . . . . . . . . . . . . 19 86 4.5. Flow Control . . . . . . . . . . . . . . . . . . . . . . 19 87 4.6. Stream Termination . . . . . . . . . . . . . . . . . . . 20 88 4.7. Connection Shutdown . . . . . . . . . . . . . . . . . . . 20 89 4.8. Connection Migration . . . . . . . . . . . . . . . . . . 20 90 4.9. Explicit Congestion Notification . . . . . . . . . . . . 21 91 4.10. Session Keep-alive . . . . . . . . . . . . . . . . . . . 21 92 4.11. Loss Detection and Recovery . . . . . . . . . . . . . . . 21 93 4.12. Prohibited QUIC Frames and Packets . . . . . . . . . . . 22 94 5. HTTP/3 Profile . . . . . . . . . . . . . . . . . . . . . . . 22 95 5.1. HTTP Connection Settings . . . . . . . . . . . . . . . . 22 96 5.2. Server Push . . . . . . . . . . . . . . . . . . . . . . . 23 97 5.3. Metadata Compression . . . . . . . . . . . . . . . . . . 23 98 5.4. Prioritisation . . . . . . . . . . . . . . . . . . . . . 24 99 5.5. Session Tear-down . . . . . . . . . . . . . . . . . . . . 24 100 5.6. HTTP/3 Extension frames . . . . . . . . . . . . . . . . . 24 101 5.7. Prohibited HTTP/3 Frames . . . . . . . . . . . . . . . . 24 102 6. Application-Layer Security . . . . . . . . . . . . . . . . . 25 103 6.1. Content Integrity . . . . . . . . . . . . . . . . . . . . 25 104 6.2. Content Authenticity . . . . . . . . . . . . . . . . . . 25 105 6.3. Content Confidentiality . . . . . . . . . . . . . . . . . 27 106 7. Loss Recovery . . . . . . . . . . . . . . . . . . . . . . . . 27 107 7.1. Forward Error Correction . . . . . . . . . . . . . . . . 27 108 7.2. Unicast Repair . . . . . . . . . . . . . . . . . . . . . 27 109 8. Transmission of Partial Content . . . . . . . . . . . . . . . 28 110 9. Protocol Identifier . . . . . . . . . . . . . . . . . . . . . 28 111 9.1. Draft Version Identification . . . . . . . . . . . . . . 28 112 10. Discovery of Multicast QUIC Sessions . . . . . . . . . . . . 29 113 10.1. Source-specific Multicast Advertisement . . . . . . . . 30 114 10.2. Session Parameter Advertisement . . . . . . . . . . . . 30 115 10.2.1. Version . . . . . . . . . . . . . . . . . . . . . . 30 116 10.2.2. Cipher Suite . . . . . . . . . . . . . . . . . . . . 30 117 10.2.3. Session Key . . . . . . . . . . . . . . . . . . . . 31 118 10.2.4. Session Cipher Initialization Vector . . . . . . . . 31 119 10.2.5. Session Identification . . . . . . . . . . . . . . . 31 120 10.2.6. Session Idle Timeout Period . . . . . . . . . . . . 32 121 10.2.7. Resource Concurrency . . . . . . . . . . . . . . . . 32 122 10.2.8. Session Peak Flow Rate . . . . . . . . . . . . . . . 33 123 10.2.9. Digest Algorithm . . . . . . . . . . . . . . . . . . 33 124 10.2.10. Signature Algorithm . . . . . . . . . . . . . . . . 33 125 11. Security and Privacy Considerations . . . . . . . . . . . . . 34 126 11.1. Pervasive Monitoring . . . . . . . . . . . . . . . . . . 34 127 11.1.1. Large-scale Data Gathering and Correlation . . . . . 35 128 11.1.2. Changing Content . . . . . . . . . . . . . . . . . . 35 129 11.2. Protection of Discovery Mechanism . . . . . . . . . . . 35 130 11.3. Spoofing . . . . . . . . . . . . . . . . . . . . . . . . 36 131 11.3.1. Spoofed Ack Attacks . . . . . . . . . . . . . . . . 36 132 11.3.2. Sender Spoofing . . . . . . . . . . . . . . . . . . 36 133 11.3.3. Receiver Spoofing . . . . . . . . . . . . . . . . . 36 134 11.4. Replay Attacks . . . . . . . . . . . . . . . . . . . . . 36 135 11.5. Message Deletion . . . . . . . . . . . . . . . . . . . . 37 136 11.6. Denial of Service . . . . . . . . . . . . . . . . . . . 37 137 11.6.1. Unprotected Frames and Packets . . . . . . . . . . . 37 138 11.6.2. Network Performance Degradation . . . . . . . . . . 37 139 11.6.3. Unicast Repair Stampeding Herd . . . . . . . . . . . 37 140 11.7. Receiver Resource Usage . . . . . . . . . . . . . . . . 38 141 11.8. Unicast Repair Information Leakage . . . . . . . . . . . 38 142 12. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 38 143 12.1. Registration of Protocol Identification String . . . . . 38 144 12.2. Registration of Alt-Svc parameters . . . . . . . . . . . 39 145 12.2.1. Source Address . . . . . . . . . . . . . . . . . . . 39 146 12.2.2. Cipher Suite . . . . . . . . . . . . . . . . . . . . 39 147 12.2.3. Key . . . . . . . . . . . . . . . . . . . . . . . . 39 148 12.2.4. Initialization Vector . . . . . . . . . . . . . . . 39 149 12.2.5. Session Identifier . . . . . . . . . . . . . . . . . 39 150 12.2.6. Session Idle Timeout . . . . . . . . . . . . . . . . 40 151 12.2.7. Maximum Concurrent Resources . . . . . . . . . . . . 40 152 12.2.8. Peak Flow Rate . . . . . . . . . . . . . . . . . . . 40 153 12.2.9. Digest Algorithm . . . . . . . . . . . . . . . . . . 40 154 12.2.10. Signature Algorithm . . . . . . . . . . . . . . . . 40 155 13. References . . . . . . . . . . . . . . . . . . . . . . . . . 40 156 13.1. Normative References . . . . . . . . . . . . . . . . . . 40 157 13.2. Informative References . . . . . . . . . . . . . . . . . 42 158 Appendix A. Acknowledgements . . . . . . . . . . . . . . . . . . 44 159 Appendix B. Examples . . . . . . . . . . . . . . . . . . . . . . 44 160 B.1. Session Advertisement . . . . . . . . . . . . . . . . . . 44 161 B.1.1. Source-specific Multicast QUIC Session . . . . . . . 44 162 B.1.2. Source-specific Multicast QUIC Session with Transport 163 Encryption using a Symmetric Key . . . . . . . . . . 45 164 B.1.3. Source-specific Multicast QUIC Session with Transport 165 Encryption, Content Integrity and Authenticity . . . 45 166 B.2. Resource Transfer . . . . . . . . . . . . . . . . . . . . 46 167 B.2.1. Transfer without Content Integrity or Authenticity . 46 168 B.2.2. Transfer of Partial Content without Content Integrity 169 or Authenticity . . . . . . . . . . . . . . . . . . . 46 170 B.2.3. Transfer with Content Integrity and without 171 Authenticity . . . . . . . . . . . . . . . . . . . . 47 172 B.2.4. Partial Transfer with Content Integrity and without 173 Authenticity . . . . . . . . . . . . . . . . . . . . 47 174 B.2.5. Transfer with Content Integrity and Authenticity . . 48 175 B.2.6. Partial Transfer with Content Integrity and 176 Authenticity . . . . . . . . . . . . . . . . . . . . 49 177 Appendix C. Summary of differences from unicast QUIC and HTTP/3 50 178 Appendix D. Changelog . . . . . . . . . . . . . . . . . . . . . 61 179 D.1. Since draft-pardue-quic-http-mcast-04 . . . . . . . . . . 61 180 D.2. Since draft-pardue-quic-http-mcast-03 . . . . . . . . . . 61 181 D.3. Since draft-pardue-quic-http-mcast-02 . . . . . . . . . . 62 182 D.4. Since draft-pardue-quic-http-mcast-01 . . . . . . . . . . 62 183 D.5. Since draft-pardue-quic-http-mcast-00 . . . . . . . . . . 63 184 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 63 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.5), implicit shutdown (i.e. idle timeout, Section 3.4) 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.5). 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.5) 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.2. 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. Version Advertisement 547 *Authors' Note:* Version negotiation (as described in WG 548 documents) is in flux. This section will track developments and 549 will be updated accordingly. 551 Conventional QUIC has a concept of version negotiation. To start a 552 session, a client selects a version number and sends a packet to 553 initiate the connection. On receipt, if the server identifies that 554 it does not support that version then it may begin version 555 negotiation. In a unidirectional multicast environment, there is no 556 reasonable way to negotiate in such a manner. [QUIC-HTTP] defines an 557 Alt-Svc "quic" parameter that can be advertised to clients for use as 558 a version negotiation hint. This specification uses "quic" as a 559 session parameter for a similar purpose. This mechanism replaces the 560 use of the Version field in the QUIC packet long header (see 561 Section 4.2). 563 The Alt-Svc "quic" parameter is mandatory. Session advertisements 564 MUST contain exactly one instance of it and it MUST NOT be repeated. 566 A multicast sender participating in a session MUST send QUIC packets 567 and frames in the format corresponding to the advertised version. If 568 the sender does not support the advertised version it MUST NOT send 569 any data. A receiver MUST NOT join a session where the "quic" 570 parameter is absent. A receiver SHOULD NOT join a session for which 571 it does not support the advertised version, in order to avoid wasting 572 processing resources. 574 3.2. Security Context 576 *Authors' Note:* Security handshake (as described in WG documents) 577 is in flux. This section will track developments and will be 578 updated accordingly. 580 This specification replaces the in-band security handshake. The 581 session parameters "cipher suite", "key" and "iv" (described below) 582 allow for the establishment of a security context. In order to 583 protect themselves, endpoints SHOULD NOT participate in sessions for 584 which they cannot establish reasonable confidence over the cipher 585 suite, key, or IV in use for that session. Endpoints SHOULD leave 586 any sessions which fail to successfully match anticipated security 587 characteristics. 589 3.2.1. Cipher Suite 591 Cipher suite negotiation is replaced with a "cipher suite" session 592 parameter, which is advertised as the Alt-Svc parameter "cipher- 593 suite" (Section 10.2.2). 595 The Alt-Svc "cipher-suite" parameter is OPTIONAL. If present, this 596 parameter MUST contain only one value that corresponds to an entry in 597 the TLS Cipher Suite Registry (see http://www.iana.org/assignments/ 598 tls-parameters/tls-parameters.xhtml#tls-parameters-4). Session 599 advertisments that omit this parameter imply that the session is 600 operating with cipher suite 0x00,0x00 (NULL_WITH_NULL_NULL). 602 3.2.2. Key Exchange 604 Key exchange is replaced with a "key" session parameter, which is 605 advertised as the Alt-Svc parameter "key" (Section 10.2.3). The 606 parameter carries a variable-length hex-encoded key for use with the 607 session cipher suite. 609 The Alt-Svc "key" parameter is OPTIONAL. Session advertisments that 610 omit this parameter imply that the key may be available via an out- 611 of-band method not described in this document. 613 3.2.3. Initialization Vector 615 Initialization Vector (IV) exchange is replaced with an "iv" session 616 parameter, which is advertised as the Alt-Svc parameter "iv" 617 (Section 10.2.4). The parameter carries a variable-length hex- 618 encoded IV for use with the session cipher suite and key. 620 The Alt-Svc "iv" parameter is OPTIONAL. Session advertisments that 621 omit this parameter imply that the IV may be available via an out-of- 622 band method not described in this document. 624 3.3. Session Identification 626 [QUIC-TRANSPORT] specifies how the QUIC connection identifiers are 627 used, in particular the independent selection of these identfiers by 628 each endpoint for its peer. In a unidirectional multicast 629 environment, there is no meaningful way for an endpoint to generate a 630 connection identifier for its peer to use. This document defines a 631 "session identifier" session parameter, which is advertised as the 632 Alt-Svc parameter "session-id" (Section 10.2.5). The requirements 633 for the usage of session identifiers have already been described in 634 Section 2.3. 636 The Alt-Svc "session-id" parameter is optional. Session 637 advertisements MAY contain zero or more instances. The parameter MAY 638 be repeated with different values, indicating that multiple sessions 639 are multiplexed in the same multicast group. 641 *Authors' Note:* We invite review comments on mandating a single 642 session identifier per advertised session, i.e. only one session 643 identifier per ASM {G} or SSM {S,G}. 645 3.4. Session Idle Timeout 647 Conventional QUIC connections may be implicitly terminated following 648 a period of idleness (lack of network activity). The optional QUIC 649 TransportParameter "idle_timeout" provides a means for endpoints to 650 specify the timeout period. This document defines a "session idle 651 timeout" session parameter, which is advertised as the Alt-Svc 652 parameter "session-idle-timeout" (Section 10.2.6). This session 653 parameter mimics the behaviour of "idle_timeout", providing a means 654 for multicast QUIC sessions to define their own idle timeout periods. 656 Session idle timeout may be prevented by keep-alive strategies 657 Section 4.10. 659 The Alt-Svc "session-idle-timeout" parameter is optional. Session 660 advertisements MAY contain zero or more instances of this parameter. 661 If it is repeated, the first occurrence MUST be used and subsequent 662 occurrences MUST be ignored. Session advertisements that omit the 663 "session-idle-timeout" parameter, or set it to zero never time out. 665 Receiving participants SHOULD leave multicast QUIC sessions when the 666 session idle timeout period has elapsed (Section 4.7). Leaving 667 participants MUST use the silent close method, in which no QUIC 668 "CONNECTION_CLOSE" frame is sent. 670 3.5. Session Peak Flow Rate 672 [QUIC-TRANSPORT] specifies a credit-based stream- and connection- 673 level flow control scheme which prevents a fast sender from 674 overwhelming a slow receiver at the stream level, as well as an 675 aggregate level of all streams. Window size connection parameters 676 are exchanged on connection establishment using the required QUIC 677 TransportParameters "initial_max_data", 678 "initial_max_stream_data_bidi_local", 679 "initial_max_stream_data_bidi_remote" and 680 "initial_max_stream_data_uni". In a unidirectional multicast 681 environment, such a scheme is infeasible. 683 This document defines a "peak flow rate" session parameter, expressed 684 in units of bits per second, which is advertised as the Alt-Svc 685 parameter "peak-flow-rate" (Section 10.2.8). This completely 686 replaces the transport parameters listed above, instead indicating 687 the maximum bit rate of QUIC "STREAM" frame payloads transmitted on 688 all multicast groups comprising the session. It applies at the 689 aggregate level, and is not specific to any single stream. 691 The Alt-Svc "peak-flow-rate" parameter is OPTIONAL. If the parameter 692 is repeated the first occurrence MUST be used and subsequent 693 occurrences MUST be ignored. Session advertisements that omit the 694 parameter imply that the flow rate is unlimited. 696 A multicast sender SHOULD NOT cause the advertised peak flow rate of 697 a session to be exceeded. A receiver MAY leave any session where the 698 advertised peak flow rate is exceeded. 700 3.6. Resource Concurrency 702 [QUIC-TRANSPORT] considers concurrency in terms of the number of 703 active incoming streams, which is varied by the receiving endpoint 704 adjusting the maximum Stream ID. The initial value of maximum Stream 705 ID is controlled by the relevant required QUIC TransportParameters 706 "initial_max_streams_bidi" and "initial_max_streams_uni". They are 707 increased during the lifetime of a QUIC connection by the QUIC 708 "MAX_STREAMS" frame. In a unidirectional multicast environment, 709 there is no way for a receiver to specify an initial limit nor to 710 increase it. Therefore in multicast QUIC, the maximum Stream ID 711 (initial and always) is 2^62. This mechanism is not used to manage 712 concurrency in multicast QUIC. 714 Due to the profiling of maximum Stream ID, there is no role for the 715 QUIC "STREAMS_BLOCKED" frame and it is prohibited. Participants MUST 716 NOT send this frame type. Reception of this frame type MUST be 717 handled as described in Section 4.12. 719 This document specifies a "maximum concurrent resources" session 720 parameter, which is advertised as the Alt-Svc parameter "max- 721 concurrent-resources" (Section 10.2.7). This parameter replaces 722 "initial_max_stream_id_bidi" and "initial_max_stream_id_uni". It 723 advertises the maximum number of concurrent active resources 724 generated by a sender in a given multicast QUIC session. 726 The Alt-Svc "max-concurrent-resources" parameter is OPTIONAL. If the 727 parameter is repeated the first occurrence MUST be used and 728 subsequent occurrences MUST be ignored. Session advertisements that 729 omit the parameter imply that the maximum concurrency is unlimited. 731 A multicast sender participating in a session MUST NOT cause the 732 advertised "max-concurrent-resources" to be exceeded. A receiver MAY 733 leave any session where the advertised limit is exceeded, in order to 734 protect itself from denial-of-service attacks. 736 3.7. Additional TransportParameter Considerations 738 *Authors' Note:* This section will consider TransportParameters 739 that have not already been addressed, as required. It will track 740 developments and issues that may arise. 742 3.8. Digest Algorithm 744 A method to provide content integrity is described in Section 6.1. 745 This specifies the means to convey a value computed by a particular 746 digest algorithm. The identity of the selected algorithm is also 747 indicated. Valid digest algorithms are collected in the IANA HTTP 748 Digest Algorithm Values registry (http://www.iana.org/assignments/ 749 http-dig-alg/http-dig-alg.xhtml#http-dig-alg-1). 751 This document specifies a "digest algorithm" session parameter, which 752 is advertised as the Alt-Svc parameter "digest-algorithm" 753 (Section 10.2.9). 755 *Authors' Note:* Section 6.1 contains an author's note on the 756 potential for content integrity to become mandatory. This section 757 will be updated in line with the outcome of that decision. 759 The Alt-Svc "digest-algorithm" parameter is OPTIONAL. Repetition of 760 the "digest algorithm" parameter in a single advertisement describes 761 an algorithm set that MAY be used across the session. Session 762 advertisements that omit the Alt-Svc parameter "digest-algorithm" 763 imply that either: 765 o the session does not use the content integrity mechanism, or 767 o the algorithm set is unrestricted, i.e. a sender may vary the 768 algorithm as it so chooses. This may lead to undesirable results 769 if receivers do not support a chosen algorithm. 771 Advertising the algorithm set for a session gives receivers the 772 opportunity to selectively join sessions where the algorithms are 773 known to be supported. This may help to mitigate latency issues in 774 the receiver resulting from joining a session only to discover some 775 of its parameters are not supported. 777 A multicast sender participating in a session MUST NOT use algorithms 778 outside the signalled digest algorithm set. A receiver MAY leave any 779 session where an algorithm outside the digest algorithm set is used. 781 3.9. Signature Algorithm 783 A method to provide content authenticity is described in Section 6.2. 784 This specifies the means to convey a value computed by a particular 785 signature algorithm. The identity of the selected algorithm is also 786 indicated. Valid signature algorithms are collected in the IANA 787 Signature Algorithms registry (http://www.iana.org/assignments/ 788 signature-algorithms). 790 This document specifies a "signature algorithm" session parameter, 791 which is advertised as the Alt-Svc parameter "signature-algorithm" 792 (Section 10.2.10). 794 *Authors' Note:* Section 6.2 contains an author's note on the 795 potential for content authenticity to become mandatory. This 796 section will be updated in line with the outcome of that decision. 798 The Alt-Svc "signature-algorithm" parameter is OPTIONAL. Repetition 799 of the "signature algorithm" parameter in a single advertisement 800 describes an algorithm set that MAY be used across the session. 801 Session advertisements that omit the Alt-Svc parameter "signature- 802 algorithm" imply that either: 804 o the session does not use the content authenticity mechanism, or 806 o the algorithm set is unrestricted i.e. a sender may vary the 807 algorithm as it so chooses. This may lead to undesirable results 808 if receivers do not support a chosen algorithm. 810 Advertising the algorithm set for a session gives receivers the 811 opportunity to selectively join sessions where the algorithms are 812 known to be supported. This may help to mitigate latency issues in 813 the receiver resulting from joining a session only to discover some 814 of its parameters are not supported. 816 A multicast sender participating in a session MUST NOT use algorithms 817 outside the signalled signature algorithm set. A receiver MAY leave 818 any session where an algorithm outside the signature algorithm set is 819 used. 821 4. QUIC Profile 823 *Authors' Note:* The QUIC transport document is subject to change. 824 This section is based on our best understanding of draft-ietf- 825 quic-transport-08. The authors will track developments and will 826 update this section accordingly. 828 The profile of [QUIC-TRANSPORT] is presented in this section. In 829 order to preserve compatibility with conventional QUIC, the 830 specification works with a limited scope of change. However, the 831 nature of unidirectional multicast communications means that some 832 protocol procedures or behaviours need to be modified. 834 4.1. Packet Size 836 The means for determining an appropriate size for QUIC packets are 837 described in Section 14 of [QUIC-TRANSPORT]. Implementations of this 838 specification SHOULD bear in mind that the Path Maximum Transmission 839 Unit (PTMU) may be affected by multicast IP technologies such as 840 Automatic Multicast Tunneling (AMT) [RFC7450]. Additionally, 841 consideration should be given toward the applicability of maximum 842 transmission unit discovery methods (such as PLPMTUD [RFC4821] and 843 PMTUD [RFC1191]) to multicast IP. 845 4.2. Packet Format 847 Endpoints implementing this specification MUST only send QUIC packets 848 with the short header form. As short header packets do not include a 849 length, senders MUST NOT attempt to coalesce any QUIC packets in the 850 same UDP datagram. Therefore, all UDP datagrams sent by senders 851 conforming to this profile contain exactly one QUIC packet. 853 4.2.1. Packet Numbers 855 All packets for this profile SHALL be numbered in the application 856 data packet number space. The initial and handshake packet number 857 spaces are not used by this profile, as the handshake is replaced by 858 an out-of-band mechanism (see Section 2.4). 860 Because a recevier may join a session after the sender has already 861 sent several packets, it MUST NOT assume that the first packet number 862 will be 0. 864 4.2.2. Spin Bit 866 [QUIC-TRANSPORT] specifies a bit in the short packet header as the 867 latency spin bit that may be used to measure network round trip 868 latency between a client and a server. This mechanism is not usable 869 in a unidirectional multicast packet flow. Senders SHALL set the 870 spin bit to zero in all packets. Receivers SHOULD ignore the spin 871 bit. 873 *Authors' Note:* The authors welcome suggestions for the use of 874 the spin bit in a multicast context. 876 4.3. Connection Identifier 878 The Destination Connection ID field MUST be present in every QUIC 879 packet if the session was advertised with a "session-id" session 880 parameter (Section 10.2.5). If there is no Session ID session 881 parameter, then the Destination Connection ID MUST NOT be present in 882 any QUIC packet for that session. In the case where multiple 883 sessions are multiplexed on the same 5-tuple network association, the 884 Destination Connection ID field MUST be present in every QUIC packet 885 and must be distinct for each session. 887 4.4. Stream Identifier 889 The maximum Stream ID of a multicast QUIC session is 2^62, as 890 explained in Section 3.6. With the exception of the first client- 891 initiated request Stream ID, which is reserved as described in 892 Section 5.2, all Stream ID values SHALL be of the server-initiated 893 unidirectional stream type. 895 4.5. Flow Control 897 Conventional QUIC provides stream- and connection-level flow control, 898 and endpoints manage this by sending QUIC "MAX_DATA" or 899 "MAX_STREAM_DATA" frames as required. When a sender is blocked from 900 sending flow-controlled frames, it sends an informational QUIC 901 "BLOCKED" or "STREAM_BLOCKED" frame. 903 In a unidirectional environment, the sender never has a receive 904 window and the receiver cannot send in-band updates. Therefore, the 905 management of flow-control windows and transmission of blockage 906 information is not supported by this profile. The QUIC "MAX_DATA", 907 "MAX_STREAM_DATA", "BLOCKED" and "STREAM_BLOCKED" frames are 908 prohibited by this profile. Participants MUST NOT send these frame 909 types. Reception of these frame types MUST be handled as described 910 in Section 4.12. 912 4.6. Stream Termination 914 A sender MAY prematurely terminate the transmission on any unreserved 915 QUIC Stream ID by setting the "FIN" bit of a QUIC "STREAM" frame, or 916 by sending a QUIC "RESET_STREAM" frame (as specified in 917 [QUIC-TRANSPORT] and [QUIC-HTTP]). 919 Receiving participants MUST NOT make any attempt to send QUIC 920 "RESET_STREAM" frames to the multicast group. 922 4.7. Connection Shutdown 924 Explicit shutdown of a multicast QUIC session using QUIC methods is 925 not supported by this profile. 927 The QUIC "APPLICATION_CLOSE" and "CONNECTION_CLOSE" frames, and the 928 Stateless Reset packet are prohibited. Participants MUST NOT send 929 these and reception MUST be handled as described in Section 4.12. 931 Explicit session tear-down using HTTP semantics is allowed, as 932 described in Section 5.5. 934 Implicit shutdown by means of silent close is also supported, as 935 described in Section 3.4. 937 4.8. Connection Migration 939 [QUIC-TRANSPORT] has a connection migration feature that allows a 940 connection to survive changes to endpoint addresses. This profile 941 does not currently support connection migration, and as such the QUIC 942 "NEW_CONNECTION_ID" and "RETIRE_CONNECTION_ID" frames are prohibited. 943 Similarly, the QUIC "PATH_CHALLENGE" and "PATH_RESPONSE" frames are 944 also prohibited, but additionally because they require bidirectional 945 capability that this profile does not provide. 947 Endpoints participating in a session conforming to this profile 948 should only expect to use a single session ID for the duration of the 949 session, and as such there is no mapping for the 950 "active_connection_id_limit" transport parameter specified in section 951 5.1.1 of [QUIC-TRANSPORT] in this profile. 953 *Author's Note*: Seamless migration from one multicast QUIC 954 session to another is described in Section 2.1.3. 956 4.9. Explicit Congestion Notification 958 [QUIC-TRANSPORT] specifies that clients may use Explicit Congestion 959 Notification (ECN) [RFC3168]. ECN allows receivers to inform senders 960 of impending congestion before packets are dropped, and the sender 961 may then reduce its transmission rate. As ECN requires bidirectional 962 communication for the receiver to inform the sender of the 963 congestion, the use of ECN for this profile is prohibited. 965 *Author's Note*: It is the responsibility of a receiver to 966 determine whether network conditions permit the uncongested 967 reception of a given session based on the advertised "peak-flow- 968 rate" parameter. 970 4.10. Session Keep-alive 972 The flow of traffic in a multicast QUIC session is driven by a 973 sender. There may be periods where the sender has no application 974 data to send for a period longer than the session idle timeout. This 975 profile repurposes the QUIC "PING" frame to act as a unidirectional 976 keep-alive message that may be sent in order to inform receivers that 977 the session should remain in the Fully-established state. 978 [QUIC-TRANSPORT] contains guidance on the sending frequency of QUIC 979 "PING" frames. 981 Senders MAY send a QUIC "PING" frame at any time in order to inform 982 receivers that the session traffic flow has not fallen idle. This 983 frame MUST NOT be acknowledged. Indeed, QUIC "ACK" frames are 984 prohibited by this profile (Section 4.11). 986 Receiving participants MUST NOT make any attempt to send QUIC "PING" 987 frames. 989 4.11. Loss Detection and Recovery 991 Receivers implementing this profile MUST NOT make any attempt to 992 acknowledge the reception of QUIC packets. The QUIC "ACK" frame is 993 prohibited for both senders and receivers. Reception of this frame 994 MUST be handled as described in Section 4.12. 996 Section 7 specifies alternative strategies for loss recovery. 998 4.12. Prohibited QUIC Frames and Packets 1000 The following QUIC packets MUST NOT be transmitted by participants: 1001 Any packets with a long header (Initial, 0-RTT Protected, Handshake, 1002 Retry), Version Negotiation, Stateless Reset. 1004 The following QUIC frames MUST NOT be transmitted by participants: 1005 "ACK", "CONNECTION_CLOSE", "CRYPTO", "DATA_BLOCKED", "MAX_DATA", 1006 "MAX_STREAM_DATA", "MAX_STREAMS", "NEW_CONNECTION_ID", "NEW_TOKEN", 1007 "PATH_CHALLENGE", "PATH_RESPONSE", "RETIRE_CONNECTION_ID", 1008 "STOP_SENDING", "STREAM_DATA_BLOCKED", "STREAMS_BLOCKED". 1010 The following QUIC frames MUST NOT be transmitted by receivers: 1011 "PING", "RESET_STREAM". 1013 Reception of a prohibited QUIC frame or packet is a protocol error. 1014 Receivers MUST ignore all prohibited QUIC frames and packets. 1016 5. HTTP/3 Profile 1018 *Authors' Note:* The HTTP/3 mapping document is subject to change. 1019 This section is based on our best understanding of draft-ietf- 1020 quic-http-17. The authors will track developments and will update 1021 this section accordingly. 1023 HTTP over multicast QUIC depends on HTTP server push, as described in 1024 Section 4.4 of [QUIC-HTTP]. Section 5.2 below applies an additional 1025 constraint on the use of server push. A multicast sender 1026 participating in a session pushes resources as a series of QUIC 1027 "STREAM" frames carrying HTTP/3 "PUSH_PROMISE", "HEADERS" and "DATA" 1028 frames. Examples of this are provided in Appendix B.2. Senders MUST 1029 comply with the requirements of the session parameters, as described 1030 earlier in Section 3. 1032 The profile of HTTP/3 specified in this section places additional 1033 constrains on the use of metadata compression (Section 5.3) and 1034 prioritisation (Section 5.4). 1036 5.1. HTTP Connection Settings 1038 The HTTP/3 "SETTINGS" frame is prohibited by this profile. 1039 Participants MUST NOT make any attempt to send this frame type. 1040 Reception of this frame MUST be handled as described in Section 5.7. 1042 5.2. Server Push 1044 Server push is, by default, disabled for HTTP/3 connections. A 1045 conventional HTTP/3 client enables and manages server push by 1046 controlling the maximum Push ID ([QUIC-HTTP], Section 5.2.6), 1047 achieved by sending the HTTP/3 "MAX_PUSH_ID" frame. 1049 This profile mandates the use of server push, and specifies no means 1050 to disable it. The maximum Push ID for multicast QUIC sessions 1051 (initial and always) is 2^62. Values of Push ID SHALL be allocated 1052 in accordance with [QUIC-HTTP]. 1054 Server push concurrency in multicast QUIC is described in 1055 Section 3.6. There is no role for the HTTP/3 "MAX_PUSH_ID" frame and 1056 it is prohibited. Participants MUST NOT send this frame type. 1057 Reception of this frame type MUST be handled as described in 1058 Section 5.7. 1060 For this profile, the Stream Type for any new server-initiated 1061 unidirectional stream MUST be Server Push ("0x01"). 1063 The HTTP/3 "CANCEL_PUSH" frame MAY be used by sending participants to 1064 abort sending a response for the identified server push. Usage of 1065 this frame SHALL follow the guidance for servers in [QUIC-HTTP]. 1067 Receiving participants MUST NOT make any attempt to send HTTP/3 1068 "CANCEL_PUSH" frames to the multicast group. 1070 Conventionally, pushed responses are associated with an explicit 1071 request from a client. This is not possible when using a 1072 unidirectional transport such as multicast IP. This profile reserves 1073 the first client-initiated, bidirectional QUIC stream. HTTP/3 1074 "PUSH_PROMISE" frames MUST be sent on this reserved Stream ID. 1076 *Authors' Note:* The exact value of this Stream ID is currently in 1077 flux. This section will track developments and will be updated 1078 accordingly. It is currently expected to be Stream ID 0. 1080 5.3. Metadata Compression 1082 The compression of HTTP header fields is considered in QPACK 1083 [QUIC-QPACK], which describes two methods for the compression of HTTP 1084 header fields: indexing (via static or dynamic tables) and Huffman 1085 encoding. 1087 A multicast QUIC session, as described in the present document, does 1088 not provide the assurances (receiver participation, transport 1089 reliability) required to sufficiently maintain the dynamic decoding 1090 context. Therefore, this document requires that endpoints SHALL NOT 1091 use dynamic indexing. It is RECOMMENDED that endpoints use static 1092 indexing and/or Huffman encoding in order to benefit from the 1093 remaining compression methods available. 1095 5.4. Prioritisation 1097 The HTTP/3 "PRIORITY" frame is prohibited by this profile. 1098 Participants MUST NOT make any attempt to send this frame type. 1099 Reception of this frame MUST be handled as described in Section 5.7. 1101 5.5. Session Tear-down 1103 A multicast QUIC session MAY be explicitly torn down by means of the 1104 "Connection: close" HTTP header described in section 6.6 of 1105 [RFC7230]. A sender intending to leave the session SHOULD include 1106 the "Connection: close" header in its response metadata. A sender 1107 SHOULD transmit all outstanding frames related to remaining request/ 1108 response exchanges before ending transmission to the multicast group. 1109 A receiver SHOULD continue to receive and process frames until all 1110 outstanding request/response exchanges are complete. 1112 The HTTP/3 "GOAWAY" frame is prohibited. Participants MUST NOT send 1113 this and reception MUST be handled as described in Section 5.7. 1115 5.6. HTTP/3 Extension frames 1117 HTTP/3 extension frames (e.g. "ALTSVC") are prohibited by this 1118 profile. Participants MUST NOT make any attempt to send extension 1119 frame types. Reception of these MUST be handled as described in 1120 Section 5.7. 1122 5.7. Prohibited HTTP/3 Frames 1124 The following HTTP/3 frames MUST NOT be transmitted by participants: 1125 "DUPLICATE_PUSH", "GOAWAY", "MAX_PUSH_ID", "PRIORITY", "SETTINGS". 1127 In addition, all HTTP/3 extension frame types MUST NOT be transmitted 1128 by participants. 1130 The following HTTP/3 frames MUST NOT be transmitted by receivers: 1131 "CANCEL_PUSH". 1133 Reception of a prohibited HTTP/3 frame is a protocol error. 1134 Receivers MUST ignore prohibited HTTP/3 frames. 1136 6. Application-Layer Security 1138 As already described in Section 3.2, the implicit cipher suite used 1139 by a multicast QUIC session makes very limited provision for security 1140 in the transport and session layers. This section profiles the use 1141 of some additional features to provide equivalent functionality at 1142 the application-layer. 1144 6.1. Content Integrity 1146 In many applications, it is important to ensure that an HTTP 1147 representation has been received intact (i.e. has not suffered from 1148 transmission loss or random bit errors) before passing the received 1149 object on to the receiving application. A mechanism is therefore 1150 specified here to provide end-to-end content integrity protection for 1151 HTTP representations in transit. The use of this content integrity 1152 mechanism is RECOMMENDED. 1154 *Authors' Note:* We invite review comments on mandating the use of 1155 this content integrity mechanism. 1157 [RFC3230] specifies an instance digest HTTP header called "Digest". 1158 A sender MAY include this header in the HTTP/3 "HEADERS" frame of any 1159 representation it transmits and a receiver MAY use this header to 1160 validate the integrity of the received representation once it has 1161 been reassembled. Where this validation fails, the receiver SHOULD 1162 discard the representation without processing it further. 1164 Note that the digest value protects a whole HTTP instance (i.e. the 1165 representation of a resource at the point of transmission as opposed 1166 to the body of a particular HTTP message). In cases where partial 1167 representations are fragmented over one or more HTTP response 1168 messages, the digest value is computed over the complete 1169 representation prior to fragmentation into partial responses. 1171 Any of the algorithms specified in the IANA registry of digest 1172 algorithms (http://www.iana.org/assignments/http-dig-alg/http-dig- 1173 alg.xhtml#http-dig-alg-1) MAY be used in conjunction with the 1174 "Digest" header. There is no requirement for participants to support 1175 the full set of algorithms. 1177 6.2. Content Authenticity 1179 In some applications, it is important for a receiver to reassure 1180 itself that an HTTP representation has been received from an 1181 authentic source. It is also sometimes useful for a receiver to know 1182 that the information has not been tampered with in transit by a 1183 malicious intermediate actor. A mechanism is therefore specified 1184 here to prove the authenticity of HTTP messages in transit. The use 1185 of this content authenticity mechanism is RECOMMENDED for senders 1186 implementing this specification. 1188 *Authors' Note:* We invite review comments on mandating the use of 1189 this content authenticity mechanism. 1191 [I-D.cavage-http-signatures] specifies a means of securely signing 1192 metadata associated with any HTTP message. The resulting digital 1193 signature is conveyed in the "Signature" header of the message 1194 itself. The "Signature" header also conveys a list of HTTP header 1195 fields over which the signature was computed. A receiver MAY verify 1196 the "Signature" header in order to validate the authenticity of 1197 received metadata. Where this validation fails, the receiver SHOULD 1198 discard or ignore any related metadata and/or data without processing 1199 it further. 1201 Note that the signature proves the authenticity of the metadata in a 1202 single HTTP message. A "Signature" header MAY be included separately 1203 in the HTTP/3 "PUSH_PROMISE" frame (protecting the request metadata) 1204 and in the final (or only) HTTP/3 "HEADERS" frame relating to a 1205 particular resource (protecting the response metadata). In order to 1206 provide an additional level of protection, however, it is RECOMMENDED 1207 that the signature be computed over the combined request metadata 1208 (from the HTTP/3 "PUSH_PROMISE" frame) and the corresponding response 1209 metadata (from the HTTP/3 "HEADERS" frames) of the same resource. 1210 This binds the request metadata and response metadata together, 1211 providing the receiver with additional reassurance of authenticity. 1212 In this latter case, the combined digital signature SHALL be conveyed 1213 in the final (or only) HTTP/3 "HEADERS" frame. 1215 In applications where the detection of replay attacks is a 1216 requirement, it is RECOMMENDED that the "Date" header be included in 1217 the scope of the signature. It is RECOMMENDED that receivers use the 1218 value of the "Date" header for replay detection using appropriate 1219 strategies (e.g. checking for freshness). The definition of such 1220 strategies is beyond the scope of this document. 1222 In applications where the authenticity and integrity of the 1223 transmission are both important, it is RECOMMENDED that the "Digest" 1224 header specified in Section 6.1 above is included in the scope of the 1225 signature. By signing the instance digest, the authenticity and 1226 integrity of the HTTP message body are also assured in addition to 1227 that of the metadata. 1229 Any of the algorithms specified in the IANA registry of signature 1230 algorithms (http://www.iana.org/assignments/signature-algorithms) MAY 1231 be used in conjunction with the "Signature" header. There is no 1232 requirement for participants to support the full set of algorithms. 1234 6.3. Content Confidentiality 1236 In applications where there is a requirement for the content itself 1237 to remain confidential, appropriate steps SHOULD be taken to protect 1238 the application payload, for example by encrypting it. This document 1239 does not preclude the use of application-level encryption, but does 1240 not specify a mechanism for the distribution of content decryption 1241 keys. 1243 7. Loss Recovery 1245 Because the acknowledgement of received packets to multicast groups 1246 is prohibited by this specification (Section 4.11) the detection of 1247 discarded or corrupted packets is the sole responsibility of the 1248 receiver, and such losses must be recovered by means other than the 1249 retransmission mechanism specified in [QUIC-TRANSPORT] and 1250 [QUIC-RECOVERY]. 1252 7.1. Forward Error Correction 1254 *Authors' Note:* A simple parity-based Forward Error Correction 1255 scheme was removed from the experimental QUIC wire protocol 1256 specification in version Q032. The IETF's QUIC Working Group is 1257 chartered to specify one (or more) new FEC schemes in the future. 1258 This section will track developments in this area, and will be 1259 updated accordingly. 1261 A sender MAY make use of a suitable Forward Error Correction scheme 1262 to allow a receiver to reconstruct lost packets from those that have 1263 been successfully received. 1265 7.2. Unicast Repair 1267 In the case where a lost QUIC packet cannot be recovered using 1268 Forward Error Correction, either because the number of packets lost 1269 exceeds the scheme's threshold for reconstruction, or because FEC is 1270 not in use on the multicast QUIC session, a receiver MAY instead 1271 recover the missing payload data using conventional unicast HTTP 1272 requests to an origin server. 1274 o The total size of the resource is indicated in the "content- 1275 length" response header carried in the HTTP/3 "HEADERS" frame. 1277 o The location of the missing data can be determined by examining 1278 the Offset field in the QUIC "STREAM" frame headers of 1279 successfully received QUIC packets. 1281 Using this information, a receiver MAY compose an efficient HTTP 1282 range request [RFC7233] to the origin server indicated in the URL. 1283 Several disjoint ranges MAY be combined into a single HTTP request. 1284 A receiver MAY direct its request to an alternative server using Alt- 1285 Svc information received on the multicast QUIC session, or else 1286 received as part of a previous unicast HTTP response according to the 1287 rules in [RFC7838]. 1289 8. Transmission of Partial Content 1291 Under certain circumstances, a sender may not be in full possession 1292 of a resource body when transmission begins, or may not be able to 1293 guarantee that a transmission will complete. In such cases, the 1294 sender MAY employ the syntax of an HTTP range request [RFC7233] to 1295 indicate partial content, as specified below. All receivers SHALL 1296 implement support for such HTTP range requests. 1298 If partial content is to be transmitted: 1300 o The "range" header (Section 3.1 of [RFC7233]) SHALL be present in 1301 the HTTP/3 "PUSH_PROMISE" frame. 1303 o The corresponding HTTP/3 "HEADERS" frame SHALL indicate HTTP 1304 status code 206. 1306 * The range being transmitted SHALL be indicated in a "content- 1307 range" header field and the size of the complete resource 1308 indicated in a "content-length" header field. 1310 9. Protocol Identifier 1312 The HTTP over multicast QUIC protocol specified in this document is 1313 identified by the application-layer protocol negotiation (ALPN) 1314 [RFC7301] identifier "hqm". The IANA registration of this protocol 1315 identifier can be found in Section 12.1. This reserves the ALPN 1316 identifier space but describes a protocol that does not use TLS. The 1317 usage of the "hqm" identifier for discoverability is described in 1318 Section 10. 1320 9.1. Draft Version Identification 1322 *RFC Editor's Note:* Please remove this section prior to 1323 publication of a final version of this document. 1325 Only implementations of the final, published RFC can identify 1326 themselves as "hqm". Until such an RFC exists, implementations MUST 1327 NOT identify themselves using this string. 1329 Implementations of draft versions of the protocol MUST add the string 1330 "-" and the corresponding draft number to the identifier. For 1331 example, draft-pardue-quic-http-mcast-00 is identified using the 1332 string "hqm-00". 1334 Non-compatible experiments that are based on these draft versions 1335 MUST append the string "-" and an experiment name to the identifier. 1336 For example, an experimental implementation based on draft-pardue- 1337 quic-http-mcast-09 which removes the requirement to ensure version 1338 matches might identify itself as "hqm-09-version-ignorant". Note 1339 that any label MUST conform to the "token" syntax defined in 1340 Section 3.2.6 of [RFC7230]. Experimenters are encouraged to 1341 coordinate their experiments. 1343 10. Discovery of Multicast QUIC Sessions 1345 The announcement and discovery of services operating over multicast 1346 IP has previously been specified by the Session Description Protocol 1347 (SDP) [RFC4566], Session Announcement Protocol [RFC2974] and Session 1348 Initiation Protocol [RFC3261]. These are typically deployed together 1349 and in conjunction with a multicast-friendly transport such as the 1350 Real-time Transport Protocol (RTP) [RFC3550]. 1352 In contrast, the present document specifies a mechanism for 1353 advertising services that is built into HTTP metadata and is 1354 consistent across unicast and multicast resource delivery modes. 1355 This means that a single application-layer can be used for service 1356 advertisement/discovery, and for bulk data transmission/reception. 1357 Specifically, the "Alt-Svc" HTTP header is specified as the means to 1358 advertise multicast services from a unicast service. A unicast HTTP 1359 response MAY be decorated with an Alt-Svc value that hints to the 1360 client about the availability of the resource via a multicast QUIC 1361 session. A client that supports such a multicast QUIC session MAY 1362 then transparently switch to it. 1364 Symmetrically, the "Alt-Svc" header can also be used to advertise the 1365 unicast service from a multicast service. A resource transmitted as 1366 part of a multicast QUIC session MAY be decorated with an Alt-Svc 1367 value that hints to the client about the availability of the resource 1368 via an alternative unicast HTTP server. A receiver MAY then use this 1369 HTTP server for unicast resource patching (Section 7.2). 1371 Where HTTP over multicast QUIC sessions are advertised using Alt-Svc, 1372 the protocol identifier SHALL be "hqm", as specified in Section 9. 1374 10.1. Source-specific Multicast Advertisement 1376 Source-specific multicast (SSM) [RFC4607] MAY be used for the 1377 delivery of multicast services. 1379 *Authors' Note:* We invite review comments on mandating the use of 1380 source-specific multicast only. 1382 This document specifies the "source-address" parameter for Alt-Svc, 1383 which is used to provide the SSM source address to endpoints. 1385 Syntax: 1387 source-address = uri-host; see RFC7230, Section 2.7 1389 For example: 1391 source-address="192.0.2.1" 1393 When a multicast QUIC session is provided using SSM, the "source- 1394 address" parameter MUST be advertised. 1396 10.2. Session Parameter Advertisement 1398 The concept of session parameters is introduced in Section 2.2. This 1399 section details how the session parameters are expressed as Alt-Svc 1400 parameters. 1402 10.2.1. Version 1404 The version of QUIC supported in a multicast QUIC session is 1405 advertised with the "quic" parameter. The requirements for endpoint 1406 usage of "quic" are specified in Section 3.1. 1408 10.2.2. Cipher Suite 1410 This document specifies the "cipher-suite" parameter for Alt-Svc, 1411 which carries the cipher suite in use by a multicast QUIC session. 1412 "cipher-suite" MUST contain one of the values contained in the TLS 1413 Cipher Suite Registry (http://www.iana.org/assignments/tls- 1414 parameters/tls-parameters.xhtml#tls-parameters-4): 1416 Syntax: 1418 cipher-suite = 4*4 HEXDIG 1420 For example, the following specifies cipher suite 0x13,0x01 1421 ("TLS_AES_128_GCM_SHA256"): 1423 cipher-suite=1301 1425 The requirements for endpoint usage of "cipher-suite" are described 1426 in Section 3.2. 1428 10.2.3. Session Key 1430 This document specifies the "key" parameter for Alt-Svc, which 1431 carries the cryptographic key in use by the multicast QUIC session. 1433 Syntax: 1435 key = *HEXDIG 1437 For example: 1439 key=4adf1eab9c2a37fd 1441 The requirements for endpoint usage of "key" are described in 1442 Section 3.2. 1444 10.2.4. Session Cipher Initialization Vector 1446 This document specifies the "iv" parameter for Alt-Svc, which carries 1447 the cipher Initialization Vector (IV) in use by the multicast QUIC 1448 session. 1450 Syntax: 1452 iv = *HEXDIG 1454 For example: 1456 iv=4dbe593acb4d1577ad6ba7dc3189834e 1458 The requirements for endpoint usage of "iv" are described in 1459 Section 3.2. 1461 10.2.5. Session Identification 1463 This document defines the "session-id" parameter for Alt-Svc, which 1464 carries the multicast QUIC session identifier. 1466 Syntax: 1468 session-id = *HEXDIG 1470 For example, the following specifies session 101 (0x65 hexadecimal): 1472 session-id=65 1474 The requirements for endpoint usage of "session-id" are described in 1475 Section 2.3. In the above example, the Destination Connection ID 1476 field in every QUIC packet header would be one byte in size. For a 1477 session-id of BADBEEF then then Destintation Connection ID field in 1478 every QUIC packet header would be four bytes in size. 1480 10.2.6. Session Idle Timeout Period 1482 This document specifies the "session-idle-timeout" parameter for Alt- 1483 Svc, which carries the idle timeout period of a multicast QUIC 1484 session. 1486 Syntax: 1488 session-idle-timeout = *DIGIT ; number of seconds between 0 and 600 1490 For example, the following specifies a one-minute session idle 1491 timeout period: 1493 session-idle-timeout=60 1495 The requirements for endpoint usage of "session-idle-timeout" are 1496 described in Section 3.4. 1498 10.2.7. Resource Concurrency 1500 This document specifies the "max-concurrent-resources" parameter for 1501 Alt-Svc, which expresses the maximum number of concurrent active 1502 resources from the sender in a multicast QUIC session. 1504 Syntax: 1506 max-concurrent-resources = *DIGIT ; unsigned 32-bit integer 1508 For example, the following specifies that no more than 12 (decimal) 1509 resources will be concurrently active in the session: 1511 max-concurrent-resources=12 1513 The requirements for endpoint usage of "max-concurrent-resources" are 1514 described in Section 3.6. 1516 10.2.8. Session Peak Flow Rate 1518 This document specifies the "peak-flow-rate" parameter for Alt-Svc, 1519 which expresses the expected maximum aggregate transfer rate of data 1520 from all sources of the multicast QUIC session. 1522 Syntax: 1524 peak-flow-rate = *DIGIT ; bits per second 1526 For example, the following specifies a peak flow rate of 550 kbits/s 1527 in the session: 1529 peak-flow-rate=550000 1531 The requirements for endpoint usage of "peak-flow-rate" are described 1532 in Section 3.5. 1534 10.2.9. Digest Algorithm 1536 This document specifies the "digest-algorithm" parameter for Alt-Svc, 1537 which carries the digest algorithm in use by a multicast QUIC 1538 session. "digest-algorithm" MUST contain one of the values defined in 1539 the HTTP Digest Algorithm Values registry 1540 (https://www.iana.org/assignments/http-dig-alg/http-dig- 1541 alg.xhtml#http-dig-alg-1). 1543 Syntax: 1545 digest-algorithm = token 1547 For example, the following specifies a digest algorithm of SHA-256: 1549 digest-algorithm=SHA-256 1551 The requirements for endpoint usage of "digest-algorithm" are 1552 described in Section 3.8. 1554 10.2.10. Signature Algorithm 1556 This document specifies the "signature-algorithm" parameter for Alt- 1557 Svc, which carries the signature algorithm in use by a multicast QUIC 1558 session. "signature-algorithm" MUST contain one of the values defined 1559 in the Signature Algorithms registry 1560 (http://www.iana.org/assignments/signature-algorithms). 1562 Syntax: 1564 signature-algorithm = token 1566 For example, the following specifies a signature algorithm of SHA- 1567 256: 1569 signature-algorithm=rsa-sha256 1571 The requirements for endpoint usage of "signature-algorithm" are 1572 described in Section 3.9. 1574 11. Security and Privacy Considerations 1576 This document specifies a profile of QUIC and HTTP/3 that changes the 1577 security model. In order to address this, application-level security 1578 methods are described in Section 6. This document does not preclude 1579 the use of secure multicast approaches that may provide additional 1580 security assurances required for certain use cases. 1582 The use of side-channel or out-of-band technologies (potentially 1583 bidirectional interactions) to support multicast QUIC sessions are 1584 considered out of this document's scope. Services using such 1585 technologies should apply their security considerations accordingly. 1587 11.1. Pervasive Monitoring 1589 Certain multicast deployment architectures may require the use of a 1590 session decryption key shared by all participants. Furthermore, the 1591 discovery mechanism described in this document provides a means for a 1592 receiver to obtain a session decryption key without joining the 1593 session. The act of removing packet protection in order to inspect 1594 or modify application contents may, in certain deployments, be 1595 trivial. The exploration of restricting key learning or session 1596 joining to authorised participants goes beyond the scope of this 1597 document. 1599 Because in-band multicast interactions are unidirectional, the impact 1600 of Pervasive Monitoring [RFC7258] on in-band traffic flows is 1601 inherently reduced. Actors can only inspect or modify sender- 1602 initiated traffic. Additional measures for content confidentiality 1603 may mitigate the impact further. This is discussed in Section 6.3. 1605 Further Pervasive Monitoring concerns are addressed in the following 1606 sections. 1608 11.1.1. Large-scale Data Gathering and Correlation 1610 Multicast QUIC sessions decouple sending and receiving participants. 1611 Session participation is subject to operations that allow an endpoint 1612 to join or leave a multicast group, typically IGMP [RFC3376] or MLD 1613 [RFC3810]. The propagation intent of these messages travelling 1614 deeper through a network hierarchy generally leads to the 1615 anonymisation of data if implemented as specified. It may be 1616 possible to gather user-identifiable messages close to the network 1617 edge, for example a router logging such messages. However, this 1618 would require wide-ranging access across Internet Service Provider 1619 networks. Therefore, while such attacks are feasible, it can be 1620 asserted that gathering and correlating user-identifiable traffic is 1621 difficult to perform covertly and at scale. 1623 11.1.2. Changing Content 1625 Sessions that use a symmetric key for packet protection are subject 1626 to the possibility of a malicious actor modifying traffic at some 1627 point in the network between a legitimate sender and one (or more) 1628 receivers. Receiver-side validation, as specified in Section 6 of 1629 the present document, and also in [QUIC-TRANSPORT], allows for the 1630 detection of such modification. Two approaches help mitigate the 1631 impact of modification; the first is application-level methods that 1632 protect data (Section 6.1) and metadata (Section 6.2); the second is 1633 reduction of the QUIC packet attack surface by means of removal of 1634 many frame types (Section 4.12 and Section 5.7). 1636 11.2. Protection of Discovery Mechanism 1638 Multicast QUIC session advertisements SHOULD be conveyed over a 1639 secure transport that guarantees authenticity and integrity in order 1640 to mitigate attacks related to a malicious service advertisement, for 1641 example a "man in the middle" directing endpoints to a service that 1642 may lead to other attacks or exploitations. 1644 *Authors' Note:* We invite review comments on mandating the use of 1645 a secure transport for advertising sessions. 1647 Endpoints that make use of multicast QUIC session advertisements 1648 SHOULD have reasonable assurance that the alternative service is 1649 under control of, and valid for, the whole origin, as described in 1650 Section 2.1 of [RFC7838]. Section 6.2 discusses measures that may be 1651 used to fulfil this requirement. 1653 11.3. Spoofing 1655 11.3.1. Spoofed Ack Attacks 1657 The Spoofed "ACK" attack described in Section 13.1 of 1658 [QUIC-TRANSPORT] is out of scope because use of the QUIC "ACK" frame 1659 is prohibited (Section 4.11) by the present document. 1661 11.3.2. Sender Spoofing 1663 A malicious actor may be able to stage a spoof attack by sending fake 1664 QUIC packets to a multicast QUIC session. This could affect the 1665 operation or behaviour of receivers. In a multicast scenario, this 1666 form of attack has the potential to scale massively. 1668 The feasibility of spoofing a multicast sender is governed by the 1669 characteristics of the multicast deployment and network 1670 infrastructure. The use of source-specific multicast [RFC4607] may 1671 reduce the feasibility. The use of content authenticity 1672 (Section 6.2) may mitigate concerns for the application-level 1673 messages. However, there remains the possibility for transport-level 1674 messages to be spoofed. Multicast applications should consider 1675 further mitigations to address this concern. 1677 11.3.3. Receiver Spoofing 1679 Client source address concerns discussed in Section 7.5 of 1680 [QUIC-TRANSPORT] are out of scope because the connection 1681 establishment is replaced with session establishment in the present 1682 document. Further, the impact that spoofed receivers would have on 1683 the sender is minimal. The impact of malicious participants on the 1684 network is discussed in Section 11.6.2. 1686 11.4. Replay Attacks 1688 Conventional QUIC strategies for protecting against replay attacks 1689 apply similarly here. 1691 Certain multicast QUIC sessions may use a shared key for transport- 1692 level encryption, which would allow an attacker to record, decrypt, 1693 repackage and replay QUIC packets. Section 6.2 discusses how the 1694 application-level contents may be protected from replay (by signing 1695 the "Date" HTTP header), which provides some mitigation to the 1696 success rate or effects of replay attacks. 1698 11.5. Message Deletion 1700 Since HTTP over multicast QUIC is designed to tolerate unreliable 1701 delivery, the impacts of message deletion attacks are presumed to be 1702 small. Deletion of packets carrying HTTP headers will cause a 1703 receiver to ignore subsequent packets carrying body data. 1704 Furthermore, the use of multicast QUIC sessions is opportunistic; 1705 disruption in service (for example, deleting packets and causing a 1706 receiver to fail in construction of a content object) is mitigated by 1707 falling back to a unicast service. Considerations for how this may 1708 affect the performance of the unicast service are given in 1709 Section 11.6.3. 1711 11.6. Denial of Service 1713 11.6.1. Unprotected Frames and Packets 1715 The handling of unprotected QUIC packets is discussed in section 1716 9.1.4 of [QUIC-TLS]. The profile described in the present document 1717 provides the means for a multicast sender to protect QUIC packets 1718 with a shared key, which is not a strong protection. The weak 1719 protection of QUIC packets could present a denial-of-service risk. 1720 To mitigate the impact of handling such QUIC packets, certain frames 1721 and packets are prohibited as described in (Section 4.12 and 1722 Section 5.7). 1724 The frame types that are allowed by this profile do not present a 1725 risk of denial of service. Concerns over authenticity and integrity 1726 are addressed by the application-layer protection mechanisms 1727 described in Section 6. 1729 11.6.2. Network Performance Degradation 1731 The possibility for malfunctioning or malicious participants to 1732 degrade the network is a broad issue and considered out of scope for 1733 this document. Guidelines and concerns discussed in UDP Best 1734 Practices [RFC8085] and other sources apply equally here. This 1735 specification does not preclude the use of network performance 1736 degradation mitigation solutions such as network circuit breakers. 1738 11.6.3. Unicast Repair Stampeding Herd 1740 Deployments that support the unicast repair mechanism described in 1741 Section 7.2 should be aware that a triggering of this behaviour 1742 (either deliberate, planned or unplanned) in a large population of 1743 multicast receivers may cause a stampeding herd of client requests to 1744 the unicast repair service. Service operators SHOULD mitigate the 1745 impact of stampeding herd on their deployment. 1747 11.7. Receiver Resource Usage 1749 The application of receiver-side validation, as defined in the 1750 present document and in [QUIC-TRANSPORT], adds some protection 1751 against allocating resource to the processing of bad data. 1753 11.8. Unicast Repair Information Leakage 1755 The unicast repair mechanism may lead to the leakage of user 1756 behaviour data. An attacker could gain insight into any receiver 1757 participating in a multicast QUIC session, for example by monitoring 1758 the TCP port of the unicast alternative. This alone is no worse than 1759 current abilities to monitor unicast interactions, for example 1760 observing the SNI field contained in a TLS ClientHello. The complete 1761 protection of unicast interactions is beyond the scope of this 1762 document. However, knowledge that a user (or group of users) has 1763 participated in a session is sensitive and may be obtained by 1764 correlation between with observable multicast and unicast traffic. 1766 To give an example, a malicious "man in the middle" could purposely 1767 cause all receivers to perform a unicast repair (by disrupting the 1768 QUIC traffic flow in some way). The disruption is untargeted and may 1769 be simple to orchestrate, but the correlation of user activity data, 1770 especially across a distributed repair service (e.g. a CDN), requires 1771 resources that may reduce the attractiveness of such an attack. 1773 The ability for an attacker to disrupt multicast QUIC sessions is 1774 mitigated by this profile (mainly the prohibition of frames and 1775 packets). Application-layer security measures described in Section 6 1776 reduce the feasibility further. 1778 Multicast receivers concerned about this form of leakage can 1779 eliminate this risk completely by disabling support for unicast 1780 repair, at the potential cost of reduced service quality. 1782 12. IANA Considerations 1784 12.1. Registration of Protocol Identification String 1786 This document creates a new registration for the identification of 1787 the HTTP over multicast QUIC protocol in the "Application-Layer 1788 Protocol Negotiation (ALPN) Protocol IDs" registry established by 1789 [RFC7301]. 1791 The "hqm" string identifies HTTP semantics expressed as HTTP mapped 1792 to a QUIC layer and carried over IP multicast: 1794 Protocol: Bulk data transport using HTTP over multicast QUIC 1795 Identification Sequence: 0x68 0x71 0x6D ("hqm") 1797 Specification: This document, Section 9 1799 This entry reserves an identifier that is not allowed to appear in 1800 TLS Application-Layer Protocol Negotiation. 1802 12.2. Registration of Alt-Svc parameters 1804 This document creates seven registrations for the identification of 1805 parameters for the "Hypertext Transfer Protocol (HTTP) Alt-Svc 1806 Parameter Registry" established by [RFC7838] 1807 (http://www.iana.org/assignments/tls-extensiontype-values/tls- 1808 extensiontype-values.xhtml#alpn-protocol-ids). 1810 12.2.1. Source Address 1812 Parameter name: source-address 1814 Specification: This document, Section 10.1 1816 12.2.2. Cipher Suite 1818 Parameter name: cipher-suite 1820 Specification: This document, Section 10.2.2 1822 12.2.3. Key 1824 Parameter name: key 1826 Specification: This document, Section 10.2.3 1828 12.2.4. Initialization Vector 1830 Parameter name: iv 1832 Specification: This document, Section 10.2.4 1834 12.2.5. Session Identifier 1836 Parameter name: session-id 1838 Specification: This document, Section 10.2.5 1840 12.2.6. Session Idle Timeout 1842 Parameter name: session-idle-timeout 1844 Specification: This document, Section 10.2.6 1846 12.2.7. Maximum Concurrent Resources 1848 Parameter name: max-concurrent-resources 1850 Specification: This document, Section 10.2.7 1852 12.2.8. Peak Flow Rate 1854 Parameter name: peak-flow-rate 1856 Specification: This document, Section 10.2.8 1858 12.2.9. Digest Algorithm 1860 Parameter name: digest-algorithm 1862 Specification: This document, Section 10.2.9 1864 12.2.10. Signature Algorithm 1866 Parameter name: signature-algorithm 1868 Specification: This document, Section 10.2.10 1870 13. References 1872 13.1. Normative References 1874 [I-D.cavage-http-signatures] 1875 Cavage, M. and M. Sporny, "Signing HTTP Messages", draft- 1876 cavage-http-signatures-11 (work in progress), April 2019. 1878 [QUIC-HTTP] 1879 Bishop, M., Ed., "Hypertext Transfer Protocol Version 3 1880 (HTTP/3)", draft-ietf-quic-http-22 (work in progress). 1882 [QUIC-QPACK] 1883 Krasic, C., Ed., Bishop, M., Ed., and A. Frindell, Ed., 1884 "QPACK: Header Compression for HTTP over QUIC", draft- 1885 ietf-quic-qpack-09 (work in progress). 1887 [QUIC-TRANSPORT] 1888 Iyengar, J., Ed. and M. Thomson, Ed., "QUIC: A UDP-Based 1889 Multiplexed and Secure Transport", draft-ietf-quic- 1890 transport-22 (work in progress). 1892 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 1893 Requirement Levels", BCP 14, RFC 2119, 1894 DOI 10.17487/RFC2119, March 1997, 1895 . 1897 [RFC3168] Ramakrishnan, K., Floyd, S., and D. Black, "The Addition 1898 of Explicit Congestion Notification (ECN) to IP", 1899 RFC 3168, DOI 10.17487/RFC3168, September 2001, 1900 . 1902 [RFC3230] Mogul, J. and A. Van Hoff, "Instance Digests in HTTP", 1903 RFC 3230, DOI 10.17487/RFC3230, January 2002, 1904 . 1906 [RFC4607] Holbrook, H. and B. Cain, "Source-Specific Multicast for 1907 IP", RFC 4607, DOI 10.17487/RFC4607, August 2006, 1908 . 1910 [RFC5234] Crocker, D., Ed. and P. Overell, "Augmented BNF for Syntax 1911 Specifications: ABNF", STD 68, RFC 5234, 1912 DOI 10.17487/RFC5234, January 2008, 1913 . 1915 [RFC7230] Fielding, R., Ed. and J. Reschke, Ed., "Hypertext Transfer 1916 Protocol (HTTP/1.1): Message Syntax and Routing", 1917 RFC 7230, DOI 10.17487/RFC7230, June 2014, 1918 . 1920 [RFC7233] Fielding, R., Ed., Lafon, Y., Ed., and J. Reschke, Ed., 1921 "Hypertext Transfer Protocol (HTTP/1.1): Range Requests", 1922 RFC 7233, DOI 10.17487/RFC7233, June 2014, 1923 . 1925 [RFC7234] Fielding, R., Ed., Nottingham, M., Ed., and J. Reschke, 1926 Ed., "Hypertext Transfer Protocol (HTTP/1.1): Caching", 1927 RFC 7234, DOI 10.17487/RFC7234, June 2014, 1928 . 1930 [RFC7301] Friedl, S., Popov, A., Langley, A., and E. Stephan, 1931 "Transport Layer Security (TLS) Application-Layer Protocol 1932 Negotiation Extension", RFC 7301, DOI 10.17487/RFC7301, 1933 July 2014, . 1935 [RFC7405] Kyzivat, P., "Case-Sensitive String Support in ABNF", 1936 RFC 7405, DOI 10.17487/RFC7405, December 2014, 1937 . 1939 [RFC7838] Nottingham, M., McManus, P., and J. Reschke, "HTTP 1940 Alternative Services", RFC 7838, DOI 10.17487/RFC7838, 1941 April 2016, . 1943 [RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC 1944 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, 1945 May 2017, . 1947 13.2. Informative References 1949 [QUIC-RECOVERY] 1950 Iyengar, J., Ed. and I. Swett, Ed., "QUIC Loss Detection 1951 and Congestion Control", draft-ietf-quic-recovery-22 (work 1952 in progress). 1954 [QUIC-TLS] 1955 Thomson, M., Ed. and S. Turner, Ed, Ed., "Using Transport 1956 Layer Security (TLS) to Secure QUIC", draft-ietf-quic- 1957 tls-22 (work in progress). 1959 [RFC1112] Deering, S., "Host extensions for IP multicasting", STD 5, 1960 RFC 1112, DOI 10.17487/RFC1112, August 1989, 1961 . 1963 [RFC1191] Mogul, J. and S. Deering, "Path MTU discovery", RFC 1191, 1964 DOI 10.17487/RFC1191, November 1990, 1965 . 1967 [RFC2974] Handley, M., Perkins, C., and E. Whelan, "Session 1968 Announcement Protocol", RFC 2974, DOI 10.17487/RFC2974, 1969 October 2000, . 1971 [RFC3261] Rosenberg, J., Schulzrinne, H., Camarillo, G., Johnston, 1972 A., Peterson, J., Sparks, R., Handley, M., and E. 1973 Schooler, "SIP: Session Initiation Protocol", RFC 3261, 1974 DOI 10.17487/RFC3261, June 2002, 1975 . 1977 [RFC3376] Cain, B., Deering, S., Kouvelas, I., Fenner, B., and A. 1978 Thyagarajan, "Internet Group Management Protocol, Version 1979 3", RFC 3376, DOI 10.17487/RFC3376, October 2002, 1980 . 1982 [RFC3550] Schulzrinne, H., Casner, S., Frederick, R., and V. 1983 Jacobson, "RTP: A Transport Protocol for Real-Time 1984 Applications", STD 64, RFC 3550, DOI 10.17487/RFC3550, 1985 July 2003, . 1987 [RFC3810] Vida, R., Ed. and L. Costa, Ed., "Multicast Listener 1988 Discovery Version 2 (MLDv2) for IPv6", RFC 3810, 1989 DOI 10.17487/RFC3810, June 2004, 1990 . 1992 [RFC4566] Handley, M., Jacobson, V., and C. Perkins, "SDP: Session 1993 Description Protocol", RFC 4566, DOI 10.17487/RFC4566, 1994 July 2006, . 1996 [RFC4821] Mathis, M. and J. Heffner, "Packetization Layer Path MTU 1997 Discovery", RFC 4821, DOI 10.17487/RFC4821, March 2007, 1998 . 2000 [RFC5737] Arkko, J., Cotton, M., and L. Vegoda, "IPv4 Address Blocks 2001 Reserved for Documentation", RFC 5737, 2002 DOI 10.17487/RFC5737, January 2010, 2003 . 2005 [RFC5740] Adamson, B., Bormann, C., Handley, M., and J. Macker, 2006 "NACK-Oriented Reliable Multicast (NORM) Transport 2007 Protocol", RFC 5740, DOI 10.17487/RFC5740, November 2009, 2008 . 2010 [RFC6676] Venaas, S., Parekh, R., Van de Velde, G., Chown, T., and 2011 M. Eubanks, "Multicast Addresses for Documentation", 2012 RFC 6676, DOI 10.17487/RFC6676, August 2012, 2013 . 2015 [RFC6726] Paila, T., Walsh, R., Luby, M., Roca, V., and R. Lehtonen, 2016 "FLUTE - File Delivery over Unidirectional Transport", 2017 RFC 6726, DOI 10.17487/RFC6726, November 2012, 2018 . 2020 [RFC7258] Farrell, S. and H. Tschofenig, "Pervasive Monitoring Is an 2021 Attack", BCP 188, RFC 7258, DOI 10.17487/RFC7258, May 2022 2014, . 2024 [RFC7450] Bumgardner, G., "Automatic Multicast Tunneling", RFC 7450, 2025 DOI 10.17487/RFC7450, February 2015, 2026 . 2028 [RFC8085] Eggert, L., Fairhurst, G., and G. Shepherd, "UDP Usage 2029 Guidelines", BCP 145, RFC 8085, DOI 10.17487/RFC8085, 2030 March 2017, . 2032 [RFC8200] Deering, S. and R. Hinden, "Internet Protocol, Version 6 2033 (IPv6) Specification", STD 86, RFC 8200, 2034 DOI 10.17487/RFC8200, July 2017, 2035 . 2037 Appendix A. Acknowledgements 2039 The authors would like to thank the following for their contributions 2040 to the design described in the present document: Brandon Butterworth, 2041 Chris Poole, Craig Taylor and David Waring. 2043 We are also grateful to Thomas Swindells and Magnus Westerlund for 2044 their helpful review comments. 2046 Appendix B. Examples 2048 This appendix contains examples of multicast QUIC session 2049 advertisement and resource transfer (with and without application- 2050 layer content security). 2052 B.1. Session Advertisement 2054 This section shows several different examples of an HTTP service 2055 advertising a multicast QUIC session. Examples are given in IPv4 2056 form, using reserved address ranges as specified in [RFC5737] and 2057 [RFC6676]. 2059 B.1.1. Source-specific Multicast QUIC Session 2061 Advertisement of a multicast QUIC session operating on the source- 2062 specific multicast group address 232.0.0.1 on port 2000 with the 2063 source address 192.0.2.1. The session ID is 16 (0x10) and the idle 2064 timeout is one minute. At most 10 resources may be concurrently 2065 active in the session and the flow rate should not exceed 10 kbits/s. 2066 The multicast transport is unencrypted. 2068 HTTP Alternative Service header field: 2070 Alt-Svc: 2071 hqm="232.0.0.1:2000"; source-address="192.0.2.1"; quic=1; 2072 session-id=10; session-idle-timeout=60; 2073 max-concurrent-resources=10; peak-flow-rate=10000 2075 B.1.2. Source-specific Multicast QUIC Session with Transport Encryption 2076 using a Symmetric Key 2078 Advertisement of a multicast QUIC session operating on the IPv6 2079 globally-scoped source-specific multicast group address ff3e::1234 on 2080 port 2000 with the source address 2001:db8::1. The session ID is 16 2081 (0x10) and the idle timeout is one minute. At most 10 resources may 2082 be concurrently active in the session and the flow rate should not 2083 exceed 10 kbits/s. The multicast transport is encrypted using the 2084 AEAD cipher suite 0x13,0x01 ("TLS_AES_128_GCM_SHA256") with the 2085 shared session key and IV provided. 2087 HTTP Alternative Service header field: 2089 Alt-Svc: 2090 hqm="[ff3e::1234]:2000"; source-address="2001:db8::1"; quic=1; 2091 session-id=10; session-idle-timeout=60; 2092 max-concurrent-resources=10; peak-flow-rate=10000; 2093 cipher-suite=1301; key=4adf1eab9c2a37fd; 2094 iv=4dbe593acb4d1577ad6ba7dc3189834e 2096 B.1.3. Source-specific Multicast QUIC Session with Transport 2097 Encryption, Content Integrity and Authenticity 2099 Advertisement of a multicast QUIC session operating on the IPv6 2100 globally-scoped source-specific multicast group address ff3e::1234 on 2101 port 2000 with the source address 2001:db8::1. The session ID is 16 2102 (0x10) and the idle timeout is one minute. At most 10 resources may 2103 be concurrently active in the session and the flow rate should not 2104 exceed 10 kbits/s. The multicast transport is encrypted using the 2105 AEAD cipher suite 0x13,0x01 ("TLS_AES_128_GCM_SHA256") with the 2106 shared session key and IV provided. Content integrity is in use with 2107 the digest algorithm set restricted to SHA-256. Content authenticity 2108 is in use with the signature algorithm set restricted to rsa-sha256. 2110 HTTP Alternative Service header field: 2112 Alt-Svc: 2113 hqm="[ff3e::1234]:2000"; source-address="2001:db8::1"; quic=1; 2114 session-id=10; session-idle-timeout=60; 2115 max-concurrent-resources=10; peak-flow-rate=10000; 2116 cipher-suite=1301; key=4adf1eab9c2a37fd; 2117 iv=4dbe593acb4d1577ad6ba7dc3189834e; 2118 digest-algorithm=SHA-256; signature-algorithm=rsa-sha256 2120 B.2. Resource Transfer 2122 This section shows several different examples of the HTTP message 2123 patterns for a single resource. 2125 Examples that show HTTP/3 "PUSH_PROMISE" or "HEADERS" frames describe 2126 the contents of enclosed header block fragments. 2128 B.2.1. Transfer without Content Integrity or Authenticity 2130 HTTP/3 "PUSH_PROMISE" frame: 2132 :method: GET 2133 :scheme: https 2134 :path: /files/example.txt 2135 :authority: example.org 2137 HTTP/3 "HEADERS" frame; 2139 :status: 200 2140 content-length: 100 2141 content-type: text/plain 2142 date: Fri, 20 Jan 2017 10:00:00 GMT 2144 HTTP/3 "DATA" frame containing 100 bytes of response body data: 2146 ... 2148 B.2.2. Transfer of Partial Content without Content Integrity or 2149 Authenticity 2151 In this example, partial content is transferred as described in 2152 Section 8. The "Range" request header is used to indicate the 2153 sender's original intention to transfer all 100 bytes of the 2154 representation. The "Content-Range" response header indicates that 2155 only the first 50 bytes were actually sent. 2157 HTTP/3 "PUSH_PROMISE" frame: 2159 :method: GET 2160 :scheme: https 2161 :path: /files/example.txt 2162 :authority: example.org 2163 range: bytes=0-* 2165 HTTP/3 "HEADERS" frame: 2167 :status: 206 2168 content-length: 100 2169 content-range: bytes 0-49/100 2170 content-type: text/plain 2171 date: Fri, 20 Jan 2017 10:00:00 GMT 2173 HTTP/3 "DATA" frame containing 50 bytes of response body data: 2175 ... 2177 B.2.3. Transfer with Content Integrity and without Authenticity 2179 In this example, content integrity is assured by the inclusion of the 2180 "Digest" response header, as described in Section 6.1. 2182 HTTP/3 "PUSH_PROMISE" frame: 2184 :method: GET 2185 :scheme: https 2186 :path: /files/example.txt 2187 :authority: example.org 2189 HTTP/3 "HEADERS" frame including the "Digest" header: 2191 :status: 200 2192 content-length: 100 2193 content-type: text/plain 2194 date: Fri, 20 Jan 2017 10:00:00 GMT 2195 digest: SHA-256=DieQ9zfRaDdyAilTVCvmBePuxMm+B6cNocP+QCrNSqo= 2197 HTTP/3 "DATA" frame containing 100 bytes of response body data: 2199 ... 2201 B.2.4. Partial Transfer with Content Integrity and without Authenticity 2203 In this example, partial content is transferred as described in 2204 Section 8. The "Range" request header is used to indicate the 2205 sender's intention to transfer all 100 bytes of the representation. 2206 The "Content-Range" response header indicates that only the first 50 2207 bytes were actually sent. Content integrity is assured by the 2208 inclusion of the "Digest" response header, as described in 2209 Section 6.1. 2211 HTTP/3 "PUSH_PROMISE" frame: 2213 :method: GET 2214 :scheme: https 2215 :path: /files/example.txt 2216 :authority: example.org 2217 range: bytes=0-* 2219 HTTP/3 "HEADERS" frame including the "Digest" header: 2221 :status: 206 2222 content-length: 100 2223 content-range: bytes 0-49/100 2224 content-type: text/plain 2225 date: Fri, 20 Jan 2017 10:00:00 GMT 2226 digest: SHA-256=DieQ9zfRaDdyAilTVCvmBePuxMm+B6cNocP+QCrNSqo= 2228 HTTP/3 "DATA" frame containing 50 bytes of response body data: 2230 ... 2232 B.2.5. Transfer with Content Integrity and Authenticity 2234 In this example, content integrity is assured by the inclusion of the 2235 "Digest" response header, as described in Section 6.1. Content 2236 authenticity is assured separately for the request and the response 2237 messages by the "Signature" header which protects the header fields 2238 described in further detail below. The "Signature" header parameter 2239 "keyId" contains the URL of a file containing the public key related 2240 to the multicast sender's private key used to create the digital 2241 signature. 2243 HTTP/3 "PUSH_PROMISE" frame including a "Signature" header protecting 2244 the ":method" and ":path" (the request target), as well as the 2245 ":scheme" and ":authority" of the pseudo-request: 2247 :method: GET 2248 :scheme: https 2249 :path: /files/example.txt 2250 :authority: example.org 2251 signature: keyId="https://example.org/mcast-sender.example.org.pem", 2252 algorithm=rsa-sha256, 2253 headers="(request-target) :scheme :authority", 2254 signature="MGQCMFTaFptaM2FhgzJq2i9AaChuFDHjp6GiXVtRnI8BsA" 2256 HTTP/3 "HEADERS" frame including a "Signature" header protecting the 2257 ":method", ":path", ":scheme" and ":authority" of the pseudo-request 2258 above, plus the "Date" and "Digest" of the response: 2260 :status: 200 2261 content-length: 100 2262 content-type: text/plain 2263 date: Fri, 20 Jan 2017 10:00:00 GMT 2264 digest: SHA-256=DieQ9zfRaDdyAilTVCvmBePuxMm+B6cNocP+QCrNSqo= 2265 signature: keyId="https://example.org/mcast-sender.example.org.pem", 2266 algorithm=rsa-sha256, 2267 headers="(request-target) :scheme :authority date digest", 2268 signature="MGUCMBgx6cuwTzg0W29zNUra8xfMsEcb3rFA3Y" 2270 HTTP/3 "DATA" frame containing response body data: 2272 ... 2274 B.2.6. Partial Transfer with Content Integrity and Authenticity 2276 In this example, partial content is transferred and the "Range" 2277 header (as described in Section 8) is used to indicate that 50 bytes 2278 out of 100 bytes were transferred. Content integrity is provided by 2279 the inclusion of the "Digest" header, as described in Section 6.1. 2280 Authenticity is provided by the "Signature" header which protects the 2281 header fields described in further detail. The "Signature" header 2282 parameter "keyId" contains the URL of a file containing the public 2283 key related to the multicast sender's private key used to create the 2284 digital signature. 2286 HTTP/3 "PUSH_PROMISE" frame: 2288 :method: GET 2289 :scheme: https 2290 :path: /files/example.txt 2291 :authority: example.org 2292 range: bytes=0-* 2293 signature: keyId="https://example.org/mcast-sender.example.org.pem", 2294 algorithm=rsa-sha256, 2295 headers="(request-target) :scheme :authority range", 2296 signature="MGQCMFTaFptaM2FhgzJq2i9AaChuFDHjp6GiXVtRnI8BsA" 2298 HTTP/3 "HEADERS" frame protecting the ":method", ":path", ":scheme" 2299 and ":authority" of the pseudo-request above, plus the "Date", 2300 "Digest" and "Content-Range" of the response: 2302 :status: 206 2303 content-length: 100 2304 content-range: bytes 0-49/100 2305 content-type: text/plain 2306 date: Fri, 20 Jan 2017 10:00:00 GMT 2307 digest: SHA-256=DieQ9zfRaDdyAilTVCvmBePuxMm+B6cNocP+QCrNSqo= 2308 signature: keyId="https://example.org/mcast-sender.example.org.pem", 2309 algorithm=rsa-sha256, 2310 headers="(request-target) :scheme :authority 2311 date digest content-range", 2312 signature="MGUCMBgx6cuwTzg0W29zNUra8xfMsEcb3rFA3Y" 2314 HTTP/3 "DATA" frame containing response body data: 2316 ... 2318 Appendix C. Summary of differences from unicast QUIC and HTTP/3 2319 +----------------+-----------------------+--------------------------+ 2320 | Protocol | Unicast QUIC | Multicast QUIC profile | 2321 | feature | | | 2322 +----------------+-----------------------+--------------------------+ 2323 | Packet number | QUIC transport | All packets are numbered | 2324 | spaces | packets are seperated | in the application data | 2325 | | into three distinct | packet number space. | 2326 | | packet number spaces: | | 2327 | | initial, handshake | | 2328 | | and application data. | | 2329 | | | | 2330 | Transport | Combined | Not used. | 2331 | handshake | cryptographic and | | 2332 | | transport handshake | | 2333 | | stream conveying TLS | | 2334 | | handshake messages in | | 2335 | | QUIC Initial and | | 2336 | | Handshake packets. | | 2337 | | | | 2338 | TLS cipher | Client's preferred | Cipher suite optionally | 2339 | suite | cipher suite included | advertised out of band | 2340 | | in Client Hello | via Alt-Svc "cipher- | 2341 | | message. | suite" parameter. | 2342 | | | Default cipher suite is | 2343 | | | "0x00,0x00 | 2344 | | | (NULL_WITH_NULL_NULL)". | 2345 | | | | 2346 | TLS session | Session key included | Session key optionally | 2347 | key | in Server Hello | advertised out of band | 2348 | | message. | via Alt-Svc "key" | 2349 | | | parameter. | 2350 | | | | 2351 | TLS | Initialization vector | Initialization vector | 2352 | initialization | included in Server | optionally advertised | 2353 | vector | Hello message. | out of band via Alt-Svc | 2354 | | | "iv" parameter. | 2355 +----------------+-----------------------+--------------------------+ 2357 Table 1: Cryptography and Transport 2359 +----------------------------+----------------+---------------------+ 2360 | Protocol feature | Unicast QUIC | Multicast QUIC | 2361 | | | profile | 2362 +----------------------------+----------------+---------------------+ 2363 | "initial_max_data" | Connection- | Not used. Peak flow | 2364 | | level flow | rate of a session | 2365 | | control window | optionally | 2366 | | size. | advertised out of | 2367 | | | band via Alt-Svc | 2368 | | | "peak-flow-rate" | 2369 | | | parameter. | 2370 | | | | 2371 | "initial_max_stream_data_b | Locally- | Not used. No | 2372 | idi_local" | initiated | bidirectional | 2373 | | bidirectional | streams in this | 2374 | | stream flow | profile. | 2375 | | control window | | 2376 | | size. | | 2377 | | | | 2378 | "initial_max_stream_data_b | Remotely- | Not used. No | 2379 | idi_remote" | initiated | bidirectional | 2380 | | bidirectional | streams in this | 2381 | | stream flow | profile. | 2382 | | control window | | 2383 | | size. | | 2384 | | | | 2385 | "initial_max_stream_data_u | Unidirectional | Not used. Peak flow | 2386 | ni" | stream flow | rate of a session | 2387 | | control window | optionally | 2388 | | size. | advertised out of | 2389 | | | band via Alt-Svc | 2390 | | | "peak-flow-rate | 2391 | | | parameter". | 2392 | | | | 2393 | "initial_max_streams_bidi" | Maximum stream | Not used. Maximum | 2394 | and | concurrency. | concurrent | 2395 | "initial_max_streams_uni" | | resources in a | 2396 | | | session optionally | 2397 | | | advertised out of | 2398 | | | band via Alt-Svc | 2399 | | | "max-concurrent- | 2400 | | | resources" | 2401 | | | parameter. | 2402 +----------------------------+----------------+---------------------+ 2404 Table 2: Required Transport Parameters 2406 +------------------------+------------------+-----------------------+ 2407 | Protocol feature | Unicast QUIC | Multicast QUIC | 2408 | | | profile | 2409 +------------------------+------------------+-----------------------+ 2410 | "original_connection_i | The value of the | Not used. No client | 2411 | d" | Destination | interaction. | 2412 | | Connection ID | | 2413 | | field from the | | 2414 | | first Initial | | 2415 | | packet sent by | | 2416 | | the client. | | 2417 | | | | 2418 | "idle_timeout" | How long to keep | Not used. Advertised | 2419 | | an idle | out of band via Alt- | 2420 | | connection open | Svc "session-idle- | 2421 | | for before | timeout" parameter; | 2422 | | closing. Takes a | defaults to 0 (never | 2423 | | default of 0 | close on idle) if not | 2424 | | (never close on | specified. | 2425 | | idle) if not | | 2426 | | specified. | | 2427 | | | | 2428 | "stateless_reset_token | Used in | Not used. Stateless | 2429 | " | verifying a | reset is not used by | 2430 | | stateless reset. | this profile. | 2431 | | | | 2432 | "max_packet_size" | Limit of the | Not used. Maximum | 2433 | | size of packets | packet size for a | 2434 | | that an endpoint | session optionally | 2435 | | is willing to | advertised out of | 2436 | | receive. | band via Alt-Svc | 2437 | | | "max-packet-size" | 2438 | | | parameter. | 2439 | | | | 2440 | "ack_delay_exponent" | The exponent | Not used. "ACK" | 2441 | | used to decode | frames are prohibited | 2442 | | the ACK Delay | by this profile. | 2443 | | field in the | | 2444 | | "ACK" frame. | | 2445 | | | | 2446 | "max_ack_delay" | Maximum time in | Not used. "ACK" | 2447 | | milliseconds by | frames are prohibited | 2448 | | which an | by this profile. | 2449 | | endpoint will | | 2450 | | delay sending ac | | 2451 | | knowledgements. | | 2452 | | | | 2453 | "disable_migration" | Signals if an | Not used. Session | 2454 | | endpoint does | migration not | 2455 | | not support | currently supported | 2456 | | connection | by this profile. | 2457 | | migration. | | 2458 | | | | 2459 | "preferred_address" | Used to effect a | Not used. No | 2460 | | change in server | handshake in this | 2461 | | address at the | profile. | 2462 | | end of the | | 2463 | | handshake. | | 2464 +------------------------+------------------+-----------------------+ 2466 Table 3: Optional Transport Parameters 2468 +-------------+---------------------+-------------------------------+ 2469 | Protocol | Unicast QUIC | Multicast QUIC profile | 2470 | feature | | | 2471 +-------------+---------------------+-------------------------------+ 2472 | Maximum | Determined by path | Determined by path MTU | 2473 | packet size | MTU discovery or | discovery or other heuristic. | 2474 | | other heuristic. | | 2475 | | | | 2476 | Long header | Used for packets | Prohibited. | 2477 | packet | that are sent prior | | 2478 | | to the completion | | 2479 | | of version | | 2480 | | negotiation and | | 2481 | | before packet | | 2482 | | protection keys are | | 2483 | | established. | | 2484 | | | | 2485 | Version | Protocol version | Not permitted. Protocol | 2486 | negotiation | negotiation between | version advertised out of | 2487 | packet | initiating client | band via Alt-Svc "quic" | 2488 | | and server. | parameter. | 2489 | | | | 2490 | Stateless | Used by a peer to | Not permitted. (Potential | 2491 | reset | terminate a | denial-of-service attack | 2492 | packet | connection that has | vector.) | 2493 | | become unusable. | | 2494 | | | | 2495 | Short | Used for packets | Used to convey QUIC frames | 2496 | header | that are sent once | (see below). | 2497 | packet | a connection has | | 2498 | | been established. | | 2499 | | Used to convey QUIC | | 2500 | | frames (see below). | | 2501 | | | | 2502 | Source | Connection IDs | Source Connection ID not | 2503 | Connection | negotiated between | used. Destination Connection | 2504 | ID field, | client and server | ID redefined to be a | 2505 | Destination | during handshake | Multicast Session ID which is | 2506 | Connection | and may be changed | optionally advertised out of | 2507 | ID field | subsequently using | band via the Alt-Svc | 2508 | | the | "session-id" parameter. May | 2509 | | "NEW_CONNECTION_ID" | be omitted from packets if | 2510 | | frame. | the address/port tuple is | 2511 | | | sufficient to identify the | 2512 | | | session, in which case it is | 2513 | | | not advertised. | 2514 +-------------+---------------------+-------------------------------+ 2516 Table 4: QUIC Packet Layer 2518 +------------------------+----------------------+---------------------+ 2519 | Protocol feature | Unicast QUIC | Multicast QUIC | 2520 | | | profile | 2521 +------------------------+----------------------+---------------------+ 2522 | "PADDING" frame | Used to pad out a | Permitted, but | 2523 | | QUIC packet with | wasteful of network | 2524 | | zero bytes. (The | capacity. | 2525 | | first packet sent on | | 2526 | | a connection must be | | 2527 | | at least 1200 bytes | | 2528 | | long to prove that | | 2529 | | the network can | | 2530 | | transmit packets of | | 2531 | | at least this size.) | | 2532 | | | | 2533 | "PING" frame | Used by an endpoint | Used by the | 2534 | | to verify that its | multicast sender as | 2535 | | peer is still alive. | a session keep- | 2536 | | Acknowledged using a | alive notification. | 2537 | | regular "ACK" frame. | Never acknowledged. | 2538 | | | | 2539 | "ACK" frame | Used by a receiver | Both "ACK" frame | 2540 | | to acknowledge | types are | 2541 | | receipt of data from | prohibited. | 2542 | | its peer. | | 2543 | | | | 2544 | "RESET_STREAM" frame | Request by receiver | Indication to | 2545 | | for sender to | receivers that the | 2546 | | terminate a stream | multicast sender | 2547 | | transmission | has prematurely | 2548 | | prematurely. | terminated a stream | 2549 | | | transmission. | 2550 | | | Prohibited for | 2551 | | | receivers to send. | 2552 | | | | 2553 | "STOP_SENDING" frame | Flow control back | Prohibited. | 2554 | | pressure. Used to | | 2555 | | signal to a peer | | 2556 | | that incoming data | | 2557 | | on a stream is being | | 2558 | | discarded on receipt | | 2559 | | at the application's | | 2560 | | request. This | | 2561 | | abruptly terminates | | 2562 | | a stream. | | 2563 | | | | 2564 | "CRYPTO" frame | Used to transmit | Prohibited. | 2565 | | cryptographic | | 2566 | | handshake messages. | | 2567 | | | | 2568 | "NEW_TOKEN" frame | Used by a server to | Prohibited. Session | 2569 | | supply a token to | migration not | 2570 | | its client to be | currently supported | 2571 | | sent in the header | by this profile. | 2572 | | of an initial packet | | 2573 | | for a future | | 2574 | | connection. Used to | | 2575 | | facilitate | | 2576 | | connection | | 2577 | | migration. | | 2578 | | | | 2579 | "STREAM" frame | Conveys application- | Conveys | 2580 | | layer payloads (see | application-layer | 2581 | | HTTP/3 mapping | payloads (see | 2582 | | below). | HTTP/3 mapping | 2583 | | | below). | 2584 | | | | 2585 | "FIN" bit on "STREAM" | Indication by sender | Indication by the | 2586 | frame | to its peer that a | multicast sender | 2587 | | stream transmission | that a stream | 2588 | | has finished. | transmission has | 2589 | | | finished. | 2590 | | | | 2591 | "MAX_DATA" frame | Flow control update | Prohibited. | 2592 | | notification. | | 2593 | | | | 2594 | "MAX_STREAM_DATA" | Flow control update | Prohibited. | 2595 | frame | notification. | | 2596 | | | | 2597 | "MAX_STREAMS" frame | Used by an endpoint | Prohibited. | 2598 | | to inform a peer of | | 2599 | | the maximum stream | | 2600 | | ID that it is | | 2601 | | permitted to open. | | 2602 | | | | 2603 | "DATA_BLOCKED" frame | Notification to | Prohibited. | 2604 | | receiver that | | 2605 | | sender's | | 2606 | | transmission is | | 2607 | | blocked pending an | | 2608 | | update to its flow | | 2609 | | control window by | | 2610 | | peer. | | 2611 | | | | 2612 | "STREAM_DATA_BLOCKED" | Notification to | Prohibited. | 2613 | frame | receiver that | | 2614 | | sender's | | 2615 | | transmission of a | | 2616 | | single stream is | | 2617 | | blocked pending an | | 2618 | | update to its flow | | 2619 | | control window by | | 2620 | | peer. | | 2621 | | | | 2622 | "STREAMS_BLOCKED" | Notification to | Prohibited. | 2623 | frames | receiver that the | | 2624 | | sender wishes to | | 2625 | | open a stream but is | | 2626 | | unable to do so | | 2627 | | because the maximum | | 2628 | | stream ID has been | | 2629 | | reached for a given | | 2630 | | stream type. | | 2631 | | | | 2632 | "NEW_CONNECTION_ID" | Used to provide a | Prohibited. Session | 2633 | frame | peer with | migration not | 2634 | | alternative | currently supported | 2635 | | connection IDs that | by this profile. | 2636 | | can be used to break | | 2637 | | linkability when | | 2638 | | migrating | | 2639 | | connections. | | 2640 | | | | 2641 | "RETIRE_CONNECTION_ID" | Indicates that an | Prohibited. Session | 2642 | frame | endpoint will no | migration not | 2643 | | longer use a | currently supported | 2644 | | connection ID that | by this profile. | 2645 | | was issued by its | | 2646 | | peer. | | 2647 | | | | 2648 | "PATH_CHALLENGE" frame | Used to check | Prohibited. | 2649 | | reachability to a | | 2650 | | peer and for path | | 2651 | | validation during | | 2652 | | connection | | 2653 | | migration. | | 2654 | | | | 2655 | "PATH_RESPONSE" frame | Sent in response to | Prohibited. | 2656 | | a "PATH_CHALLENGE" | | 2657 | | frame. | | 2658 | | | | 2659 | "CONNECTION_CLOSE" | Notification (by | Prohibited. Use | 2660 | frame | either peer) of | HTTP explicit | 2661 | | graceful connection | session tear-down | 2662 | | shutdown. | instead (see | 2663 | | | Section 5.5). | 2664 +------------------------+----------------------+---------------------+ 2666 Table 5: QUIC Framing Layer 2668 +------------------+------------------+-----------------------------+ 2669 | Protocol feature | Unicast HTTP/3 | Multicast HTTP/3 profile | 2670 +------------------+------------------+-----------------------------+ 2671 | Stream Type | Type of | Only Server Push type is | 2672 | | unidirectional | permitted. | 2673 | | stream. | | 2674 | | | | 2675 | Push ID | Identifies a | Identifies a promised | 2676 | | promised | resource conveyed in an | 2677 | | resource | earlier "PUSH_PROMISE" | 2678 | | conveyed in an | frame. | 2679 | | earlier | | 2680 | | "PUSH_PROMISE" | | 2681 | | frame. | | 2682 | | | | 2683 | "DATA" frame | Carriage of HTTP | Carriage of HTTP response | 2684 | | request/response | message body. | 2685 | | message body. | | 2686 | | | | 2687 | "HEADERS" frame | Carriage of HTTP | Carriage of HTTP response | 2688 | | request/response | message metadata. Trailing | 2689 | | message | "HEADERS" frame is | 2690 | | metadata. | permitted. | 2691 | | Trailing | | 2692 | | "HEADERS" frame | | 2693 | | is permitted. | | 2694 | | | | 2695 | "PRIORITY" frame | Dynamic | Prohibited. | 2696 | | adjustment of | | 2697 | | stream priority. | | 2698 | | | | 2699 | "CANCEL_PUSH" | Used to request | Permitted only for senders. | 2700 | frame | cancellation of | | 2701 | | server push | | 2702 | | prior to the | | 2703 | | push stream | | 2704 | | being created. | | 2705 | | | | 2706 | "SETTINGS" frame | Negotiation of | Prohibited. | 2707 | | HTTP/3 | | 2708 | | connection | | 2709 | | settings. | | 2710 | | | | 2711 | "PUSH_PROMISE" | Carriage of HTTP | Carriage of HTTP pseudo- | 2712 | frame | pseudo-request | request message metadata. | 2713 | | message | All HTTP representation | 2714 | | metadata. | transfers over multicast | 2715 | | | begin this way. Stream ID | 2716 | | | of the first client- | 2717 | | | initiated bidirectional | 2718 | | | stream is reserved and all | 2719 | | | "PUSH_PROMISE" frames | 2720 | | | reference this as the | 2721 | | | client request from which | 2722 | | | they are notionally | 2723 | | | derived. This stream | 2724 | | | remains open while a sender | 2725 | | | is participating in the | 2726 | | | multicast QUIC session. | 2727 | | | | 2728 | "GOAWAY" frame | Early | Prohibited. Use HTTP | 2729 | | notification (by | explicit session tear-down | 2730 | | either endpoint) | instead. | 2731 | | of future | | 2732 | | connection | | 2733 | | closure, | | 2734 | | allowing for | | 2735 | | orderly | | 2736 | | completion of | | 2737 | | open streams. | | 2738 | | | | 2739 | "MAX_PUSH_ID" | Used by a | Prohibited. | 2740 | frame | receiver to | | 2741 | | control the | | 2742 | | number of server | | 2743 | | pushes that a | | 2744 | | sender can | | 2745 | | initiate. | | 2746 | | | | 2747 | "DUPLICATE_PUSH" | Used by servers | Prohibited. | 2748 | frame | to indicate that | | 2749 | | an existing | | 2750 | | pushed resource | | 2751 | | is related to | | 2752 | | multiple client | | 2753 | | requests. | | 2754 | | | | 2755 | "ALTSVC" HTTP/2 | Signalling | Prohibited. | 2756 | extension frame | alternative | | 2757 | | service for | | 2758 | | HTTP/3 session. | | 2759 | | | | 2760 | Other HTTP/2 | | Prohibited. | 2761 | extension frames | | | 2762 +------------------+------------------+-----------------------------+ 2764 Table 6: HTTP/3 Mapping 2766 +-------------+----------------------------------+------------------+ 2767 | Protocol | Unicast HTTP/3 | Multicast HTTP/3 | 2768 | feature | | profile | 2769 +-------------+----------------------------------+------------------+ 2770 | Huffman | Header blocks may use Huffman | Header blocks | 2771 | string | codes to compress literal string | may use Huffman | 2772 | compression | values. | codes to | 2773 | | | compress literal | 2774 | | | string values. | 2775 | | | | 2776 | Static | Header blocks may refer to | Header blocks | 2777 | table | indexed entries in the static | may refer to | 2778 | | table. | indexed entries | 2779 | | | in the static | 2780 | | | table. | 2781 | | | | 2782 | Dynamic | Header blocks may insert entries | Prohibited, size | 2783 | table | into the dynamic table and | is currently | 2784 | | subsequent header blocks may | locked to 0. | 2785 | | refer to their indexes. Unused | | 2786 | | as size is currently locked to | | 2787 | | 0. | | 2788 +-------------+----------------------------------+------------------+ 2790 Table 7: HTTP Metadata Compression Layer 2792 Appendix D. Changelog 2794 *RFC Editor's Note:* Please remove this section prior to 2795 publication of a final version of this document. 2797 D.1. Since draft-pardue-quic-http-mcast-04 2799 o Update references to QUIC I-Ds, remove QUIC-SPIN. (draft-ietf- 2800 quic-transport-20) 2802 o Update session ID length to match new connection ID length. 2803 (draft-ietf-quic-transport-22) 2805 o Clarify the mapping for the new "active_connection_id_limit" 2806 session parameter. (draft-ietf-quic-transport-21) 2808 o Update text to conform with latest version negotiation text from 2809 [QUIC-TRANSPORT]. 2811 o Update stream types for server push in accordance with draft-ietf- 2812 quic-http-19. 2814 o Fix some idnits warnings to do with line lengths in Alt-Svc 2815 examples. 2817 o Update IPv6 informative reference to RFC 8200 as it obsoletes RFC 2818 2460. 2820 o Clarify difference between connection and session migration. 2822 o Move GOAWAY frame to HTTP/3 profile. 2824 o Renamed Session Shutdown to Connection Shutdown to mirror concept 2825 in [QUIC-TRANSPORT]. 2827 o Clarify the layer of each frame type when referred to. 2829 D.2. Since draft-pardue-quic-http-mcast-03 2831 o Update references to QUIC I-Ds. 2833 o Change crypto handshake text now that it's no longer done on 2834 Stream ID 0. 2836 o Update to reference Source and Destination Connection IDs. 2838 o Prohibit the use of connection coalescing, migration and ECN. 2840 o Update allowed and disallowed packets and frames to match the core 2841 specs. 2843 o Remove references to the PONG frame. (draft-ietf-quic-transport- 2844 10) 2846 o Change HTTP/QUIC to HTTP/3. (draft-ietf-quic-http-17) 2848 o Change HPACK to QPACK. (draft-ietf-quic-http-10) 2850 o Prohibit the DUPLICATE_PUSH frame. 2852 o Clarify packet number space (only use application data space, not 2853 initial or handshake). 2855 o Add statement on QUIC latency spin bit. 2857 o Removed sentence stating that multiple Connection IDs cannot be 2858 used concurrently in a unicast QUIC session, in accordance with 2859 [QUIC-TRANSPORT] section 5.1.2. 2861 D.3. Since draft-pardue-quic-http-mcast-02 2863 o No changes. 2865 D.4. Since draft-pardue-quic-http-mcast-01 2867 o Explicit guidance on maximum stream ID value permitted. 2869 o Updated guidance on PING (and PONG) frame. 2871 o Added a comparison table to appendix. 2873 o Remove invalid use of trailing headers. 2875 o Use the new HTTP/QUIC DATA frame. 2877 o Prohibit APPLICATION CLOSE frame, and move GOAWAY frame to HTTP/ 2878 QUIC section. 2880 o Redefine server push to reflect core document changes. 2882 o Remove default idle time out value. 2884 o Clarify session parameter requirements (session-idle-timeout 2885 became mandatory). 2887 o Update frame notation convention. 2889 D.5. Since draft-pardue-quic-http-mcast-00 2891 o Update references to QUIC I-Ds. 2893 o Relax session leaving requirements language. 2895 o Clarify handling of omitted session parameter advertisements. 2897 o Rename "Idle" state to "Quiescent". 2899 o Add digest algorithm session parameter. 2901 o Add signature algorithm session parameter. 2903 o Add Initialization Vector session parameter. 2905 o Replace COPT tag-value-pairs with TransportParameter values. 2907 o Add example of an advertisement for a session with content 2908 authenticity and integrity. 2910 Authors' Addresses 2912 Lucas Pardue 2914 Email: lucaspardue.24.7@gmail.com 2916 Richard Bradbury 2917 BBC Research & Development 2919 Email: richard.bradbury@bbc.co.uk 2921 Sam Hurst 2922 BBC Research & Development 2924 Email: sam.hurst@bbc.co.uk