idnits 2.17.1 draft-pardue-quic-http-mcast-02.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 2 instances of too long lines in the document, the longest one being 8 characters in excess of 72. == There are 1 instance of lines with multicast IPv4 addresses in the document. If these are generic example addresses, they should be changed to use the 233.252.0.x range defined in RFC 5771 Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year == The document seems to lack the recommended RFC 2119 boilerplate, even if it appears to use RFC 2119 keywords -- however, there's a paragraph with a matching beginning. Boilerplate error? (The document does seem to have the reference to RFC 2119 which the ID-Checklist requires). -- The document date (February 2, 2018) is 2272 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-09 == Outdated reference: A later version (-34) exists of draft-ietf-quic-http-09 == Outdated reference: A later version (-34) exists of draft-ietf-quic-transport-09 ** 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-09 == Outdated reference: A later version (-34) exists of draft-ietf-quic-tls-09 -- Obsolete informational reference (is this intentional?): RFC 2460 (Obsoleted by RFC 8200) -- Obsolete informational reference (is this intentional?): RFC 4566 (Obsoleted by RFC 8866) Summary: 6 errors (**), 0 flaws (~~), 8 warnings (==), 3 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Network Working Group L. Pardue 3 Internet-Draft R. Bradbury 4 Intended status: Informational BBC Research & Development 5 Expires: August 6, 2018 February 2, 2018 7 Hypertext Transfer Protocol (HTTP) over multicast QUIC 8 draft-pardue-quic-http-mcast-02 10 Abstract 12 This document specifies a profile of the QUIC protocol and the HTTP/ 13 QUIC mapping that facilitates the transfer of HTTP resources over 14 multicast IP using the QUIC transport as its framing and 15 packetisation layer. Compatibility with the QUIC protocol's syntax 16 and semantics is maintained as far as practical and additional 17 features are specified where this is not possible. 19 Status of This Memo 21 This Internet-Draft is submitted in full conformance with the 22 provisions of BCP 78 and BCP 79. 24 Internet-Drafts are working documents of the Internet Engineering 25 Task Force (IETF). Note that other groups may also distribute 26 working documents as Internet-Drafts. The list of current Internet- 27 Drafts is at http://datatracker.ietf.org/drafts/current/. 29 Internet-Drafts are draft documents valid for a maximum of six months 30 and may be updated, replaced, or obsoleted by other documents at any 31 time. It is inappropriate to use Internet-Drafts as reference 32 material or to cite them other than as "work in progress." 34 This Internet-Draft will expire on August 6, 2018. 36 Copyright Notice 38 Copyright (c) 2018 IETF Trust and the persons identified as the 39 document authors. All rights reserved. 41 This document is subject to BCP 78 and the IETF Trust's Legal 42 Provisions Relating to IETF Documents 43 (http://trustee.ietf.org/license-info) in effect on the date of 44 publication of this document. Please review these documents 45 carefully, as they describe your rights and restrictions with respect 46 to this document. Code Components extracted from this document must 47 include Simplified BSD License text as described in Section 4.e of 48 the Trust Legal Provisions and are provided without warranty as 49 described in the Simplified BSD License. 51 Table of Contents 53 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 4 54 1.1. Notational Conventions . . . . . . . . . . . . . . . . . 6 55 1.2. Definitions . . . . . . . . . . . . . . . . . . . . . . . 6 56 2. Multicast QUIC Sessions . . . . . . . . . . . . . . . . . . . 7 57 2.1. Session States . . . . . . . . . . . . . . . . . . . . . 7 58 2.1.1. Session Establishment . . . . . . . . . . . . . . . . 8 59 2.1.2. Session Termination . . . . . . . . . . . . . . . . . 8 60 2.1.3. Session Migration . . . . . . . . . . . . . . . . . . 9 61 2.2. Session Parameters . . . . . . . . . . . . . . . . . . . 9 62 2.3. Session Identification . . . . . . . . . . . . . . . . . 10 63 2.4. Session Security . . . . . . . . . . . . . . . . . . . . 10 64 3. Session Advertisement . . . . . . . . . . . . . . . . . . . . 11 65 3.1. Version Advertisement . . . . . . . . . . . . . . . . . . 11 66 3.2. Security Context . . . . . . . . . . . . . . . . . . . . 12 67 3.2.1. Cipher Suite . . . . . . . . . . . . . . . . . . . . 12 68 3.2.2. Key Exchange . . . . . . . . . . . . . . . . . . . . 13 69 3.2.3. Initialization Vector . . . . . . . . . . . . . . . . 13 70 3.3. Session Identification . . . . . . . . . . . . . . . . . 13 71 3.4. Session Idle Timeout . . . . . . . . . . . . . . . . . . 13 72 3.5. Session Peak Flow Rate . . . . . . . . . . . . . . . . . 14 73 3.6. Resource Concurrency . . . . . . . . . . . . . . . . . . 14 74 3.7. Additional TransportParameter Considerations . . . . . . 15 75 3.8. Digest Algorithm . . . . . . . . . . . . . . . . . . . . 15 76 3.9. Signature Algorithm . . . . . . . . . . . . . . . . . . . 16 77 4. QUIC Profile . . . . . . . . . . . . . . . . . . . . . . . . 17 78 4.1. Packet Size . . . . . . . . . . . . . . . . . . . . . . . 17 79 4.2. Packet Format . . . . . . . . . . . . . . . . . . . . . . 17 80 4.3. Connection Identifier . . . . . . . . . . . . . . . . . . 18 81 4.4. Stream Identifier . . . . . . . . . . . . . . . . . . . . 18 82 4.5. Flow Control . . . . . . . . . . . . . . . . . . . . . . 18 83 4.6. Stream Termination . . . . . . . . . . . . . . . . . . . 18 84 4.7. Session Shutdown . . . . . . . . . . . . . . . . . . . . 19 85 4.8. Session Keep-alive . . . . . . . . . . . . . . . . . . . 19 86 4.9. Loss Detection and Recovery . . . . . . . . . . . . . . . 19 87 4.10. Prohibited QUIC Frames and Packets . . . . . . . . . . . 20 88 5. HTTP/QUIC Profile . . . . . . . . . . . . . . . . . . . . . . 20 89 5.1. HTTP Connection Settings . . . . . . . . . . . . . . . . 20 90 5.2. Server Push . . . . . . . . . . . . . . . . . . . . . . . 21 91 5.3. Metadata Compression . . . . . . . . . . . . . . . . . . 21 92 5.4. Prioritisation . . . . . . . . . . . . . . . . . . . . . 22 93 5.5. Session Tear-down . . . . . . . . . . . . . . . . . . . . 22 94 5.6. HTTP/QUIC Extension frames . . . . . . . . . . . . . . . 22 95 5.7. Prohibited HTTP/QUIC Frames . . . . . . . . . . . . . . . 22 97 6. Application-Layer Security . . . . . . . . . . . . . . . . . 23 98 6.1. Content Integrity . . . . . . . . . . . . . . . . . . . . 23 99 6.2. Content Authenticity . . . . . . . . . . . . . . . . . . 23 100 6.3. Content Confidentiality . . . . . . . . . . . . . . . . . 25 101 7. Loss Recovery . . . . . . . . . . . . . . . . . . . . . . . . 25 102 7.1. Forward Error Correction . . . . . . . . . . . . . . . . 25 103 7.2. Unicast Repair . . . . . . . . . . . . . . . . . . . . . 25 104 8. Transmission of Partial Content . . . . . . . . . . . . . . . 26 105 9. Protocol Identifier . . . . . . . . . . . . . . . . . . . . . 26 106 9.1. Draft Version Identification . . . . . . . . . . . . . . 26 107 10. Discovery of Multicast QUIC Sessions . . . . . . . . . . . . 27 108 10.1. Source-specific Multicast Advertisement . . . . . . . . 28 109 10.2. Session Parameter Advertisement . . . . . . . . . . . . 28 110 10.2.1. Version . . . . . . . . . . . . . . . . . . . . . . 28 111 10.2.2. Cipher Suite . . . . . . . . . . . . . . . . . . . . 28 112 10.2.3. Session Key . . . . . . . . . . . . . . . . . . . . 29 113 10.2.4. Session Cipher Initialization Vector . . . . . . . . 29 114 10.2.5. Session Identification . . . . . . . . . . . . . . . 29 115 10.2.6. Session Idle Timeout Period . . . . . . . . . . . . 30 116 10.2.7. Resource Concurrency . . . . . . . . . . . . . . . . 30 117 10.2.8. Session Peak Flow Rate . . . . . . . . . . . . . . . 30 118 10.2.9. Digest Algorithm . . . . . . . . . . . . . . . . . . 31 119 10.2.10. Signature Algorithm . . . . . . . . . . . . . . . . 31 120 11. Security and Privacy Considerations . . . . . . . . . . . . . 32 121 11.1. Pervasive Monitoring . . . . . . . . . . . . . . . . . . 32 122 11.1.1. Large-scale Data Gathering and Correlation . . . . . 32 123 11.1.2. Changing Content . . . . . . . . . . . . . . . . . . 33 124 11.2. Protection of Discovery Mechanism . . . . . . . . . . . 33 125 11.3. Spoofing . . . . . . . . . . . . . . . . . . . . . . . . 33 126 11.3.1. Spoofed Ack Attacks . . . . . . . . . . . . . . . . 33 127 11.3.2. Sender Spoofing . . . . . . . . . . . . . . . . . . 33 128 11.3.3. Receiver Spoofing . . . . . . . . . . . . . . . . . 34 129 11.4. Replay Attacks . . . . . . . . . . . . . . . . . . . . . 34 130 11.5. Message Deletion . . . . . . . . . . . . . . . . . . . . 34 131 11.6. Denial of Service . . . . . . . . . . . . . . . . . . . 34 132 11.6.1. Unprotected Frames and Packets . . . . . . . . . . . 35 133 11.6.2. Network Performance Degradation . . . . . . . . . . 35 134 11.6.3. Unicast Repair Stampeding Herd . . . . . . . . . . . 35 135 11.7. Receiver Resource Usage . . . . . . . . . . . . . . . . 35 136 11.8. Unicast Repair Information Leakage . . . . . . . . . . . 35 137 12. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 36 138 12.1. Registration of Protocol Identification String . . . . . 36 139 12.2. Registration of Alt-Svc parameters . . . . . . . . . . . 36 140 12.2.1. Source Address . . . . . . . . . . . . . . . . . . . 37 141 12.2.2. Cipher Suite . . . . . . . . . . . . . . . . . . . . 37 142 12.2.3. Key . . . . . . . . . . . . . . . . . . . . . . . . 37 143 12.2.4. Initialization Vector . . . . . . . . . . . . . . . 37 144 12.2.5. Session Identifier . . . . . . . . . . . . . . . . . 37 145 12.2.6. Session Idle Timeout . . . . . . . . . . . . . . . . 37 146 12.2.7. Maximum Concurrent Resources . . . . . . . . . . . . 37 147 12.2.8. Peak Flow Rate . . . . . . . . . . . . . . . . . . . 38 148 12.2.9. Digest Algorithm . . . . . . . . . . . . . . . . . . 38 149 12.2.10. Signature Algorithm . . . . . . . . . . . . . . . . 38 150 13. References . . . . . . . . . . . . . . . . . . . . . . . . . 38 151 13.1. Normative References . . . . . . . . . . . . . . . . . . 38 152 13.2. Informative References . . . . . . . . . . . . . . . . . 39 153 Appendix A. Acknowledgements . . . . . . . . . . . . . . . . . . 41 154 Appendix B. Examples . . . . . . . . . . . . . . . . . . . . . . 42 155 B.1. Session Advertisement . . . . . . . . . . . . . . . . . . 42 156 B.1.1. Source-specific Multicast QUIC Session . . . . . . . 42 157 B.1.2. Source-specific Multicast QUIC Session with Transport 158 Encryption using a Symmetric Key . . . . . . . . . . 42 159 B.1.3. Source-specific Multicast QUIC Session with Transport 160 Encryption, Content Integrity and Authenticity . . . 43 161 B.2. Resource Transfer . . . . . . . . . . . . . . . . . . . . 43 162 B.2.1. Transfer without Content Integrity or Authenticity . 43 163 B.2.2. Transfer of Partial Content without Content Integrity 164 or Authenticity . . . . . . . . . . . . . . . . . . . 44 165 B.2.3. Transfer with Content Integrity and without 166 Authenticity . . . . . . . . . . . . . . . . . . . . 44 167 B.2.4. Partial Transfer with Content Integrity and without 168 Authenticity . . . . . . . . . . . . . . . . . . . . 45 169 B.2.5. Transfer with Content Integrity and Authenticity . . 45 170 B.2.6. Partial Transfer with Content Integrity and 171 Authenticity . . . . . . . . . . . . . . . . . . . . 46 172 Appendix C. Summary of differences from unicast QUIC and 173 HTTP/QUIC . . . . . . . . . . . . . . . . . . . . . 47 174 Appendix D. Changelog . . . . . . . . . . . . . . . . . . . . . 54 175 D.1. Since draft-pardue-quic-http-mcast-01 . . . . . . . . . . 54 176 D.2. Since draft-pardue-quic-http-mcast-00 . . . . . . . . . . 55 177 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 55 179 1. Introduction 181 The means to bulk transfer resources over multicast IP [RFC1112] 182 using HTTP semantics presents an opportunity to more efficiently 183 deliver services at scale, while leveraging the wealth of existing 184 HTTP-related standards, tools and applications. Audio-visual 185 segmented media, in particular, would benefit from this mode of 186 transmission. 188 The carriage of HTTP over multicast IP may be satisfied using 189 existing technologies, for example the Real-time Transport Protocol 190 (RTP) [RFC3550]. However, such protocols typically require the 191 translation or encapsulation of HTTP. This introduces concerns for 192 providers of services, such as defining the translation, additional 193 workload, complication of workflows, manageability issues, versioning 194 issues, and so on. 196 In contrast, this document describes a simpler and more direct 197 expression of HTTP semantics over multicast IP. HTTP over multicast 198 QUIC is a profile of the QUIC protocol [QUIC-TRANSPORT] (Section 4) 199 and the HTTP/QUIC mapping [QUIC-HTTP] (Section 5). This includes the 200 repurposing of certain QUIC packet fields and changes to some 201 protocol procedures (e.g. prohibition of the usage of certain frame 202 types) which, in turn, change the behavioural expectations of 203 endpoints. However, the profile purposely limits the scope of change 204 in order to preserve maximum compatibility with conventional QUIC. 205 For the reader's convenience, the differences between this 206 specification and conventional QUIC are summarised in Appendix C. 208 This profile prohibits the transmission of QUIC packets from receiver 209 to sender via multicast IP. The use of side-channel or out-of-band 210 feedback mechanisms is not prohibited by this specification, but is 211 out of scope and these are not considered further by the present 212 document. 214 Experience indicates that a generally available multicast deployment 215 is difficult to achieve on the Internet notwithstanding the 216 improvements that IPv6 [RFC2460] makes in this area. There is 217 evidence that discretely referenced multicast "islands" can more 218 pragmatically be deployed. Discovery of such islands by receivers, 219 as they become available, is typically difficult, however. To 220 address the problem, this document describes an HTTP-based discovery 221 mechanism that uses HTTP Alternative Services [RFC7838] to advertise 222 the existence of multicast QUIC sessions (Section 3). This provides 223 the means for multicast-capable endpoints to learn about and make use 224 of them in an opportunistic and user-imperceptible manner. This 225 mechanism results in a common HTTP application layer for both the 226 discovery and delivery of services across unicast and multicast 227 networks. This provides support for users and devices accessing 228 services over a heterogeneous network. This is a departure from 229 conventional multicast discovery technologies such as SDP [RFC4566] 230 and SAP [RFC2974]. 232 The discovery mechanism also addresses some of the issues related to 233 using QUIC over a unidirectional network association by replacing 234 connection establishment aspects that depend on a bidirectional 235 transport. 237 The present document includes a number of optional features. It is 238 anticipated that further specifications will define interoperability 239 profiles suited to particular application domains. 241 1.1. Notational Conventions 243 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 244 "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and 245 "OPTIONAL" in this document are to be interpreted as described in BCP 246 14 [RFC2119] [RFC8174] when, and only when, they appear in all 247 captials, as shown here. 249 This document uses the Augmented BNF defined in [RFC5234] and updated 250 by [RFC7405] along with the "#rule" extension defined in Section 7 of 251 [RFC7230]. The rules below are defined in [RFC5234], [RFC7230], and 252 [RFC7234]: 254 o quoted-string = 256 o token = 258 o uri-host = 260 1.2. Definitions 262 Definitions of terms that are used in this document: 264 o endpoint: A host capable of being a participant in a multicast 265 QUIC session. 267 o multicast QUIC session: A logical unidirectional flow of metadata 268 and data over multicast IP, framed according to this 269 specification. The lifetime of a session is independent of any 270 endpoint. 272 o participant: A sender or receiver that is taking part in a 273 multicast QUIC session. 275 o sender: A participant sending multicast traffic according to this 276 specification. 278 o receiver: A participant receiving multicast traffic according to 279 this specification. 281 o session: See multicast QUIC session. 283 o session ID: The identifier for a multicast QUIC session. 285 o session parameter: Characteristic of a multicast QUIC session. 287 2. Multicast QUIC Sessions 289 An HTTP/QUIC connection [QUIC-TRANSPORT] carried over bidirectional 290 unicast is defined as a conversation between two QUIC endpoints that 291 multiplexes several logical streams within a single encryption 292 context. This is a one-to-one relationship. Furthermore, QUIC 293 connections achieve decoupling from the underlying network (IP and 294 port) by means of a Connection ID. Use of a consistent connection 295 identifier allows QUIC connections to survive changes to the network 296 connectivity. The establishment of a QUIC connection relies upon an 297 up-front, in-band exchange (and possible negotiation) of 298 cryptographic and transport parameters (conveyed in QUIC handshake 299 messages) and HTTP-specific settings (conveyed in HTTP/QUIC 300 "SETTINGS" frames). Such parameters may be required or optional and 301 may be used by either endpoint to control the characteristics of 302 connection usage. 304 This concept of a connection does not suit the carriage of HTTP/QUIC 305 over unidirectional network associations such as multicast IP. In 306 fact, there is no requirement for either endpoint (multicast sender 307 or receiver) to be in existence in order for the other to start or 308 join this one-sided conversation. The term "connection" is 309 misleading in this context; therefore we introduce an alternative 310 term "multicast QUIC session" or simply "session", which is defined 311 as the logical entity describing the characteristics of the 312 anticipated unidirectional flow of metadata and data. Such 313 characteristics are expressed as "session parameters", described in 314 Section 2.2. Advertisement of multicast QUIC sessions, specified in 315 Section 3, allows for the senders and receivers to discover a session 316 and to form multicast IP network associations that permit traffic 317 flow. 319 2.1. Session States 321 The lifecycle of a multicast QUIC session is decoupled from the 322 lifecycle of any particular endpoint. Multicast receivers or senders 323 that take part in a session are called participants. The state of a 324 session is influenced by the actions of participants. The loose 325 coupling of participants means that they are unlikely to have a 326 consistent shared view of the current state of a session. There is 327 no requirement for a participant to know the session state and the 328 present document does not define a method to explicitly determine it. 329 The definitions of session states provided below are intended to 330 assist higher-level operational treatment of sessions: 332 o Quiescent: the session has no participants and is ready to accept 333 them. 335 o Half-established: the session has a participant. 337 o Fully-established: the session has a sender and at least one 338 receiver participant. 340 o Finished: the session has ended, and there are no participants. 342 Permitted states transitions are shown in Figure 1 below. 344 The transmission of QUIC packets is expected to occur only during the 345 Half-Established and Fully-Established states. 347 +-----------+ +------------------+ +-------------------+ 348 | |-------->| |------->| | 349 | Quiescent | | Half-Established | | Fully-Established | 350 | |<--------| |<-------| | 351 +-----------+ +------------------+ +-------------------+ 352 | | 353 | v 354 | +----------+ 355 | | | 356 +------------------>| Finished | 357 | | 358 +----------+ 360 Figure 1: Multicast QUIC session states 362 2.1.1. Session Establishment 364 A session begins in the Quiescent state. A typical session 365 establishment sequence would see the transition from Quiescent to 366 Half-Established when a sender joins the session. The transition 367 from Half-Established to Fully-Established occurs when at least one 368 receiver joins the session. 370 It is equally valid for a receiver to join a session in the Quiescent 371 state, triggering the transition to Half-Established. In this case, 372 the transition to Fully-Established takes place only when a sender 373 joins the session. 375 2.1.2. Session Termination 377 A session enters the Finished state when all participants leave it. 378 The methods for leaving a session are either explicit shutdown 379 (Section 5.5), implicit shutdown (i.e. idle timeout, Section 3.4) or 380 migration away (described in the next section). 382 In a typical case, a session that is in the Fully-Established state 383 would be closed in two stages. In the first stage the sender sends 384 explicit shutdown messages to the multicast group and subsequently 385 stops transmitting packets. This causes the session to transition 386 from Fully-Established to Half-Established. In the second stage, 387 receivers that have received explicit shutdown messages leave the 388 multicast group. Once all receivers have left the session it 389 transitions from Half-Established to Finished. 391 The transition from Quiescent to Finished could also occur in 392 response to out-of-band actions, for example the availability of a 393 session being withdrawn without any participants having made use of 394 it. 396 2.1.3. Session Migration 398 Endpoints MAY migrate between multicast QUIC sessions (for example, 399 to make use of alternate session parameters that are preferred). 400 Session migration requires participants to leave the current session 401 and join the new session. These actions affect the state of the 402 respective sessions as explained above. 404 The discovery of multicast QUIC sessions is described in Section 3. 406 2.2. Session Parameters 408 The characteristics of multicast QUIC sessions are expressed as 409 session parameters, which cover cryptographic and transport 410 parameters, HTTP-specific settings and multicast-specific 411 configuration. 413 Session parameter exchange over IP multicast is difficult: 415 o In-band exchanges are one-way, and so the client does not have the 416 means to send session parameters. 418 o The lifecycle of any multicast sender is independent of the 419 multicast receiver. It is therefore unlikely that all receivers 420 will have joined a session in time to receive parameters sent at 421 the start of a multicast session. 423 A range of strategies exists to mitigate these points. However, each 424 has the possibility to add complexity to deployment and 425 manageability, transmission overhead, or other such concerns. This 426 document defines a solution that relies on the one-way announcement 427 of session parameters in advance of session establishment. This is 428 achieved using HTTP Alternative Services [RFC7838] and is explained 429 in Section 3. Other advertisement solutions are not prohibited but 430 are not explored in this document. 432 Session parameters MUST NOT change during the lifetime of a session. 433 This restriction also applies to HTTP-level settings (see 434 Section 5.1). 436 2.3. Session Identification 438 This document defines a 64-bit session identifier used to identify a 439 session. This "Session ID" affords independence from multicast IP, 440 creating the possibility for a session to span multiple multicast 441 groups, or to migrate a session to a different multicast group. 442 Assignment of Session ID is considered out of this document's scope. 444 The Session ID is carried in the Connection ID field of the QUIC 445 packet (see Section 4.3). 447 A multicast sender participating in a session MUST send QUIC packets 448 with a matching Session ID. A multicast receiver participating in a 449 session MUST validate that the Session ID of received QUIC packets 450 matches that advertised in the session parameters (Section 3, 451 Section 10.2) before any HTTP-level processing is done. In the case 452 of validation failure, the receiver SHOULD ignore the packet in order 453 to protect itself from denial-of-service attacks. 455 2.4. Session Security 457 *Authors' Note:* Security handshake (as described in WG documents) 458 is in flux. This section will track developments and will be 459 updated accordingly. 461 The QUIC cryptographic handshake ([QUIC-TRANSPORT] and [QUIC-TLS]) 462 sets out methods to achieve the goals of authenticated key exchange 463 and QUIC packet protection between two endpoints forming a QUIC 464 connection. The design facilitates low-latency connection; 1-RTT or 465 0-RTT. QUIC Stream 0 is reserved for handshake messages. 467 This specification replaces the in-band security handshake, achieving 468 similar goals through the use of session parameters described in 469 Section 3.2. For the purpose of compatibility, the use of QUIC 470 stream 0 (see Section 4.4) is reserved. 472 Integrity and authenticity concerns are addressed in Section 6.1 and 473 Section 6.2 respectively. In order to protect themselves from attack 474 vectors, endpoints SHOULD NOT participate in sessions for which they 475 cannot establish reasonable confidence over the cipher suite or key 476 in use for that session. Participants MAY leave any session that 477 fails to successfully match anticipated security characteristics. 479 3. Session Advertisement 481 In this specification, connection negotiation is replaced with a 482 session advertisement mechanism based on HTTP Alternative Services 483 (Alt-Svc) [RFC7838]. This document specifies how the parameters of a 484 multicast QUIC session are expressed as Alt-Svc parameters. The 485 following sections provide a high-level view of these; further 486 details are provided in Section 10.2, with examples provided in 487 Appendix B.1. QUIC connection parameters not defined as, or related 488 to, Alt-Svc parameters are not used. 490 The definition of a session (including the session ID and its 491 parameters) is not the responsibility of any endpoint. Rather, 492 endpoints SHOULD use session advertisements to determine if they are 493 capable of participating in a given session. This document does not 494 specify which party is responsible for defining and/or advertising 495 multicast QUIC sessions. 497 Endpoints SHOULD NOT become participants in sessions where the 498 advertisement requirements set out in the present document are 499 unfulfilled. 501 The freshness of Alt-Svc multicast QUIC session advertisements is as 502 described in section 2.2 of [RFC7838]. 504 It is RECOMMENDED that session advertisements are carried over a 505 secure transport (such as HTTPS) which can guarantee the authenticity 506 and integrity of the Alt-Svc information. This addresses some of the 507 concerns around the protection of session establishment described in 508 Section 11.2. 510 *Authors' Note:* We invite review comments on mandating the use of 511 a secure transport for advertising sessions. 513 Senders MAY also advertise the availability of alternative sessions 514 by carrying Alt-Svc in a multicast QUIC session. 516 3.1. Version Advertisement 518 *Authors' Note:* Version negotiation (as described in WG 519 documents) is in flux. This section will track developments and 520 will be updated accordingly. 522 Conventional QUIC connection establishment begins with version 523 negotiation. In a unidirectional multicast environment, there is no 524 reasonable way to negotiate in such a manner. [QUIC-HTTP] defines an 525 Alt-Svc "quic" parameter that can be advertised to clients for use as 526 a version negotiation hint. This specification uses "quic" as a 527 session parameter for a similar purpose. This mechanism replaces the 528 use of the Version field in the QUIC packet long header (see 529 Section 4.2). 531 The Alt-Svc "quic" parameter is mandatory. Session advertisements 532 MUST contain exactly one instance of it and it MUST NOT be repeated. 534 A multicast sender participating in a session MUST send QUIC packets 535 and frames in the format corresponding to the advertised version. If 536 the sender does not support the advertised version it MUST NOT send 537 any data. A receiver MUST NOT join a session where the "quic" 538 parameter is absent. A receiver SHOULD NOT join a session for which 539 it does not support the advertised version, in order to avoid wasting 540 processing resources. 542 3.2. Security Context 544 *Authors' Note:* Security handshake (as described in WG documents) 545 is in flux. This section will track developments and will be 546 updated accordingly. 548 This specification replaces the in-band security handshake. The 549 session parameters "cipher suite", "key" and "iv" (described below) 550 allow for the establishment of a security context. In order to 551 protect themselves, endpoints SHOULD NOT participate in sessions for 552 which they cannot establish reasonable confidence over the cipher 553 suite, key, or IV in use for that session. Endpoints SHOULD leave 554 any sessions which fail to successfully match anticipated security 555 characteristics. 557 3.2.1. Cipher Suite 559 Cipher suite negotiation is replaced with a "cipher suite" session 560 parameter, which is advertised as the Alt-Svc parameter "cipher- 561 suite" (Section 10.2.2). 563 The Alt-Svc "cipher-suite" parameter is OPTIONAL. If present, this 564 parameter MUST contain only one value that corresponds to an entry in 565 the TLS Cipher Suite Registry (see http://www.iana.org/assignments/ 566 tls-parameters/tls-parameters.xhtml#tls-parameters-4). Session 567 advertisments that omit this parameter imply that the session is 568 operating with cipher suite 0x00,0x00 (NULL_WITH_NULL_NULL). 570 3.2.2. Key Exchange 572 Key exchange is replaced with a "key" session parameter, which is 573 advertised as the Alt-Svc parameter "key" (Section 10.2.3). The 574 parameter carries a variable-length hex-encoded key for use with the 575 session cipher suite. 577 The Alt-Svc "key" parameter is OPTIONAL. Session advertisments that 578 omit this parameter imply that the key may be available via an out- 579 of-band method not described in this document. 581 3.2.3. Initialization Vector 583 Initialization Vector (IV) exchange is replaced with an "iv" session 584 parameter, which is advertised as the Alt-Svc parameter "iv" 585 (Section 10.2.4). The parameter carries a variable-length hex- 586 encoded IV for use with the session cipher suite and key. 588 The Alt-Svc "iv" parameter is OPTIONAL. Session advertisments that 589 omit this parameter imply that the IV may be available via an out-of- 590 band method not described in this document. 592 3.3. Session Identification 594 [QUIC-TRANSPORT] specifies how the QUIC Connection ID is used, in 595 particular the client-side generation of this value. In a 596 unidirectional multicast environment, there is no meaningful way for 597 a client to generate a Connection ID and use it. This document 598 defines a "session identifier" session parameter, which is advertised 599 as the Alt-Svc parameter "session-id" (Section 10.2.5). The 600 requirements for the usage of session identifiers have already been 601 described in Section 2.3. 603 The Alt-Svc "session-id" parameter is mandatory. Session 604 advertisments MUST contain at least one instance. It MAY be repeated 605 with different values, indicating that multiple sessions are present. 607 *Authors' Note:* We invite review comments on mandating a single 608 session identifier per advertised session, i.e. only one session 609 identifier per ASM {G} or SSM {S,G}. 611 3.4. Session Idle Timeout 613 Conventional QUIC connections may be implicitly terminated following 614 a period of idleness (lack of network activity). The required QUIC 615 TransportParameter "idle_timeout" provides a means for endpoints to 616 specify the timeout period. This document defines a "session idle 617 timeout" session parameter, which is advertised as the Alt-Svc 618 parameter "session-idle-timeout" (Section 10.2.6). This session 619 parameter mimics the behaviour of "idle_timeout", providing a means 620 for multicast QUIC sessions to define their own idle timeout periods. 622 Session idle timeout may be prevented by keep-alive strategies 623 Section 4.8. 625 The Alt-Svc "session-idle-timeout" parameter is mandatory. Session 626 advertisments MUST contain at least one instance. If the parameter 627 is repeated the first occurrence MUST be used and subsequent 628 occurrences MUST be ignored. 630 Receiving participants SHOULD leave multicast QUIC sessions when the 631 session idle timeout period has elapsed (Section 4.7). Leaving 632 participants MUST use the silent close method, in which no QUIC 633 "CONNECTION_CLOSE" frame is sent. 635 3.5. Session Peak Flow Rate 637 [QUIC-TRANSPORT] specifies a credit-based stream- and connection- 638 level flow control scheme which prevents a fast sender from 639 overwhelming a slow receiver. Window size connection parameters are 640 exchanged on connection establishment using the required QUIC 641 TransportParameters "initial_max_data" and "initial_max_stream_data". 642 In a unidirectional multicast environment, such a scheme is 643 infeasible. This document defines a "peak flow rate" session 644 parameter, expressed in units of bits per second, which is advertised 645 as the Alt-Svc parameter "peak-flow-rate" (Section 10.2.8). This 646 replaces "initial_max_data" and "initial_max_stream_data" completely, 647 instead indicating the maximum bit rate of QUIC "STREAM" frame 648 payloads transmitted on all multicast groups comprising the session. 650 The Alt-Svc "peak-flow-rate" parameter is OPTIONAL. If the parameter 651 is repeated the first occurrence MUST be used and subsequent 652 occurrences MUST be ignored. Session advertisements that omit the 653 parameter imply that the flow rate is unlimited. 655 A multicast sender SHOULD NOT cause the advertised peak flow rate of 656 a session to be exceeded. A receiver MAY leave any session where the 657 advertised peak flow rate is exceeded. 659 3.6. Resource Concurrency 661 [QUIC-TRANSPORT] considers concurrency in terms of the number of 662 active incoming streams, which is varied by the receiving endpoint 663 adjusting the maximum Stream ID. The initial value of maximum Stream 664 ID is controlled by the relevant required QUIC TransportParameters 665 "initial_max_stream_id_bidi" and "initial_max_stream_id_uni". They 666 are increased during the lifetime of a QUIC connection by the QUIC 667 "MAX_STREAM_ID" frame. In a unidirectional multicast environment, 668 there is no way for a receiver to specify an initial limit nor 669 increase it. Therefore in multicast QUIC, the maximum Stream ID 670 (initial and always) is 2^62. This mechanism is not used to manage 671 concurrency in multicast QUIC. 673 Due to the profiling of maximum Stream ID, there is no role for the 674 QUIC "STREAM_ID_BLOCKED" frame and it is prohibited. Participants 675 MUST NOT send this frame type. Reception of this frame type MUST be 676 handled as described in Section 4.10. 678 This document specifies a "maximum concurrent resources" session 679 parameter, which is advertised as the Alt-Svc parameter "max- 680 concurrent-resources" (Section 10.2.7). This parameter replaces 681 "initial_max_stream_id_bidi" and "initial_max_stream_id_uni". It 682 advertises the maximum number of concurrent active resources 683 generated by a sender in a given multicast QUIC session. 685 The Alt-Svc "max-concurrent-resources" parameter is OPTIONAL. If the 686 parameter is repeated the first occurrence MUST be used and 687 subsequent occurrences MUST be ignored. Session advertisements that 688 omit the parameter imply that the maximum concurrency is unlimited. 690 A multicast sender participating in a session MUST NOT cause the 691 advertised "max-concurrent-resources" to be exceeded. A receiver MAY 692 leave any session where the advertised limit is exceeded, in order to 693 protect itself from denial-of-service attacks. 695 3.7. Additional TransportParameter Considerations 697 *Authors' Note:* This section will consider TransportParameters 698 that have not already been addressed, as required. It will track 699 developments and issues that may arise. 701 3.8. Digest Algorithm 703 A method to provide content integrity is described in Section 6.1. 704 This specifies the means to convey a value computed by a particular 705 digest algorithm. The identity of the selected algorithm is also 706 indicated. Valid digest algorithms are collected in the IANA HTTP 707 Digest Algorithm Values registry (http://www.iana.org/assignments/ 708 http-dig-alg/http-dig-alg.xhtml#http-dig-alg-1). 710 This document specifies a "digest algorithm" session parameter, which 711 is advertised as the Alt-Svc parameter "digest-algorithm" 712 (Section 10.2.9). 714 *Authors' Note:* Section 6.1 contains an author's note on the 715 potential for content integrity to become mandatory. This section 716 will be updated in line with the outcome of that decision. 718 The Alt-Svc "digest-algorithm" parameter is OPTIONAL. Repetition of 719 the "digest algorithm" parameter in a single advertisement describes 720 an algorithm set that MAY be used across the session. Session 721 advertisements that omit the Alt-Svc parameter "digest-algorithm" 722 imply that either: 724 o the session does not use the content integrity mechanism, or 726 o the algorithm set is unrestricted, i.e. a sender may vary the 727 algorithm as it so chooses. This may lead to undesirable results 728 if receivers do not support a chosen algorithm. 730 Advertising the algorithm set for a session gives receivers the 731 opportunity to selectively join sessions where the algorithms are 732 known to be supported. This may help to mitigate latency issues in 733 the receiver resulting from joining a session only to discover some 734 of its parameters are not supported. 736 A multicast sender participating in a session MUST NOT use algorithms 737 outside the signalled digest algorithm set. A receiver MAY leave any 738 session where an algorithm outside the digest algorithm set is used. 740 3.9. Signature Algorithm 742 A method to provide content authenticity is described in Section 6.2. 743 This specifies the means to convey a value computed by a particular 744 signature algorithm. The identity of the selected algorithm is also 745 indicated. Valid signature algorithms are collected in the IANA 746 Signature Algorithms registry (http://www.iana.org/assignments/ 747 signature-algorithms). 749 This document specifies a "signature algorithm" session parameter, 750 which is advertised as the Alt-Svc parameter "signature-algorithm" 751 (Section 10.2.10). 753 *Authors' Note:* Section 6.2 contains an author's note on the 754 potential for content authenticity to become mandatory. This 755 section will be updated in line with the outcome of that decision. 757 The Alt-Svc "signature-algorithm" parameter is OPTIONAL. Repetition 758 of the "signature algorithm" parameter in a single advertisement 759 describes an algorithm set that MAY be used across the session. 760 Session advertisements that omit the Alt-Svc parameter "signature- 761 algorithm" imply that either: 763 o the session does not use the content authenticity mechanism, or 765 o the algorithm set is unrestricted i.e. a sender may vary the 766 algorithm as it so chooses. This may lead to undesirable results 767 if receivers do not support a chosen algorithm. 769 Advertising the algorithm set for a session gives receivers the 770 opportunity to selectively join sessions where the algorithms are 771 known to be supported. This may help to mitigate latency issues in 772 the receiver resulting from joining a session only to discover some 773 of its parameters are not supported. 775 A multicast sender participating in a session MUST NOT use algorithms 776 outside the signalled signature algorithm set. A receiver MAY leave 777 any session where an algorithm outside the signature algorithm set is 778 used. 780 4. QUIC Profile 782 *Authors' Note:* The QUIC transport document is subject to change. 783 This section is based on our best understanding of draft-ietf- 784 quic-transport-09. The authors will track developments and will 785 update this section accordingly. 787 The profile of [QUIC-TRANSPORT] is presented in this section. In 788 order to preserve compatibility with conventional QUIC, the 789 specification works with a limited scope of change. However, the 790 nature of unidirectional multicast communications means that some 791 protocol procedures or behaviours need to be modified. 793 4.1. Packet Size 795 The means for determining an appropriate size for QUIC packets are 796 described in Section 9 of [QUIC-TRANSPORT]. Implementations of this 797 specification SHOULD bear in mind that the Path Maximum Transmission 798 Unit (PTMU) may be affected by multicast IP technologies such as 799 Automatic Multicast Tunneling (AMT) [RFC7450]. Additionally, 800 consideration should be given toward the applicability of maximum 801 transmission unit discovery methods (such as PLPMTUD [RFC4821] and 802 PMTUD [RFC1191]) to multicast IP. 804 4.2. Packet Format 806 Endpoints implementing this specification MUST only send QUIC packets 807 with the short header form. This header form omits the Version 808 field. 810 *Authors' Note:* The authors welcome suggestions for conveying the 811 QUIC version in every multicast QUIC packet. 813 4.3. Connection Identifier 815 The Connection ID field MUST be present in every QUIC packet, and the 816 corresponding flag in the packet header MUST be set to indicate that 817 the Connection ID field is present. 819 4.4. Stream Identifier 821 The maximum Stream ID of a multicast QUIC session is 2^62, as 822 explained in Section 3.6. 824 Senders MUST NOT send any QUIC frames on QUIC stream 0. Receivers 825 MUST ignore QUIC frames received on stream 0. 827 4.5. Flow Control 829 Conventional QUIC provides stream- and connection-level flow control, 830 and endpoints manage this by sending QUIC "MAX_DATA" or 831 "MAX_STREAM_DATA" frames as required. When a sender is blocked from 832 sending flow-controlled frames, it sends an informational QUIC 833 "BLOCKED" or "STREAM_BLOCKED" frame. 835 In a unidirectional environment, the sender never has a receive 836 window and the receiver cannot send in-band updates. Therefore, the 837 management of flow-control windows and transmission of blockage 838 information is not supported by this profile. The QUIC "MAX_DATA", 839 "MAX_STREAM_DATA", "BLOCKED" and "STREAM_BLOCKED" frames are 840 prohibited by this profile. Participants MUST NOT send these frame 841 types. Reception of these frame types MUST be handled as described 842 in Section 4.10. 844 4.6. Stream Termination 846 A sender MAY prematurely terminate the transmission on any unreserved 847 QUIC Stream ID by setting the "FIN" bit of a QUIC "STREAM" frame, or 848 by sending a QUIC "RST_STREAM" frame (as specified in 849 [QUIC-TRANSPORT] and [QUIC-HTTP]). 851 Receiving participants MUST NOT make any attempt to send QUIC 852 "RST_STREAM" frames to the multicast group. 854 4.7. Session Shutdown 856 Explicit shutdown of a multicast QUIC session using QUIC methods is 857 not supported by this profile. 859 The QUIC "APPLICATION_CLOSE" and "CONNECTION_CLOSE" frames, and the 860 Public Reset packet are prohibited. Participants MUST NOT send these 861 and reception MUST be handled as described in Section 4.10. 863 The HTTP/QUIC "GOAWAY" frame is prohibited. Participants MUST NOT 864 send this and reception MUST be handled as described in Section 5.7. 866 Explicit session tear-down using HTTP semantics is allowed, as 867 described in Section 5.5. 869 Implicit shutdown by means of silent close is also supported, as 870 described in Section 3.4. 872 4.8. Session Keep-alive 874 The flow of traffic in a multicast QUIC session is driven by a 875 sender. There may be periods where the sender has no application 876 data to send for a period longer than the session idle timeout. This 877 profile repurposes the QUIC "PING" frame to act as a unidirectional 878 keep-alive message that may be sent in order to inform receivers that 879 the session should remain in the Fully-established state. 880 [QUIC-TRANSPORT] contains guidance on the sending frequency of QUIC 881 "PING" frames. 883 Senders MAY send a QUIC "PING" frame with an empty Data field at any 884 time in order to inform receivers that the session traffic flow has 885 not fallen idle. This frame MUST NOT be acknowledged. Indeed, QUIC 886 "ACK" frames are prohibited by this profile (Section 4.9). 888 Senders MUST NOT send a QUIC "PING" frame with a populated Data 889 field. This effectively means that QUIC "PONG" frames are also 890 prohibited by this profile. 892 Receiving participants MUST NOT make any attempt to send QUIC "PING" 893 frames. 895 4.9. Loss Detection and Recovery 897 Receivers implementing this profile MUST NOT make any attempt to 898 acknowledge the reception of QUIC packets. The QUIC "ACK" frame is 899 prohibited for both senders and receivers. Reception of this frame 900 MUST be handled as described in Section 4.10. 902 Section 7 specifies alternative strategies for loss recovery. 904 4.10. Prohibited QUIC Frames and Packets 906 The following QUIC packets MUST NOT be transmitted by participants: 907 0-RTT Protected, 1-RTT Protected (key phase 0), 1-RTT Protected (key 908 phase 1), Client Cleartext, Client Initial, Public Reset, Server 909 Cleartext, Server Initial, Version Negotiation. 911 The following QUIC frames MUST NOT be transmitted by participants: 912 "ACK", "APPLICATION_CLOSE", "BLOCKED", "CONNECTION_CLOSE", 913 "MAX_DATA", "MAX_STREAM_ID", "MAX_STREAM_DATA", "PING" (with Data), 914 "PONG", "STREAM_BLOCKED", "STREAM_ID_BLOCKED". 916 The following QUIC frames MUST NOT be transmitted by receivers: 917 "RST_STREAM". 919 Reception of a prohibited QUIC frame or packet is a protocol error. 920 Receivers MUST ignore all prohibited QUIC frames and packets. 922 5. HTTP/QUIC Profile 924 *Authors' Note:* The HTTP/QUIC mapping document is subject to 925 change. This section is based on our best understanding of draft- 926 ietf-quic-http-09. The authors will track developments and will 927 update this section accordingly. 929 HTTP over multicast QUIC depends on HTTP server push, as described in 930 Section 4.4 of [QUIC-HTTP]. Section 5.2 below applies an additional 931 constraint on the use of server push. A multicast sender 932 participating in a session pushes resources as a series of QUIC 933 "STREAM" frames carrying HTTP/QUIC "PUSH_PROMISE", "HEADERS" and 934 "DATA" frames. Examples of this are provided in Appendix B.2. 935 Senders MUST comply with the requirements of the session parameters, 936 as described earlier in Section 3. 938 The profile of HTTP/QUIC specified in this section places additional 939 constrains on the use of metadata compression (Section 5.3) and 940 prioritisation (Section 5.4). 942 5.1. HTTP Connection Settings 944 The HTTP/QUIC "SETTINGS" frame is prohibited by this profile. 945 Participants MUST NOT make any attempt to send this frame type. 946 Reception of this frame MUST be handled as described in Section 5.7. 948 5.2. Server Push 950 Server push is, by default, disabled for HTTP/QUIC connections. A 951 conventional HTTP/QUIC client enables and manages server push by 952 controlling the maximum Push ID ([QUIC-HTTP], Section 5.2.6), 953 achieved by sending the HTTP/QUIC "MAX_PUSH_ID" frame. 955 This profile mandates the use of server push, and specifies no means 956 to disable it. The maximum Push ID for multicast QUIC sessions 957 (initial and always) is 2^62. 959 Server push concurrency in multicast QUIC is described in 960 Section 3.6. There is no role for the HTTP/QUIC "MAX_PUSH_ID" frame 961 and it is prohibited. Participants MUST NOT send this frame type. 962 Reception of this frame type MUST be handled as described in 963 Section 5.7. 965 The HTTP/QUIC "CANCEL_PUSH" frame MAY be used by sending participants 966 to abort sending a response for the identified server push. Usage of 967 this frame should follow the guidance for servers in [QUIC-HTTP]. 969 Receiving participants MUST NOT make any attempt to send QUIC 970 "CANCEL_PUSH" frames to the multicast group. 972 Conventionally, pushed responses are associated with an explicit 973 request from a client. This is not possible when using a 974 unidirectional transport such as multicast IP. This profile reserves 975 the first client-initiated, bidirectional QUIC stream. HTTP/QUIC 976 "PUSH_PROMISE" frames MUST be sent on this reserved Stream ID. 978 *Authors' Note:* The exact value of this Stream ID is currently in 979 flux. This section will track developments and will be updated 980 accordingly. The possibility of sending HTTP/QUIC "PUSH_PROMISE" 981 frames on a control stream is discussed on 982 https://github.com/quicwg/base-drafts/issues/947. 984 5.3. Metadata Compression 986 The compression of HTTP header fields is considered in HPACK 987 [RFC7541], which describes two methods for the compression of HTTP 988 header fields: indexing (via static or dynamic tables) and Huffman 989 encoding. 991 A multicast QUIC session, as described in the present document, does 992 not provide the assurances (receiver participation, transport 993 reliability) required to sufficiently maintain the dynamic decoding 994 context. Therefore, this document requires that endpoints SHALL NOT 995 use dynamic indexing. It is RECOMMENDED that endpoints use static 996 indexing and/or Huffman encoding in order to benefit from the 997 remaining compression methods available. 999 *Authors' Note:* In the context of QUIC, changes to HPACK may 1000 allow for better leverage of the transport. QPACK 1001 ([I-D.bishop-quic-http-and-qpack]), QCRAM 1002 ([I-D.krasic-quic-qcram]) and QMIN ([I-D.tikhonov-quic-qmin]) are 1003 active proposals in this space. This section will track 1004 developments and will be updated accordingly. 1006 5.4. Prioritisation 1008 The HTTP/QUIC "PRIORITY" frame is prohibited by this profile. 1009 Participants MUST NOT make any attempt to send this frame type. 1010 Reception of this frame MUST be handled as described in Section 5.7. 1012 5.5. Session Tear-down 1014 A multicast QUIC session MAY be explicitly torn down by means of the 1015 "Connection: close" HTTP header described in section 6.6 of 1016 [RFC7230]. A sender intending to leave the session SHOULD include 1017 the "Connection: close" header in its response metadata. A sender 1018 SHOULD transmit all outstanding frames related to remaining request/ 1019 response exchanges before ending transmission to the multicast group. 1020 A receiver SHOULD continue to receive and process frames until all 1021 outstanding request/response exchanges are complete. 1023 5.6. HTTP/QUIC Extension frames 1025 HTTP/QUIC extension frames (e.g. "ALTSVC") are prohibited by this 1026 profile. Participants MUST NOT make any attempt to send extension 1027 frame types. Reception of these MUST be handled as described in 1028 Section 5.7. 1030 5.7. Prohibited HTTP/QUIC Frames 1032 The following HTTP/QUIC frames MUST NOT be transmitted by 1033 participants: "GOAWAY", "MAX_PUSH_ID", "PRIORITY", "SETTINGS". 1035 In addition, all HTTP/QUIC extension frame types MUST NOT be 1036 transmitted by participants. 1038 The following HTTP/QUIC frames MUST NOT be transmitted by receivers: 1039 "CANCEL_PUSH". 1041 Reception of a prohibited HTTP/QUIC frame is a protocol error. 1042 Receivers MUST ignore prohibited HTTP/QUIC frames. 1044 6. Application-Layer Security 1046 As already described in Section 3.2, the implicit cipher suite used 1047 by a multicast QUIC session makes very limited provision for security 1048 in the transport and session layers. This section profiles the use 1049 of some additional features to provide equivalent functionality at 1050 the application-layer. 1052 6.1. Content Integrity 1054 In many applications, it is important to ensure that an HTTP 1055 representation has been received intact (i.e. has not suffered from 1056 transmission loss or random bit errors) before passing the received 1057 object on to the receiving application. A mechanism is therefore 1058 specified here to provide end-to-end content integrity protection for 1059 HTTP representations in transit. The use of this content integrity 1060 mechanism is RECOMMENDED. 1062 *Authors' Note:* We invite review comments on mandating the use of 1063 this content integrity mechanism. 1065 [RFC3230] specifies an instance digest HTTP header called "Digest". 1066 A sender MAY include this header in the HTTP/QUIC "HEADERS" frame of 1067 any representation it transmits and a receiver MAY use this header to 1068 validate the integrity of the received representation once it has 1069 been reassembled. Where this validation fails, the receiver SHOULD 1070 discard the representation without processing it further. 1072 Note that the digest value protects a whole HTTP instance (i.e. the 1073 representation of a resource at the point of transmission as opposed 1074 to the body of a particular HTTP message). In cases where partial 1075 representations are fragmented over one or more HTTP response 1076 messages, the digest value is computed over the complete 1077 representation prior to fragmentation into partial responses. 1079 Any of the algorithms specified in the IANA registry of digest 1080 algorithms (http://www.iana.org/assignments/http-dig-alg/http-dig- 1081 alg.xhtml#http-dig-alg-1) MAY be used in conjunction with the 1082 "Digest" header. There is no requirement for participants to support 1083 the full set of algorithms. 1085 6.2. Content Authenticity 1087 In some applications, it is important for a receiver to reassure 1088 itself that an HTTP representation has been received from an 1089 authentic source. It is also sometimes useful for a receiver to know 1090 that the information has not been tampered with in transit by a 1091 malicious intermediate actor. A mechanism is therefore specified 1092 here to prove the authenticity of HTTP messages in transit. The use 1093 of this content authenticity mechanism is RECOMMENDED for senders 1094 implementing this specification. 1096 *Authors' Note:* We invite review comments on mandating the use of 1097 this content authenticity mechanism. 1099 [I-D.cavage-http-signatures] specifies a means of securely signing 1100 metadata associated with any HTTP message. The resulting digital 1101 signature is conveyed in the "Signature" header of the message 1102 itself. The "Signature" header also conveys a list of HTTP header 1103 fields over which the signature was computed. A receiver MAY verify 1104 the "Signature" header in order to validate the authenticity of 1105 received metadata. Where this validation fails, the receiver SHOULD 1106 discard or ignore any related metadata and/or data without processing 1107 it further. 1109 Note that the signature proves the authenticity of the metadata in a 1110 single HTTP message. A "Signature" header MAY be included separately 1111 in the HTTP/QUIC "PUSH_PROMISE" frame (protecting the request 1112 metadata) and in the final (or only) HTTP/QUIC "HEADERS" frame 1113 relating to a particular resource (protecting the response metadata). 1114 In order to provide an additional level of protection, however, it is 1115 RECOMMENDED that the signature be computed over the combined request 1116 metadata (from the "PUSH_PROMISE" frame) and the corresponding 1117 response metadata (from the HTTP/QUIC "HEADERS" frames) of the same 1118 resource. This binds the request metadata and response metadata 1119 together, providing the receiver with additional reassurance of 1120 authenticity. In this latter case, the combined digital signature 1121 SHALL be conveyed in the final (or only) HTTP/QUIC "HEADERS" frame. 1123 In applications where the detection of replay attacks is a 1124 requirement, it is RECOMMENDED that the "Date" header be included in 1125 the scope of the signature. It is RECOMMENDED that receivers use the 1126 value of the "Date" header for replay detection using appropriate 1127 strategies (e.g. checking for freshness). The definition of such 1128 strategies is beyond the scope of this document. 1130 In applications where the authenticity and integrity of the 1131 transmission are both important, it is RECOMMENDED that the "Digest" 1132 header specified in Section 6.1 above is included in the scope of the 1133 signature. By signing the instance digest, the authenticity and 1134 integrity of the HTTP message body are also assured in addition to 1135 that of the metadata. 1137 Any of the algorithms specified in the IANA registry of signature 1138 algorithms (http://www.iana.org/assignments/signature-algorithms) MAY 1139 be used in conjunction with the "Signature" header. There is no 1140 requirement for participants to support the full set of algorithms. 1142 6.3. Content Confidentiality 1144 In applications where there is a requirement for the content itself 1145 to remain confidential, appropriate steps SHOULD be taken to protect 1146 the application payload, for example by encrypting it. This document 1147 does not preclude the use of application-level encryption, but does 1148 not specify a mechanism for the distribution of content decryption 1149 keys. 1151 7. Loss Recovery 1153 Because the acknowledgement of received packets to multicast groups 1154 is prohibited by this specification (Section 4.9) the detection of 1155 discarded or corrupted packets is the sole responsibility of the 1156 receiver, and such losses must be recovered by means other than the 1157 retransmission mechanism specified in [QUIC-TRANSPORT] and 1158 [QUIC-RECOVERY]. 1160 7.1. Forward Error Correction 1162 *Authors' Note:* A simple parity-based Forward Error Correction 1163 scheme was removed from the experimental QUIC wire protocol 1164 specification in version Q032. The IETF's QUIC Working Group is 1165 chartered to specify one (or more) new FEC schemes in the future. 1166 This section will track developments in this area, and will be 1167 updated accordingly. 1169 A sender MAY make use of a suitable Forward Error Correction scheme 1170 to allow a receiver to reconstruct lost packets from those that have 1171 been successfully received. 1173 7.2. Unicast Repair 1175 In the case where a lost QUIC packet cannot be recovered using 1176 Forward Error Correction, either because the number of packets lost 1177 exceeds the scheme's threshold for reconstruction, or because FEC is 1178 not in use on the multicast QUIC session, a receiver MAY instead 1179 recover the missing payload data using conventional unicast HTTP 1180 requests to an origin server. 1182 o The total size of the resource is indicated in the "content- 1183 length" response header carried in the HTTP/QUIC "HEADERS" frame. 1185 o The location of the missing data can be determined by examining 1186 the Offset field in the QUIC "STREAM" frame headers of 1187 successfully received QUIC packets. 1189 Using this information, a receiver MAY compose an efficient HTTP 1190 range request [RFC7233] to the origin server indicated in the URL. 1191 Several disjoint ranges MAY be combined into a single HTTP request. 1192 A receiver MAY direct its request to an alternative server using Alt- 1193 Svc information received on the multicast QUIC session, or else 1194 received as part of a previous unicast HTTP response according to the 1195 rules in [RFC7838]. 1197 8. Transmission of Partial Content 1199 Under certain circumstances, a sender may not be in full possession 1200 of a resource body when transmission begins, or may not be able to 1201 guarantee that a transmission will complete. In such cases, the 1202 sender MAY employ the syntax of an HTTP range request [RFC7233] to 1203 indicate partial content, as specified below. All receivers SHALL 1204 implement support for such HTTP range requests. 1206 If partial content is to be transmitted: 1208 o The "range" header (Section 3.1 of [RFC7233]) SHALL be present in 1209 the HTTP/QUIC "PUSH_PROMISE" frame. 1211 o The corresponding HTTP/QUIC "HEADERS" frame SHALL indicate HTTP 1212 status code 206. 1214 * The range being transmitted SHALL be indicated in a "content- 1215 range" header field and the size of the complete resource 1216 indicated in a "content-length" header field. 1218 9. Protocol Identifier 1220 The HTTP over multicast QUIC protocol specified in this document is 1221 identified by the application-layer protocol negotiation (ALPN) 1222 [RFC7301] identifier "hqm". The IANA registration of this protocol 1223 identifier can be found in Section 12.1. This reserves the ALPN 1224 identifier space but describes a protocol that does not use TLS. The 1225 usage of the "hqm" identifier for discoverability is described in 1226 Section 10. 1228 9.1. Draft Version Identification 1230 *RFC Editor's Note:* Please remove this section prior to 1231 publication of a final version of this document. 1233 Only implementations of the final, published RFC can identify 1234 themselves as "hqm". Until such an RFC exists, implementations MUST 1235 NOT identify themselves using this string. 1237 Implementations of draft versions of the protocol MUST add the string 1238 "-" and the corresponding draft number to the identifier. For 1239 example, draft-pardue-quic-http-mcast-00 is identified using the 1240 string "hqm-00". 1242 Non-compatible experiments that are based on these draft versions 1243 MUST append the string "-" and an experiment name to the identifier. 1244 For example, an experimental implementation based on draft-pardue- 1245 quic-http-mcast-09 which removes the requirement to ensure version 1246 matches might identify itself as "hqm-09-version-ignorant". Note 1247 that any label MUST conform to the "token" syntax defined in 1248 Section 3.2.6 of [RFC7230]. Experimenters are encouraged to 1249 coordinate their experiments. 1251 10. Discovery of Multicast QUIC Sessions 1253 The announcement and discovery of services operating over multicast 1254 IP has previously been specified by the Session Description Protocol 1255 (SDP) [RFC4566], Session Announcement Protocol [RFC2974] and Session 1256 Initiation Protocol [RFC3261]. These are typically deployed together 1257 and in conjunction with a multicast-friendly transport such as the 1258 Real-time Transport Protocol (RTP) [RFC3550]. 1260 In contrast, the present document specifies a mechanism for 1261 advertising services that is built into HTTP metadata and is 1262 consistent across unicast and multicast resource delivery modes. 1263 This means that a single application-layer can be used for service 1264 advertisement/discovery, and for bulk data transmission/reception. 1265 Specifically, the "Alt-Svc" HTTP header is specified as the means to 1266 advertise multicast services from a unicast service. A unicast HTTP 1267 response MAY be decorated with an Alt-Svc value that hints to the 1268 client about the availability of the resource via a multicast QUIC 1269 session. A client that supports such a multicast QUIC session MAY 1270 then transparently switch to it. 1272 Symmetrically, the "Alt-Svc" header can also be used to advertise the 1273 unicast service from a multicast service. A resource transmitted as 1274 part of a multicast QUIC session MAY be decorated with an Alt-Svc 1275 value that hints to the client about the availability of the resource 1276 via an alternative unicast HTTP server. A receiver MAY then use this 1277 HTTP server for unicast resource patching (Section 7.2). 1279 Where HTTP over multicast QUIC sessions are advertised using Alt-Svc, 1280 the protocol identifier SHALL be "hqm", as specified in Section 9. 1282 10.1. Source-specific Multicast Advertisement 1284 Source-specific multicast (SSM) [RFC4607] MAY be used for the 1285 delivery of multicast services. 1287 *Authors' Note:* We invite review comments on mandating the use of 1288 source-specific multicast only. 1290 This document specifies the "source-address" parameter for Alt-Svc, 1291 which is used to provide the SSM source address to endpoints. 1293 Syntax: 1295 source-address = uri-host; see RFC7230, Section 2.7 1297 For example: 1299 source-address="192.0.2.1" 1301 When a multicast QUIC session is provided using SSM, the "source- 1302 address" parameter MUST be advertised. 1304 10.2. Session Parameter Advertisement 1306 The concept of session parameters is introduced in Section 2.2. This 1307 section details how the session parameters are expressed as Alt-Svc 1308 parameters. 1310 10.2.1. Version 1312 The version of QUIC supported in a multicast QUIC session is 1313 advertised with the "quic" parameter. The requirements for endpoint 1314 usage of "quic" are specified in Section 3.1. 1316 10.2.2. Cipher Suite 1318 This document specifies the "cipher-suite" parameter for Alt-Svc, 1319 which carries the cipher suite in use by a multicast QUIC session. 1320 "cipher-suite" MUST contain one of the values contained in the TLS 1321 Cipher Suite Registry (http://www.iana.org/assignments/tls- 1322 parameters/tls-parameters.xhtml#tls-parameters-4): 1324 Syntax: 1326 cipher-suite = 4*4 HEXDIG 1328 For example, the following specifies cipher suite 0x13,0x01 1329 ("TLS_AES_128_GCM_SHA256"): 1331 cipher-suite=1301 1333 The requirements for endpoint usage of "cipher-suite" are described 1334 in Section 3.2. 1336 10.2.3. Session Key 1338 This document specifies the "key" parameter for Alt-Svc, which 1339 carries the cryptographic key in use by the multicast QUIC session. 1341 Syntax: 1343 key = *HEXDIG 1345 For example: 1347 key=4adf1eab9c2a37fd 1349 The requirements for endpoint usage of "key" are described in 1350 Section 3.2. 1352 10.2.4. Session Cipher Initialization Vector 1354 This document specifies the "iv" parameter for Alt-Svc, which carries 1355 the cipher Initialization Vector (IV) in use by the multicast QUIC 1356 session. 1358 Syntax: 1360 iv = *HEXDIG 1362 For example: 1364 iv=4dbe593acb4d1577ad6ba7dc3189834e 1366 The requirements for endpoint usage of "iv" are described in 1367 Section 3.2. 1369 10.2.5. Session Identification 1371 This document defines the "session-id" parameter for Alt-Svc, which 1372 carries the multicast QUIC session identifier. 1374 Syntax: 1376 session-id = 1*16HEXDIG ; 64-bit value 1378 For example, the following specifies session 101 (0x65 hexadecimal): 1380 session-id=65 1382 The requirements for endpoint usage of "session-id" are described in 1383 Section 2.3. 1385 10.2.6. Session Idle Timeout Period 1387 This document specifies the "session-idle-timeout" parameter for Alt- 1388 Svc, which carries the idle timeout period of a multicast QUIC 1389 session. 1391 Syntax: 1393 session-idle-timeout = *DIGIT ; number of seconds between 0 and 600 1395 For example, the following specifies a one-minute session idle 1396 timeout period: 1398 session-idle-timeout=60 1400 The requirements for endpoint usage of "session-idle-timeout" are 1401 described in Section 3.4. 1403 10.2.7. Resource Concurrency 1405 This document specifies the "max-concurrent-resources" parameter for 1406 Alt-Svc, which expresses the maximum number of concurrent active 1407 resources from the sender in a multicast QUIC session. 1409 Syntax: 1411 max-concurrent-resources = *DIGIT ; unsigned 32-bit integer 1413 For example, the following specifies that no more than 12 (decimal) 1414 resources will be concurrently active in the session: 1416 max-concurrent-resources=12 1418 The requirements for endpoint usage of "max-concurrent-resources" are 1419 described in Section 3.6. 1421 10.2.8. Session Peak Flow Rate 1423 This document specifies the "peak-flow-rate" parameter for Alt-Svc, 1424 which expresses the expected maximum aggregate transfer rate of data 1425 from all sources of the multicast QUIC session. 1427 Syntax: 1429 peak-flow-rate = *DIGIT ; bits per second 1431 For example, the following specifies a peak flow rate of 550 kbits/s 1432 in the session: 1434 peak-flow-rate=550000 1436 The requirements for endpoint usage of "peak-flow-rate" are described 1437 in Section 3.5. 1439 10.2.9. Digest Algorithm 1441 This document specifies the "digest-algorithm" parameter for Alt-Svc, 1442 which carries the digest algorithm in use by a multicast QUIC 1443 session. "digest-algorithm" MUST contain one of the values defined in 1444 the HTTP Digest Algorithm Values registry 1445 (https://www.iana.org/assignments/http-dig-alg/http-dig- 1446 alg.xhtml#http-dig-alg-1). 1448 Syntax: 1450 digest-algorithm = token 1452 For example, the following specifies a digest algorithm of SHA-256: 1454 digest-algorithm=SHA-256 1456 The requirements for endpoint usage of "digest-algorithm" are 1457 described in Section 3.8. 1459 10.2.10. Signature Algorithm 1461 This document specifies the "signature-algorithm" parameter for Alt- 1462 Svc, which carries the signature algorithm in use by a multicast QUIC 1463 session. "signature-algorithm" MUST contain one of the values defined 1464 in the Signature Algorithms registry 1465 (http://www.iana.org/assignments/signature-algorithms). 1467 Syntax: 1469 signature-algorithm = token 1471 For example, the following specifies a signature algorithm of SHA- 1472 256: 1474 signature-algorithm=rsa-sha256 1475 The requirements for endpoint usage of "signature-algorithm" are 1476 described in Section 3.9. 1478 11. Security and Privacy Considerations 1480 This document specifies a profile of QUIC and HTTP/QUIC that changes 1481 the security model. In order to address this, application-level 1482 security methods are described in Section 6. This document does not 1483 preclude the use of secure multicast approaches that may provide 1484 additional security assurances required for certain use cases. 1486 The use of side-channel or out-of-band technologies (potentially 1487 bidirectional interactions) to support multicast QUIC sessions are 1488 considered out of this document's scope. Services using such 1489 technologies should apply their security considerations accordingly. 1491 11.1. Pervasive Monitoring 1493 Certain multicast deployment architectures may require the use of a 1494 session decryption key shared by all participants. Furthermore, the 1495 discovery mechanism described in this document provides a means for a 1496 receiver to obtain a session decryption key without joining the 1497 session. The act of removing packet protection in order to inspect 1498 or modify application contents may, in certain deployments, be 1499 trivial. The exploration of restricting key learning or session 1500 joining to authorised participants goes beyond the scope of this 1501 document. 1503 Because in-band multicast interactions are unidirectional, the impact 1504 of Pervasive Monitoring [RFC7258] on in-band traffic flows is 1505 inherently reduced. Actors can only inspect or modify sender- 1506 initiated traffic. Additional measures for content confidentiality 1507 may mitigate the impact further. This is discussed in Section 6.3. 1509 Further Pervasive Monitoring concerns are addressed in the following 1510 sections. 1512 11.1.1. Large-scale Data Gathering and Correlation 1514 Multicast QUIC sessions decouple sending and receiving participants. 1515 Session participation is subject to operations that allow an endpoint 1516 to join or leave a multicast group, typically IGMP [RFC3376] or MLD 1517 [RFC3810]. The propagation intent of these messages travelling 1518 deeper through a network hierarchy generally leads to the 1519 anonymisation of data if implemented as specified. It may be 1520 possible to gather user-identifiable messages close to the network 1521 edge, for example a router logging such messages. However, this 1522 would require wide-ranging access across Internet Service Provider 1523 networks. Therefore, while such attacks are feasible, it can be 1524 asserted that gathering and correlating user-identifiable traffic is 1525 difficult to perform covertly and at scale. 1527 11.1.2. Changing Content 1529 Sessions that use a symmetric key for packet protection are subject 1530 to the possibility of a malicious actor modifying traffic at some 1531 point in the network between a legitimate sender and one (or more) 1532 receivers. Receiver-side validation, as specified in Section 6 of 1533 the present document, and also in [QUIC-TRANSPORT], allows for the 1534 detection of such modification. Two approaches help mitigate the 1535 impact of modification; the first is application-level methods that 1536 protect data (Section 6.1) and metadata (Section 6.2); the second is 1537 reduction of the QUIC packet attack surface by means of removal of 1538 many frame types (Section 4.10 and Section 5.7). 1540 11.2. Protection of Discovery Mechanism 1542 Multicast QUIC session advertisements SHOULD be conveyed over a 1543 secure transport that guarantees authenticity and integrity in order 1544 to mitigate attacks related to a malicious service advertisement, for 1545 example a "man in the middle" directing endpoints to a service that 1546 may lead to other attacks or exploitations. 1548 *Authors' Note:* We invite review comments on mandating the use of 1549 a secure transport for advertising sessions. 1551 Endpoints that make use of multicast QUIC session advertisements 1552 SHOULD have reasonable assurance that the alternative service is 1553 under control of, and valid for, the whole origin, as described in 1554 Section 2.1 of [RFC7838]. Section 6.2 discusses measures that may be 1555 used to fulfil this requirement. 1557 11.3. Spoofing 1559 11.3.1. Spoofed Ack Attacks 1561 The Spoofed "ACK" attack described in Section 13.1 of 1562 [QUIC-TRANSPORT] is out of scope because use of the QUIC "ACK" frame 1563 is prohibited (Section 4.9) by the present document. 1565 11.3.2. Sender Spoofing 1567 A malicious actor may be able to stage a spoof attack by sending fake 1568 QUIC packets to a multicast QUIC session. This could affect the 1569 operation or behaviour of receivers. In a multicast scenario, this 1570 form of attack has the potential to scale massively. 1572 The feasibility of spoofing a multicast sender is governed by the 1573 characteristics of the multicast deployment and network 1574 infrastructure. The use of source-specific multicast [RFC4607] may 1575 reduce the feasibility. The use of content authenticity 1576 (Section 6.2) may mitigate concerns for the application-level 1577 messages. However, there remains the possibility for transport-level 1578 messages to be spoofed. Multicast applications should consider 1579 further mitigations to address this concern. 1581 11.3.3. Receiver Spoofing 1583 Client source address concerns discussed in Section 7.5 of 1584 [QUIC-TRANSPORT] are out of scope because the connection 1585 establishment is replaced with session establishment in the present 1586 document. Further, the impact that spoofed receivers would have on 1587 the sender is minimal. The impact of malicious participants on the 1588 network is discussed in Section 11.6.2. 1590 11.4. Replay Attacks 1592 Conventional QUIC strategies for protecting against replay attacks 1593 apply similarly here. 1595 Certain multicast QUIC sessions may use a shared key for transport- 1596 level encryption, which would allow an attacker to record, decrypt, 1597 repackage and replay QUIC packets. Section 6.2 discusses how the 1598 application-level contents may be protected from replay (by signing 1599 the "Date" HTTP header), which provides some mitigation to the 1600 success rate or effects of replay attacks. 1602 11.5. Message Deletion 1604 Since HTTP over multicast QUIC is designed to tolerate unreliable 1605 delivery, the impacts of message deletion attacks are presumed to be 1606 small. Deletion of packets carrying HTTP headers will cause a 1607 receiver to ignore subsequent packets carrying body data. 1608 Furthermore, the use of multicast QUIC sessions is opportunistic; 1609 disruption in service (for example, deleting packets and causing a 1610 receiver to fail in construction of a content object) is mitigated by 1611 falling back to a unicast service. Considerations for how this may 1612 affect the performance of the unicast service are given in 1613 Section 11.6.3. 1615 11.6. Denial of Service 1616 11.6.1. Unprotected Frames and Packets 1618 The handling of unprotected QUIC packets is discussed in section 1619 9.1.4 of [QUIC-TLS]. The profile described in the present document 1620 provides the means for a multicast sender to protect QUIC packets 1621 with a shared key, which is not a strong protection. The weak 1622 protection of QUIC packets could present a denial-of-service risk. 1623 To mitigate the impact of handling such QUIC packets, certain frames 1624 and packets are prohibited as described in (Section 4.10 and 1625 Section 5.7). 1627 The frame types that are allowed by this profile do not present a 1628 risk of denial of service. Concerns over authenticity and integrity 1629 are addressed by the application-layer protection mechanisms 1630 described in Section 6. 1632 11.6.2. Network Performance Degradation 1634 The possibility for malfunctioning or malicious participants to 1635 degrade the network is a broad issue and considered out of scope for 1636 this document. Guidelines and concerns discussed in UDP Best 1637 Practices [RFC8085] and other sources apply equally here. This 1638 specification does not preclude the use of network performance 1639 degradation mitigation solutions such as network circuit breakers. 1641 11.6.3. Unicast Repair Stampeding Herd 1643 Deployments that support the unicast repair mechanism described in 1644 Section 7.2 should be aware that a triggering of this behaviour 1645 (either deliberate, planned or unplanned) in a large population of 1646 multicast receivers may cause a stampeding herd of client requests to 1647 the unicast repair service. Service operators SHOULD mitigate the 1648 impact of stampeding herd on their deployment. 1650 11.7. Receiver Resource Usage 1652 The application of receiver-side validation, as defined in the 1653 present document and in [QUIC-TRANSPORT], adds some protection 1654 against allocating resource to the processing of bad data. 1656 11.8. Unicast Repair Information Leakage 1658 The unicast repair mechanism may lead to the leakage of user 1659 behaviour data. An attacker could gain insight into any receiver 1660 participating in a multicast QUIC session, for example by monitoring 1661 the TCP port of the unicast alternative. This alone is no worse than 1662 current abilities to monitor unicast interactions, for example 1663 observing the SNI field contained in a TLS ClientHello. The complete 1664 protection of unicast interactions is beyond the scope of this 1665 document. However, knowledge that a user (or group of users) has 1666 participated in a session is sensitive and may be obtained by 1667 correlation between with observable multicast and unicast traffic. 1669 To give an example, a malicious "man in the middle" could purposely 1670 cause all receivers to perform a unicast repair (by disrupting the 1671 QUIC traffic flow in some way). The disruption is untargeted and may 1672 be simple to orchestrate, but the correlation of user activity data, 1673 especially across a distributed repair service (e.g. a CDN), requires 1674 resources that may reduce the attractiveness of such an attack. 1676 The ability for an attacker to disrupt multicast QUIC sessions is 1677 mitigated by this profile (mainly the prohibition of frames and 1678 packets). Application-layer security measures described in Section 6 1679 reduce the feasibility further. 1681 Multicast receivers concerned about this form of leakage can 1682 eliminate this risk completely by disabling support for unicast 1683 repair, at the potential cost of reduced service quality. 1685 12. IANA Considerations 1687 12.1. Registration of Protocol Identification String 1689 This document creates a new registration for the identification of 1690 the HTTP over multicast QUIC protocol in the "Application-Layer 1691 Protocol Negotiation (ALPN) Protocol IDs" registry established by 1692 [RFC7301]. 1694 The "hqm" string identifies HTTP semantics expressed as HTTP mapped 1695 to a QUIC layer and carried over IP multicast: 1697 Protocol: Bulk data transport using HTTP over multicast QUIC 1699 Identification Sequence: 0x68 0x71 0x6D ("hqm") 1701 Specification: This document, Section 9 1703 This entry reserves an identifier that is not allowed to appear in 1704 TLS Application-Layer Protocol Negotiation. 1706 12.2. Registration of Alt-Svc parameters 1708 This document creates seven registrations for the identification of 1709 parameters for the "Hypertext Transfer Protocol (HTTP) Alt-Svc 1710 Parameter Registry" established by [RFC7838] 1711 (http://www.iana.org/assignments/tls-extensiontype-values/tls- 1712 extensiontype-values.xhtml#alpn-protocol-ids). 1714 12.2.1. Source Address 1716 Parameter name: source-address 1718 Specification: This document, Section 10.1 1720 12.2.2. Cipher Suite 1722 Parameter name: cipher-suite 1724 Specification: This document, Section 10.2.2 1726 12.2.3. Key 1728 Parameter name: key 1730 Specification: This document, Section 10.2.3 1732 12.2.4. Initialization Vector 1734 Parameter name: iv 1736 Specification: This document, Section 10.2.4 1738 12.2.5. Session Identifier 1740 Parameter name: session-id 1742 Specification: This document, Section 10.2.5 1744 12.2.6. Session Idle Timeout 1746 Parameter name: session-idle-timeout 1748 Specification: This document, Section 10.2.6 1750 12.2.7. Maximum Concurrent Resources 1752 Parameter name: max-concurrent-resources 1754 Specification: This document, Section 10.2.7 1756 12.2.8. Peak Flow Rate 1758 Parameter name: peak-flow-rate 1760 Specification: This document, Section 10.2.8 1762 12.2.9. Digest Algorithm 1764 Parameter name: digest-algorithm 1766 Specification: This document, Section 10.2.9 1768 12.2.10. Signature Algorithm 1770 Parameter name: signature-algorithm 1772 Specification: This document, Section 10.2.10 1774 13. References 1776 13.1. Normative References 1778 [I-D.cavage-http-signatures] 1779 Cavage, M. and M. Sporny, "Signing HTTP Messages", draft- 1780 cavage-http-signatures-09 (work in progress), November 1781 2017. 1783 [QUIC-HTTP] 1784 Bishop, M., Ed., "Hypertext Transfer Protocol (HTTP) over 1785 QUIC", draft-ietf-quic-http-09 (work in progress). 1787 [QUIC-TRANSPORT] 1788 Iyengar, J., Ed. and M. Thomson, Ed., "QUIC: A UDP-Based 1789 Multiplexed and Secure Transport", draft-ietf-quic- 1790 transport-09 (work in progress). 1792 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 1793 Requirement Levels", BCP 14, RFC 2119, 1794 DOI 10.17487/RFC2119, March 1997, . 1797 [RFC3230] Mogul, J. and A. Van Hoff, "Instance Digests in HTTP", 1798 RFC 3230, DOI 10.17487/RFC3230, January 2002, 1799 . 1801 [RFC4607] Holbrook, H. and B. Cain, "Source-Specific Multicast for 1802 IP", RFC 4607, DOI 10.17487/RFC4607, August 2006, 1803 . 1805 [RFC5234] Crocker, D., Ed. and P. Overell, "Augmented BNF for Syntax 1806 Specifications: ABNF", STD 68, RFC 5234, 1807 DOI 10.17487/RFC5234, January 2008, . 1810 [RFC7230] Fielding, R., Ed. and J. Reschke, Ed., "Hypertext Transfer 1811 Protocol (HTTP/1.1): Message Syntax and Routing", 1812 RFC 7230, DOI 10.17487/RFC7230, June 2014, 1813 . 1815 [RFC7233] Fielding, R., Ed., Lafon, Y., Ed., and J. Reschke, Ed., 1816 "Hypertext Transfer Protocol (HTTP/1.1): Range Requests", 1817 RFC 7233, DOI 10.17487/RFC7233, June 2014, 1818 . 1820 [RFC7234] Fielding, R., Ed., Nottingham, M., Ed., and J. Reschke, 1821 Ed., "Hypertext Transfer Protocol (HTTP/1.1): Caching", 1822 RFC 7234, DOI 10.17487/RFC7234, June 2014, 1823 . 1825 [RFC7301] Friedl, S., Popov, A., Langley, A., and E. Stephan, 1826 "Transport Layer Security (TLS) Application-Layer Protocol 1827 Negotiation Extension", RFC 7301, DOI 10.17487/RFC7301, 1828 July 2014, . 1830 [RFC7405] Kyzivat, P., "Case-Sensitive String Support in ABNF", 1831 RFC 7405, DOI 10.17487/RFC7405, December 2014, 1832 . 1834 [RFC7838] Nottingham, M., McManus, P., and J. Reschke, "HTTP 1835 Alternative Services", RFC 7838, DOI 10.17487/RFC7838, 1836 April 2016, . 1838 [RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC 1839 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, 1840 May 2017, . 1842 13.2. Informative References 1844 [I-D.bishop-quic-http-and-qpack] 1845 Bishop, M., "Header Compression for HTTP/QUIC", draft- 1846 bishop-quic-http-and-qpack-07 (work in progress), December 1847 2017. 1849 [I-D.krasic-quic-qcram] 1850 Krasic, C., "Header Compression for HTTP over QUIC", 1851 draft-krasic-quic-qcram-04 (work in progress), January 1852 2018. 1854 [I-D.tikhonov-quic-qmin] 1855 Tikhonov, D., "QMIN: Header Compression for QUIC", draft- 1856 tikhonov-quic-qmin-00 (work in progress), November 2017. 1858 [QUIC-RECOVERY] 1859 Iyengar, J., Ed. and I. Swett, Ed., "QUIC Loss Detection 1860 and Congestion Control", draft-ietf-quic-recovery-09 (work 1861 in progress). 1863 [QUIC-TLS] 1864 Thomson, M., Ed. and S. Turner, Ed, Ed., "Using Transport 1865 Layer Security (TLS) to Secure QUIC", draft-ietf-quic- 1866 tls-09 (work in progress). 1868 [RFC1112] Deering, S., "Host extensions for IP multicasting", STD 5, 1869 RFC 1112, DOI 10.17487/RFC1112, August 1989, 1870 . 1872 [RFC1191] Mogul, J. and S. Deering, "Path MTU discovery", RFC 1191, 1873 DOI 10.17487/RFC1191, November 1990, . 1876 [RFC2460] Deering, S. and R. Hinden, "Internet Protocol, Version 6 1877 (IPv6) Specification", RFC 2460, DOI 10.17487/RFC2460, 1878 December 1998, . 1880 [RFC2974] Handley, M., Perkins, C., and E. Whelan, "Session 1881 Announcement Protocol", RFC 2974, DOI 10.17487/RFC2974, 1882 October 2000, . 1884 [RFC3261] Rosenberg, J., Schulzrinne, H., Camarillo, G., Johnston, 1885 A., Peterson, J., Sparks, R., Handley, M., and E. 1886 Schooler, "SIP: Session Initiation Protocol", RFC 3261, 1887 DOI 10.17487/RFC3261, June 2002, . 1890 [RFC3376] Cain, B., Deering, S., Kouvelas, I., Fenner, B., and A. 1891 Thyagarajan, "Internet Group Management Protocol, Version 1892 3", RFC 3376, DOI 10.17487/RFC3376, October 2002, 1893 . 1895 [RFC3550] Schulzrinne, H., Casner, S., Frederick, R., and V. 1896 Jacobson, "RTP: A Transport Protocol for Real-Time 1897 Applications", STD 64, RFC 3550, DOI 10.17487/RFC3550, 1898 July 2003, . 1900 [RFC3810] Vida, R., Ed. and L. Costa, Ed., "Multicast Listener 1901 Discovery Version 2 (MLDv2) for IPv6", RFC 3810, 1902 DOI 10.17487/RFC3810, June 2004, . 1905 [RFC4566] Handley, M., Jacobson, V., and C. Perkins, "SDP: Session 1906 Description Protocol", RFC 4566, DOI 10.17487/RFC4566, 1907 July 2006, . 1909 [RFC4821] Mathis, M. and J. Heffner, "Packetization Layer Path MTU 1910 Discovery", RFC 4821, DOI 10.17487/RFC4821, March 2007, 1911 . 1913 [RFC5737] Arkko, J., Cotton, M., and L. Vegoda, "IPv4 Address Blocks 1914 Reserved for Documentation", RFC 5737, 1915 DOI 10.17487/RFC5737, January 2010, . 1918 [RFC6676] Venaas, S., Parekh, R., Van de Velde, G., Chown, T., and 1919 M. Eubanks, "Multicast Addresses for Documentation", 1920 RFC 6676, DOI 10.17487/RFC6676, August 2012, 1921 . 1923 [RFC7258] Farrell, S. and H. Tschofenig, "Pervasive Monitoring Is an 1924 Attack", BCP 188, RFC 7258, DOI 10.17487/RFC7258, May 1925 2014, . 1927 [RFC7450] Bumgardner, G., "Automatic Multicast Tunneling", RFC 7450, 1928 DOI 10.17487/RFC7450, February 2015, . 1931 [RFC7541] Peon, R. and H. Ruellan, "HPACK: Header Compression for 1932 HTTP/2", RFC 7541, DOI 10.17487/RFC7541, May 2015, 1933 . 1935 [RFC8085] Eggert, L., Fairhurst, G., and G. Shepherd, "UDP Usage 1936 Guidelines", BCP 145, RFC 8085, DOI 10.17487/RFC8085, 1937 March 2017, . 1939 Appendix A. Acknowledgements 1941 The authors would like to thank the following for their contributions 1942 to the design described in the present document: Brandon Butterworth, 1943 Sam Hurst, Chris Poole, Craig Taylor and David Waring. 1945 We are also grateful to Thomas Swindells and Magnus Westerlund for 1946 their helpful review comments. 1948 Appendix B. Examples 1950 This appendix contains examples of multicast QUIC session 1951 advertisement and resource transfer (with and without application- 1952 layer content security). 1954 B.1. Session Advertisement 1956 This section shows several different examples of an HTTP service 1957 advertising a multicast QUIC session. Examples are given in IPv4 1958 form, using reserved address ranges as specified in [RFC5737] and 1959 [RFC6676]. 1961 B.1.1. Source-specific Multicast QUIC Session 1963 Advertisement of a multicast QUIC session operating on the source- 1964 specific multicast group address 232.0.0.1 on port 2000 with the 1965 source address 192.0.2.1. The session ID is 16 (0x10) and the idle 1966 timeout is one minute. At most 10 resources may be concurrently 1967 active in the session and the flow rate should not exceed 10 kbits/s. 1968 The multicast transport is unencrypted. 1970 HTTP Alternative Service header field: 1972 Alt-Svc: 1973 hqm="232.0.0.1:2000"; source-address="192.0.2.1"; quic=1; 1974 session-id=10; session-idle-timeout=60; 1975 max-concurrent-resources=10; peak-flow-rate=10000 1977 B.1.2. Source-specific Multicast QUIC Session with Transport Encryption 1978 using a Symmetric Key 1980 Advertisement of a multicast QUIC session operating on the IPv6 1981 globally-scoped source-specific multicast group address ff3e::1234 on 1982 port 2000 with the source address 2001:db8::1. The session ID is 16 1983 (0x10) and the idle timeout is one minute. At most 10 resources may 1984 be concurrently active in the session and the flow rate should not 1985 exceed 10 kbits/s. The multicast transport is encrypted using the 1986 AEAD cipher suite 0x13,0x01 ("TLS_AES_128_GCM_SHA256") with the 1987 shared session key and IV provided. 1989 HTTP Alternative Service header field: 1991 Alt-Svc: 1992 hqm="[ff3e::1234]:2000"; source-address="2001:db8::1"; quic=1; 1993 session-id=10; session-idle-timeout=60; 1994 max-concurrent-resources=10; peak-flow-rate=10000; 1995 cipher-suite=1301; key=4adf1eab9c2a37fd; iv=4dbe593acb4d1577ad6ba7dc3189834e 1997 B.1.3. Source-specific Multicast QUIC Session with Transport 1998 Encryption, Content Integrity and Authenticity 2000 Advertisement of a multicast QUIC session operating on the IPv6 2001 globally-scoped source-specific multicast group address ff3e::1234 on 2002 port 2000 with the source address 2001:db8::1. The session ID is 16 2003 (0x10) and the idle timeout is one minute. At most 10 resources may 2004 be concurrently active in the session and the flow rate should not 2005 exceed 10 kbits/s. The multicast transport is encrypted using the 2006 AEAD cipher suite 0x13,0x01 ("TLS_AES_128_GCM_SHA256") with the 2007 shared session key and IV provided. Content integrity is in use with 2008 the digest algorithm set restricted to SHA-256. Content authenticity 2009 is in use with the signature algorithm set restricted to rsa-sha256. 2011 HTTP Alternative Service header field: 2013 Alt-Svc: 2014 hqm="[ff3e::1234]:2000"; source-address="2001:db8::1"; quic=1; 2015 session-id=10; session-idle-timeout=60; 2016 max-concurrent-resources=10; peak-flow-rate=10000; 2017 cipher-suite=1301; key=4adf1eab9c2a37fd; iv=4dbe593acb4d1577ad6ba7dc3189834e 2018 digest-algorithm=SHA-256; signature-algorithm=rsa-sha256 2020 B.2. Resource Transfer 2022 This section shows several different examples of the HTTP message 2023 patterns for a single resource. 2025 Examples that show HTTP/QUIC "PUSH_PROMISE" or "HEADERS" frames 2026 describe the contents of enclosed header block fragments. 2028 B.2.1. Transfer without Content Integrity or Authenticity 2030 HTTP/QUIC "PUSH_PROMISE" frame: 2032 :method: GET 2033 :scheme: https 2034 :path: /files/example.txt 2035 :authority: example.org 2037 HTTP/QUIC "HEADERS" frame; 2039 :status: 200 2040 content-length: 100 2041 content-type: text/plain 2042 date: Fri, 20 Jan 2017 10:00:00 GMT 2044 HTTP/QUIC "DATA" frame containing 100 bytes of response body data: 2046 ... 2048 B.2.2. Transfer of Partial Content without Content Integrity or 2049 Authenticity 2051 In this example, partial content is transferred as described in 2052 Section 8. The "Range" request header is used to indicate the 2053 sender's original intention to transfer all 100 bytes of the 2054 representation. The "Content-Range" response header indicates that 2055 only the first 50 bytes were actually sent. 2057 HTTP/QUIC "PUSH_PROMISE" frame: 2059 :method: GET 2060 :scheme: https 2061 :path: /files/example.txt 2062 :authority: example.org 2063 range: bytes=0-* 2065 HTTP/QUIC "HEADERS" frame: 2067 :status: 206 2068 content-length: 100 2069 content-range: bytes 0-49/100 2070 content-type: text/plain 2071 date: Fri, 20 Jan 2017 10:00:00 GMT 2073 HTTP/QUIC "DATA" frame containing 50 bytes of response body data: 2075 ... 2077 B.2.3. Transfer with Content Integrity and without Authenticity 2079 In this example, content integrity is assured by the inclusion of the 2080 "Digest" response header, as described in Section 6.1. 2082 HTTP/QUIC "PUSH_PROMISE" frame: 2084 :method: GET 2085 :scheme: https 2086 :path: /files/example.txt 2087 :authority: example.org 2089 HTTP/QUIC "HEADERS" frame including the "Digest" header: 2091 :status: 200 2092 content-length: 100 2093 content-type: text/plain 2094 date: Fri, 20 Jan 2017 10:00:00 GMT 2095 digest: SHA-256=DieQ9zfRaDdyAilTVCvmBePuxMm+B6cNocP+QCrNSqo= 2097 HTTP/QUIC "DATA" frame containing 100 bytes of response body data: 2099 ... 2101 B.2.4. Partial Transfer with Content Integrity and without Authenticity 2103 In this example, partial content is transferred as described in 2104 Section 8. The "Range" request header is used to indicate the 2105 sender's intention to transfer all 100 bytes of the representation. 2106 The "Content-Range" response header indicates that only the first 50 2107 bytes were actually sent. Content integrity is assured by the 2108 inclusion of the "Digest" response header, as described in 2109 Section 6.1. 2111 HTTP/QUIC "PUSH_PROMISE" frame: 2113 :method: GET 2114 :scheme: https 2115 :path: /files/example.txt 2116 :authority: example.org 2117 range: bytes=0-* 2119 HTTP/QUIC "HEADERS" frame including the "Digest" header: 2121 :status: 206 2122 content-length: 100 2123 content-range: bytes 0-49/100 2124 content-type: text/plain 2125 date: Fri, 20 Jan 2017 10:00:00 GMT 2126 digest: SHA-256=DieQ9zfRaDdyAilTVCvmBePuxMm+B6cNocP+QCrNSqo= 2128 HTTP/QUIC "DATA" frame containing 50 bytes of response body data: 2130 ... 2132 B.2.5. Transfer with Content Integrity and Authenticity 2134 In this example, content integrity is assured by the inclusion of the 2135 "Digest" response header, as described in Section 6.1. Content 2136 authenticity is assured separately for the request and the response 2137 messages by the "Signature" header which protects the header fields 2138 described in further detail below. The "Signature" header parameter 2139 "keyId" contains the URL of a file containing the public key related 2140 to the multicast sender's private key used to create the digital 2141 signature. 2143 HTTP/QUIC "PUSH_PROMISE" frame including a "Signature" header 2144 protecting the ":method" and ":path" (the request target), as well as 2145 the ":scheme" and ":authority" of the pseudo-request: 2147 :method: GET 2148 :scheme: https 2149 :path: /files/example.txt 2150 :authority: example.org 2151 signature: keyId="https://example.org/mcast-sender.example.org.pem", 2152 algorithm=rsa-sha256, 2153 headers="(request-target) :scheme :authority", 2154 signature="MGQCMFTaFptaM2FhgzJq2i9AaChuFDHjp6GiXVtRnI8BsA" 2156 HTTP/QUIC "HEADERS" frame including a "Signature" header protecting 2157 the ":method", ":path", ":scheme" and ":authority" of the pseudo- 2158 request above, plus the "Date" and "Digest" of the response: 2160 :status: 200 2161 content-length: 100 2162 content-type: text/plain 2163 date: Fri, 20 Jan 2017 10:00:00 GMT 2164 digest: SHA-256=DieQ9zfRaDdyAilTVCvmBePuxMm+B6cNocP+QCrNSqo= 2165 signature: keyId="https://example.org/mcast-sender.example.org.pem", 2166 algorithm=rsa-sha256, 2167 headers="(request-target) :scheme :authority date digest", 2168 signature="MGUCMBgx6cuwTzg0W29zNUra8xfMsEcb3rFA3Y" 2170 HTTP/QUIC "DATA" frame containing response body data: 2172 ... 2174 B.2.6. Partial Transfer with Content Integrity and Authenticity 2176 In this example, partial content is transferred and the "Range" 2177 header (as described in Section 8) is used to indicate that 50 bytes 2178 out of 100 bytes were transferred. Content integrity is provided by 2179 the inclusion of the "Digest" header, as described in Section 6.1. 2180 Authenticity is provided by the "Signature" header which protects the 2181 header fields described in further detail. The "Signature" header 2182 parameter "keyId" contains the URL of a file containing the public 2183 key related to the multicast sender's private key used to create the 2184 digital signature. 2186 HTTP/QUIC "PUSH_PROMISE" frame: 2188 :method: GET 2189 :scheme: https 2190 :path: /files/example.txt 2191 :authority: example.org 2192 range: bytes=0-* 2193 signature: keyId="https://example.org/mcast-sender.example.org.pem", 2194 algorithm=rsa-sha256, 2195 headers="(request-target) :scheme :authority range", 2196 signature="MGQCMFTaFptaM2FhgzJq2i9AaChuFDHjp6GiXVtRnI8BsA" 2198 HTTP/QUIC "HEADERS" frame protecting the ":method", ":path", 2199 ":scheme" and ":authority" of the pseudo-request above, plus the 2200 "Date", "Digest" and "Content-Range" of the response: 2202 :status: 206 2203 content-length: 100 2204 content-range: bytes 0-49/100 2205 content-type: text/plain 2206 date: Fri, 20 Jan 2017 10:00:00 GMT 2207 digest: SHA-256=DieQ9zfRaDdyAilTVCvmBePuxMm+B6cNocP+QCrNSqo= 2208 signature: keyId="https://example.org/mcast-sender.example.org.pem", 2209 algorithm=rsa-sha256, 2210 headers="(request-target) :scheme :authority 2211 date digest content-range", 2212 signature="MGUCMBgx6cuwTzg0W29zNUra8xfMsEcb3rFA3Y" 2214 HTTP/QUIC "DATA" frame containing response body data: 2216 ... 2218 Appendix C. Summary of differences from unicast QUIC and HTTP/QUIC 2220 +----------------+-------------------------+------------------------+ 2221 | Protocol | Unicast QUIC | Multicast HTTP/QUIC | 2222 | feature | | profile | 2223 +----------------+-------------------------+------------------------+ 2224 | Stream ID 0 | Combined cryptography | Reserved Stream ID not | 2225 | | and transport handshake | used. | 2226 | | stream conveying TLS | | 2227 | | handshake messages in | | 2228 | | QUIC "STREAM" frames. | | 2229 | | | | 2230 | TLS cipher | Client's preferred | Cipher suite | 2231 | suite | cipher suite included | optionally advertised | 2232 | | in Client Hello | out of band via Alt- | 2233 | | message. | Svc "cipher-suite" | 2234 | | | parameter. Default | 2235 | | | cipher suite is | 2236 | | | "0x00,0x00 (NULL_WITH_ | 2237 | | | NULL_NULL)". | 2238 | | | | 2239 | TLS session | Session key included in | Session key optionally | 2240 | key | Server Hello message. | advertised out of band | 2241 | | | via Alt-Svc "key" | 2242 | | | parameter. | 2243 | | | | 2244 | TLS | Initialization vector | Initialization vector | 2245 | initialization | included in Server | optionally advertised | 2246 | vector | Hello message. | out of band via Alt- | 2247 | | | Svc "iv" parameter. | 2248 | | | | 2249 | Required QUIC | "idle_timeout" | Advertised out of band | 2250 | TransportParam | | via Alt-Svc "session- | 2251 | eter for idle | | idle-timeout" | 2252 | timeout | | parameter. | 2253 | | | | 2254 | Required QUIC | "initial_max_data" | Not Used. Peak flow | 2255 | TransportParam | | rate of a session | 2256 | eter for | | optionally advertised | 2257 | connection | | out of band via Alt- | 2258 | flow control | | Svc "peak-flow-rate" | 2259 | | | parameter. | 2260 | | | | 2261 | Required QUIC | "initial_max_stream_ | Not used. Peak flow | 2262 | TransportParam | data" | rate of a session | 2263 | eter for | | optionally advertised | 2264 | stream flow | | out of band via Alt- | 2265 | control | | Svc "peak-flow-rate" | 2266 | | | parameter. | 2267 | | | | 2268 | Required QUIC | "initial_max_stream_id_ | Not used. Maximum | 2269 | TransportParam | bidi" and "initial_max_ | concurrent resources | 2270 | eter for | stream_id_uni" | in a session | 2271 | stream | | optionally advertised | 2272 | concurrency | | out of band via Alt- | 2273 | | | Svc "max-concurrent- | 2274 | | | resources" parameter. | 2275 +----------------+-------------------------+------------------------+ 2277 Table 1: Cryptography and Transport Parameters 2279 +-------------+----------------+--------------------------------------+ 2280 | Protocol | Unicast QUIC | Multicast HTTP/QUIC profile | 2281 | feature | | | 2282 +-------------+----------------+--------------------------------------+ 2283 | Maximum | Determined by | Determined by path MTU discovery or | 2284 | packet size | path MTU | other heuristic. | 2285 | | discovery or | | 2286 | | other | | 2287 | | heuristic. | | 2288 | | | | 2289 | Version | Protocol | Not permitted. (No negotiation | 2290 | negotiation | version | possible in multicast context.) | 2291 | packet | negotiation | "VERSION" flag in QUIC packet header | 2292 | | between | must never be set. Protocol version | 2293 | | initiating | advertised out of band via Alt-Svc | 2294 | | client and | "quic" parameter. | 2295 | | server. | | 2296 | | | | 2297 | Public | Connection | Not permitted. (Potential denial-of- | 2298 | reset | reset. | service attack vector.) | 2299 | packet | | "PUBLIC_RESET" flag in QUIC packet | 2300 | | | header must never be set. | 2301 | | | | 2302 | Regular | Used to convey | Used to convey QUIC frames (see | 2303 | packet | QUIC frames | below). Only the short header form | 2304 | | (see below). | is permitted. | 2305 | | | | 2306 | Connection | Randomly | Redefined to be a multicast Session | 2307 | ID field | assigned by | ID. Value assigned by the multicast | 2308 | | initiating | sender. Connection ID field is | 2309 | | client and/or | present in all multicast QUIC | 2310 | | server. | packets. "CONNECTION_ID" flag in | 2311 | | Different | QUIC packet header must always be | 2312 | | Connection IDs | set. The same Session ID may span | 2313 | | may not be | several multicast groups. Different | 2314 | | multiplexed on | Session IDs may be multiplexed on | 2315 | | the same | the same 5-tuple source-specific | 2316 | | 5-tuple | multicast group and port. | 2317 | | network | | 2318 | | association? | | 2319 +-------------+----------------+--------------------------------------+ 2321 Table 2: QUIC Packet Layer 2323 +---------------------+-------------------------+---------------------+ 2324 | Protocol feature | Unicast QUIC | Multicast HTTP/QUIC | 2325 | | | profile | 2326 +---------------------+-------------------------+---------------------+ 2327 | "ACK" frame | Used by a receiver to | Prohibited. | 2328 | | acknowledge receipt of | | 2329 | | data from its peer. | | 2330 | | | | 2331 | "APPLICATION_CLOSE" | Notification (by either | Prohibited. | 2332 | frame | endpoint) of immediate | | 2333 | | connection closure. | | 2334 | | | | 2335 | "BLOCKED" frame | Notification to | Prohibited. | 2336 | | receiver that sender's | | 2337 | | transmission is blocked | | 2338 | | pending an update to | | 2339 | | its flow control window | | 2340 | | by peer. | | 2341 | | | | 2342 | "CONNECTION_CLOSE" | Notification (by either | Prohibited. Use | 2343 | frame | endpoint) of immediate | HTTP explicit | 2344 | | connection closure. | session tear-down | 2345 | | | instead (see | 2346 | | | HTTP/QUIC mapping | 2347 | | | below). | 2348 | | | | 2349 | "MAX_DATA" frame | Flow control update | Prohibited. | 2350 | | notification. | | 2351 | | | | 2352 | "MAX_STREAM_DATA" | Flow control update | Prohibited. | 2353 | frame | notification. | | 2354 | | | | 2355 | "MAX_STREAM_ID" | Used by an endpoint to | Prohibited. | 2356 | frame | inform a peer of the | | 2357 | | maximum stream ID that | | 2358 | | it is permitted to | | 2359 | | open. | | 2360 | | | | 2361 | "PADDING" frame | Used to pad out a QUIC | Permitted, but | 2362 | | packet with zero bytes. | wasteful of network | 2363 | | (The first packet sent | capacity. | 2364 | | on a connection must be | | 2365 | | at least 1200 bytes | | 2366 | | long to prove that the | | 2367 | | network can transmit | | 2368 | | packets of at least | | 2369 | | this size.) | | 2370 | | | | 2371 | "PING" frame | Used by an endpoint to | Used by the | 2372 | | verify that its peer is | multicast sender as | 2373 | | still alive. | a session keep- | 2374 | | Acknowledged using | alive notification. | 2375 | | "PING" or "PONG" | "PING" with data is | 2376 | | | prohibited. Never | 2377 | | | acknowledged. | 2378 | | | | 2379 | "PONG" frame | Sent in response to a | Prohibited. | 2380 | | PING frame that | | 2381 | | contains data. | | 2382 | | | | 2383 | "RST_STREAM" frame | Request by receiver for | Indication to | 2384 | | sender to terminate a | receivers that the | 2385 | | stream transmission | multicast sender | 2386 | | prematurely. | has prematurely | 2387 | | | terminated a stream | 2388 | | | transmission. It is | 2389 | | | prohibited for | 2390 | | | receivers to send. | 2391 | | | | 2392 | "STREAM" frame | Conveys application- | Conveys | 2393 | | layer payloads (see | application-layer | 2394 | | HTTP/QUIC mapping | payloads (see | 2395 | | below). | HTTP/QUIC mapping | 2396 | | | below). | 2397 | | | | 2398 | "FIN" bit on | Indication by sender to | Indication by the | 2399 | "STREAM" frame | its peer that a stream | multicast sender | 2400 | | transmission has | that a stream | 2401 | | finished. | transmission has | 2402 | | | finished. | 2403 | | | | 2404 | "STREAM_BLOCKED" | Notification to | Prohibited. | 2405 | frame | receiver that sender's | | 2406 | | transmission is blocked | | 2407 | | pending an update to | | 2408 | | its flow control window | | 2409 | | by peer. | | 2410 | | | | 2411 | "STREAM_ID_BLOCKED" | Used when a sender | Prohibited. | 2412 | frame | wishes to open a stream | | 2413 | | but is unable to do so | | 2414 | | because of the maximum | | 2415 | | stream ID. | | 2416 +---------------------+-------------------------+---------------------+ 2418 Table 3: QUIC Framing Layer 2420 +----------------+------------------+-------------------------------+ 2421 | Protocol | Unicast | Multicast HTTP/QUIC profile | 2422 | feature | HTTP/QUIC | | 2423 +----------------+------------------+-------------------------------+ 2424 | "ALTSVC" frame | Signalling | Prohibited. | 2425 | | alternative | | 2426 | | service for | | 2427 | | HTTP/QUIC | | 2428 | | session. | | 2429 | | | | 2430 | "CANCEL_PUSH" | Used to request | Permitted only for senders. | 2431 | frame | cancellation of | | 2432 | | server push | | 2433 | | prior to the | | 2434 | | push stream | | 2435 | | being created. | | 2436 | | | | 2437 | "DATA" frame | Carriage of HTTP | Carriage of HTTP response | 2438 | | request/response | message body. | 2439 | | message body. | | 2440 | | | | 2441 | "GOAWAY" frame | Early | Prohibited. Use HTTP explicit | 2442 | | notification (by | session tear-down instead. | 2443 | | either endpoint) | | 2444 | | of future | | 2445 | | connection | | 2446 | | closure, | | 2447 | | allowing for | | 2448 | | orderly | | 2449 | | completion of | | 2450 | | open streams. | | 2451 | | | | 2452 | "HEADERS" | Carriage of HTTP | Carriage of HTTP response | 2453 | frame | request/response | message metadata. Trailing | 2454 | | message | HEADERS frame is permitted. | 2455 | | metadata. | | 2456 | | Trailing HEADERS | | 2457 | | frame is | | 2458 | | permitted. | | 2459 | | | | 2460 | "MAX_PUSH_ID" | Used by a | Prohibited. | 2461 | frame | receiver to | | 2462 | | control the | | 2463 | | number of server | | 2464 | | pushes that a | | 2465 | | sender can | | 2466 | | initiate. | | 2467 | | | | 2468 | "PRIORITY" | Dynamic | Prohibited. | 2469 | frame | adjustment of | | 2470 | | stream priority. | | 2471 | | | | 2472 | "PUSH_PROMISE" | Carriage of HTTP | Carriage of HTTP pseudo- | 2473 | frame | pseudo-request | request message metadata. All | 2474 | | message | HTTP representation transfers | 2475 | | metadata. | over multicast begin this | 2476 | | | way. Stream ID of the first | 2477 | | | client-initiated | 2478 | | | bidirectional stream is | 2479 | | | reserved and all PUSH_PROMISE | 2480 | | | frames reference this as the | 2481 | | | client request from which | 2482 | | | they are notionally derived. | 2483 | | | This stream remains open | 2484 | | | while a sender is | 2485 | | | participating in the | 2486 | | | multicast QUIC session. | 2487 | | | | 2488 | "SETTINGS" | Negotiation of | Prohibited. | 2489 | frame | HTTP/QUIC | | 2490 | | connection | | 2491 | | settings. | | 2492 | | | | 2493 | HTTP/QUIC | | Prohibited. | 2494 | extension | | | 2495 | frames | | | 2496 +----------------+------------------+-------------------------------+ 2498 Table 4: HTTP/QUIC Mapping 2500 +-------------+----------------------------------+------------------+ 2501 | Protocol | Unicast HTTP/QUIC | Multicast | 2502 | feature | | HTTP/QUIC | 2503 | | | profile | 2504 +-------------+----------------------------------+------------------+ 2505 | Huffman | Header blocks may use Huffman | Header blocks | 2506 | string | codes to compress literal string | may use Huffman | 2507 | compression | values. | codes to | 2508 | | | compress literal | 2509 | | | string values. | 2510 | | | | 2511 | Static | Header blocks may refer to | Header blocks | 2512 | table | indexed entries in the static | may refer to | 2513 | | table. | indexed entries | 2514 | | | in the static | 2515 | | | table. | 2516 | | | | 2517 | Dynamic | Header blocks may insert entries | Prohibited, size | 2518 | table | into the dynamic table and | is currently | 2519 | | subsequent header blocks may | locked to 0. | 2520 | | refer to their indexes. Unused | | 2521 | | as size is currently locked to | | 2522 | | 0. | | 2523 +-------------+----------------------------------+------------------+ 2525 Table 5: HTTP Metadata Compression Layer 2527 Appendix D. Changelog 2529 *RFC Editor's Note:* Please remove this section prior to 2530 publication of a final version of this document. 2532 D.1. Since draft-pardue-quic-http-mcast-01 2534 o Explicit guidance on maximum stream ID value permitted. 2536 o Updated guidance on PING (and PONG) frame. 2538 o Added a comparison table to appendix. 2540 o Remove invalid use of trailing headers. 2542 o Use the new HTTP/QUIC DATA frame. 2544 o Prohibit APPLICATION CLOSE frame, and move GOAWAY frame to HTTP/ 2545 QUIC section. 2547 o Redefine server push to reflect core document changes. 2549 o Remove default idle time out value. 2551 o Clarify session parameter requirements (session-idle-timeout 2552 became mandatory). 2554 o Update frame notation convention. 2556 D.2. Since draft-pardue-quic-http-mcast-00 2558 o Update references to QUIC I-Ds. 2560 o Relax session leaving requirements language. 2562 o Clarify handling of omitted session parameter advertisements. 2564 o Rename "Idle" state to "Quiescent". 2566 o Add digest algorithm session parameter. 2568 o Add signature algorithm session parameter. 2570 o Add Initialization Vector session parameter. 2572 o Replace COPT tag-value-pairs with TransportParameter values. 2574 o Add example of an advertisement for a session with content 2575 authenticity and integrity. 2577 Authors' Addresses 2579 Lucas Pardue 2580 BBC Research & Development 2582 Email: lucas.pardue@bbc.co.uk 2584 Richard Bradbury 2585 BBC Research & Development 2587 Email: richard.bradbury@bbc.co.uk