idnits 2.17.00 (12 Aug 2021) /tmp/idnits14625/draft-pardue-quic-http-mcast-03.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 (August 6, 2018) is 1384 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-10 == Outdated reference: A later version (-34) exists of draft-ietf-quic-http-08 == Outdated reference: draft-ietf-quic-transport has been published as RFC 9000 == Outdated reference: draft-ietf-quic-recovery has been published as RFC 9002 == Outdated reference: draft-ietf-quic-tls has been published as RFC 9001 -- Obsolete informational reference (is this intentional?): RFC 2460 (Obsoleted by RFC 8200) -- Obsolete informational reference (is this intentional?): RFC 4566 (Obsoleted by RFC 8866) Summary: 2 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: February 7, 2019 August 6, 2018 7 Hypertext Transfer Protocol (HTTP) over multicast QUIC 8 draft-pardue-quic-http-mcast-03 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 https://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 February 7, 2019. 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 (https://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-02 . . . . . . . . . . 54 176 D.2. Since draft-pardue-quic-http-mcast-01 . . . . . . . . . . 54 177 D.3. Since draft-pardue-quic-http-mcast-00 . . . . . . . . . . 55 178 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 55 180 1. Introduction 182 The means to bulk transfer resources over multicast IP [RFC1112] 183 using HTTP semantics presents an opportunity to more efficiently 184 deliver services at scale, while leveraging the wealth of existing 185 HTTP-related standards, tools and applications. Audio-visual 186 segmented media, in particular, would benefit from this mode of 187 transmission. 189 The carriage of HTTP over multicast IP may be satisfied using 190 existing technologies, for example the Real-time Transport Protocol 191 (RTP) [RFC3550]. However, such protocols typically require the 192 translation or encapsulation of HTTP. This introduces concerns for 193 providers of services, such as defining the translation, additional 194 workload, complication of workflows, manageability issues, versioning 195 issues, and so on. 197 In contrast, this document describes a simpler and more direct 198 expression of HTTP semantics over multicast IP. HTTP over multicast 199 QUIC is a profile of the QUIC protocol [QUIC-TRANSPORT] (Section 4) 200 and the HTTP/QUIC mapping [QUIC-HTTP] (Section 5). This includes the 201 repurposing of certain QUIC packet fields and changes to some 202 protocol procedures (e.g. prohibition of the usage of certain frame 203 types) which, in turn, change the behavioural expectations of 204 endpoints. However, the profile purposely limits the scope of change 205 in order to preserve maximum compatibility with conventional QUIC. 206 For the reader's convenience, the differences between this 207 specification and conventional QUIC are summarised in Appendix C. 209 This profile prohibits the transmission of QUIC packets from receiver 210 to sender via multicast IP. The use of side-channel or out-of-band 211 feedback mechanisms is not prohibited by this specification, but is 212 out of scope and these are not considered further by the present 213 document. 215 Experience indicates that a generally available multicast deployment 216 is difficult to achieve on the Internet notwithstanding the 217 improvements that IPv6 [RFC2460] makes in this area. There is 218 evidence that discretely referenced multicast "islands" can more 219 pragmatically be deployed. Discovery of such islands by receivers, 220 as they become available, is typically difficult, however. To 221 address the problem, this document describes an HTTP-based discovery 222 mechanism that uses HTTP Alternative Services [RFC7838] to advertise 223 the existence of multicast QUIC sessions (Section 3). This provides 224 the means for multicast-capable endpoints to learn about and make use 225 of them in an opportunistic and user-imperceptible manner. This 226 mechanism results in a common HTTP application layer for both the 227 discovery and delivery of services across unicast and multicast 228 networks. This provides support for users and devices accessing 229 services over a heterogeneous network. This is a departure from 230 conventional multicast discovery technologies such as SDP [RFC4566] 231 and SAP [RFC2974]. 233 The discovery mechanism also addresses some of the issues related to 234 using QUIC over a unidirectional network association by replacing 235 connection establishment aspects that depend on a bidirectional 236 transport. 238 The present document includes a number of optional features. It is 239 anticipated that further specifications will define interoperability 240 profiles suited to particular application domains. 242 1.1. Notational Conventions 244 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 245 "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and 246 "OPTIONAL" in this document are to be interpreted as described in BCP 247 14 [RFC2119] [RFC8174] when, and only when, they appear in all 248 captials, as shown here. 250 This document uses the Augmented BNF defined in [RFC5234] and updated 251 by [RFC7405] along with the "#rule" extension defined in Section 7 of 252 [RFC7230]. The rules below are defined in [RFC5234], [RFC7230], and 253 [RFC7234]: 255 o quoted-string = 257 o token = 259 o uri-host = 261 1.2. Definitions 263 Definitions of terms that are used in this document: 265 o endpoint: A host capable of being a participant in a multicast 266 QUIC session. 268 o multicast QUIC session: A logical unidirectional flow of metadata 269 and data over multicast IP, framed according to this 270 specification. The lifetime of a session is independent of any 271 endpoint. 273 o participant: A sender or receiver that is taking part in a 274 multicast QUIC session. 276 o sender: A participant sending multicast traffic according to this 277 specification. 279 o receiver: A participant receiving multicast traffic according to 280 this specification. 282 o session: See multicast QUIC session. 284 o session ID: The identifier for a multicast QUIC session. 286 o session parameter: Characteristic of a multicast QUIC session. 288 2. Multicast QUIC Sessions 290 An HTTP/QUIC connection [QUIC-TRANSPORT] carried over bidirectional 291 unicast is defined as a conversation between two QUIC endpoints that 292 multiplexes several logical streams within a single encryption 293 context. This is a one-to-one relationship. Furthermore, QUIC 294 connections achieve decoupling from the underlying network (IP and 295 port) by means of a Connection ID. Use of a consistent connection 296 identifier allows QUIC connections to survive changes to the network 297 connectivity. The establishment of a QUIC connection relies upon an 298 up-front, in-band exchange (and possible negotiation) of 299 cryptographic and transport parameters (conveyed in QUIC handshake 300 messages) and HTTP-specific settings (conveyed in HTTP/QUIC 301 "SETTINGS" frames). Such parameters may be required or optional and 302 may be used by either endpoint to control the characteristics of 303 connection usage. 305 This concept of a connection does not suit the carriage of HTTP/QUIC 306 over unidirectional network associations such as multicast IP. In 307 fact, there is no requirement for either endpoint (multicast sender 308 or receiver) to be in existence in order for the other to start or 309 join this one-sided conversation. The term "connection" is 310 misleading in this context; therefore we introduce an alternative 311 term "multicast QUIC session" or simply "session", which is defined 312 as the logical entity describing the characteristics of the 313 anticipated unidirectional flow of metadata and data. Such 314 characteristics are expressed as "session parameters", described in 315 Section 2.2. Advertisement of multicast QUIC sessions, specified in 316 Section 3, allows for the senders and receivers to discover a session 317 and to form multicast IP network associations that permit traffic 318 flow. 320 2.1. Session States 322 The lifecycle of a multicast QUIC session is decoupled from the 323 lifecycle of any particular endpoint. Multicast receivers or senders 324 that take part in a session are called participants. The state of a 325 session is influenced by the actions of participants. The loose 326 coupling of participants means that they are unlikely to have a 327 consistent shared view of the current state of a session. There is 328 no requirement for a participant to know the session state and the 329 present document does not define a method to explicitly determine it. 330 The definitions of session states provided below are intended to 331 assist higher-level operational treatment of sessions: 333 o Quiescent: the session has no participants and is ready to accept 334 them. 336 o Half-established: the session has a participant. 338 o Fully-established: the session has a sender and at least one 339 receiver participant. 341 o Finished: the session has ended, and there are no participants. 343 Permitted states transitions are shown in Figure 1 below. 345 The transmission of QUIC packets is expected to occur only during the 346 Half-Established and Fully-Established states. 348 +-----------+ +------------------+ +-------------------+ 349 | |-------->| |------->| | 350 | Quiescent | | Half-Established | | Fully-Established | 351 | |<--------| |<-------| | 352 +-----------+ +------------------+ +-------------------+ 353 | | 354 | v 355 | +----------+ 356 | | | 357 +------------------>| Finished | 358 | | 359 +----------+ 361 Figure 1: Multicast QUIC session states 363 2.1.1. Session Establishment 365 A session begins in the Quiescent state. A typical session 366 establishment sequence would see the transition from Quiescent to 367 Half-Established when a sender joins the session. The transition 368 from Half-Established to Fully-Established occurs when at least one 369 receiver joins the session. 371 It is equally valid for a receiver to join a session in the Quiescent 372 state, triggering the transition to Half-Established. In this case, 373 the transition to Fully-Established takes place only when a sender 374 joins the session. 376 2.1.2. Session Termination 378 A session enters the Finished state when all participants leave it. 379 The methods for leaving a session are either explicit shutdown 380 (Section 5.5), implicit shutdown (i.e. idle timeout, Section 3.4) or 381 migration away (described in the next section). 383 In a typical case, a session that is in the Fully-Established state 384 would be closed in two stages. In the first stage the sender sends 385 explicit shutdown messages to the multicast group and subsequently 386 stops transmitting packets. This causes the session to transition 387 from Fully-Established to Half-Established. In the second stage, 388 receivers that have received explicit shutdown messages leave the 389 multicast group. Once all receivers have left the session it 390 transitions from Half-Established to Finished. 392 The transition from Quiescent to Finished could also occur in 393 response to out-of-band actions, for example the availability of a 394 session being withdrawn without any participants having made use of 395 it. 397 2.1.3. Session Migration 399 Endpoints MAY migrate between multicast QUIC sessions (for example, 400 to make use of alternate session parameters that are preferred). 401 Session migration requires participants to leave the current session 402 and join the new session. These actions affect the state of the 403 respective sessions as explained above. 405 The discovery of multicast QUIC sessions is described in Section 3. 407 2.2. Session Parameters 409 The characteristics of multicast QUIC sessions are expressed as 410 session parameters, which cover cryptographic and transport 411 parameters, HTTP-specific settings and multicast-specific 412 configuration. 414 Session parameter exchange over IP multicast is difficult: 416 o In-band exchanges are one-way, and so the client does not have the 417 means to send session parameters. 419 o The lifecycle of any multicast sender is independent of the 420 multicast receiver. It is therefore unlikely that all receivers 421 will have joined a session in time to receive parameters sent at 422 the start of a multicast session. 424 A range of strategies exists to mitigate these points. However, each 425 has the possibility to add complexity to deployment and 426 manageability, transmission overhead, or other such concerns. This 427 document defines a solution that relies on the one-way announcement 428 of session parameters in advance of session establishment. This is 429 achieved using HTTP Alternative Services [RFC7838] and is explained 430 in Section 3. Other advertisement solutions are not prohibited but 431 are not explored in this document. 433 Session parameters MUST NOT change during the lifetime of a session. 434 This restriction also applies to HTTP-level settings (see 435 Section 5.1). 437 2.3. Session Identification 439 This document defines a 64-bit session identifier used to identify a 440 session. This "Session ID" affords independence from multicast IP, 441 creating the possibility for a session to span multiple multicast 442 groups, or to migrate a session to a different multicast group. 443 Assignment of Session ID is considered out of this document's scope. 445 The Session ID is carried in the Connection ID field of the QUIC 446 packet (see Section 4.3). 448 A multicast sender participating in a session MUST send QUIC packets 449 with a matching Session ID. A multicast receiver participating in a 450 session MUST validate that the Session ID of received QUIC packets 451 matches that advertised in the session parameters (Section 3, 452 Section 10.2) before any HTTP-level processing is done. In the case 453 of validation failure, the receiver SHOULD ignore the packet in order 454 to protect itself from denial-of-service attacks. 456 2.4. Session Security 458 *Authors' Note:* Security handshake (as described in WG documents) 459 is in flux. This section will track developments and will be 460 updated accordingly. 462 The QUIC cryptographic handshake ([QUIC-TRANSPORT] and [QUIC-TLS]) 463 sets out methods to achieve the goals of authenticated key exchange 464 and QUIC packet protection between two endpoints forming a QUIC 465 connection. The design facilitates low-latency connection; 1-RTT or 466 0-RTT. QUIC Stream 0 is reserved for handshake messages. 468 This specification replaces the in-band security handshake, achieving 469 similar goals through the use of session parameters described in 470 Section 3.2. For the purpose of compatibility, the use of QUIC 471 stream 0 (see Section 4.4) is reserved. 473 Integrity and authenticity concerns are addressed in Section 6.1 and 474 Section 6.2 respectively. In order to protect themselves from attack 475 vectors, endpoints SHOULD NOT participate in sessions for which they 476 cannot establish reasonable confidence over the cipher suite or key 477 in use for that session. Participants MAY leave any session that 478 fails to successfully match anticipated security characteristics. 480 3. Session Advertisement 482 In this specification, connection negotiation is replaced with a 483 session advertisement mechanism based on HTTP Alternative Services 484 (Alt-Svc) [RFC7838]. This document specifies how the parameters of a 485 multicast QUIC session are expressed as Alt-Svc parameters. The 486 following sections provide a high-level view of these; further 487 details are provided in Section 10.2, with examples provided in 488 Appendix B.1. QUIC connection parameters not defined as, or related 489 to, Alt-Svc parameters are not used. 491 The definition of a session (including the session ID and its 492 parameters) is not the responsibility of any endpoint. Rather, 493 endpoints SHOULD use session advertisements to determine if they are 494 capable of participating in a given session. This document does not 495 specify which party is responsible for defining and/or advertising 496 multicast QUIC sessions. 498 Endpoints SHOULD NOT become participants in sessions where the 499 advertisement requirements set out in the present document are 500 unfulfilled. 502 The freshness of Alt-Svc multicast QUIC session advertisements is as 503 described in section 2.2 of [RFC7838]. 505 It is RECOMMENDED that session advertisements are carried over a 506 secure transport (such as HTTPS) which can guarantee the authenticity 507 and integrity of the Alt-Svc information. This addresses some of the 508 concerns around the protection of session establishment described in 509 Section 11.2. 511 *Authors' Note:* We invite review comments on mandating the use of 512 a secure transport for advertising sessions. 514 Senders MAY also advertise the availability of alternative sessions 515 by carrying Alt-Svc in a multicast QUIC session. 517 3.1. Version Advertisement 519 *Authors' Note:* Version negotiation (as described in WG 520 documents) is in flux. This section will track developments and 521 will be updated accordingly. 523 Conventional QUIC connection establishment begins with version 524 negotiation. In a unidirectional multicast environment, there is no 525 reasonable way to negotiate in such a manner. [QUIC-HTTP] defines an 526 Alt-Svc "quic" parameter that can be advertised to clients for use as 527 a version negotiation hint. This specification uses "quic" as a 528 session parameter for a similar purpose. This mechanism replaces the 529 use of the Version field in the QUIC packet long header (see 530 Section 4.2). 532 The Alt-Svc "quic" parameter is mandatory. Session advertisements 533 MUST contain exactly one instance of it and it MUST NOT be repeated. 535 A multicast sender participating in a session MUST send QUIC packets 536 and frames in the format corresponding to the advertised version. If 537 the sender does not support the advertised version it MUST NOT send 538 any data. A receiver MUST NOT join a session where the "quic" 539 parameter is absent. A receiver SHOULD NOT join a session for which 540 it does not support the advertised version, in order to avoid wasting 541 processing resources. 543 3.2. Security Context 545 *Authors' Note:* Security handshake (as described in WG documents) 546 is in flux. This section will track developments and will be 547 updated accordingly. 549 This specification replaces the in-band security handshake. The 550 session parameters "cipher suite", "key" and "iv" (described below) 551 allow for the establishment of a security context. In order to 552 protect themselves, endpoints SHOULD NOT participate in sessions for 553 which they cannot establish reasonable confidence over the cipher 554 suite, key, or IV in use for that session. Endpoints SHOULD leave 555 any sessions which fail to successfully match anticipated security 556 characteristics. 558 3.2.1. Cipher Suite 560 Cipher suite negotiation is replaced with a "cipher suite" session 561 parameter, which is advertised as the Alt-Svc parameter "cipher- 562 suite" (Section 10.2.2). 564 The Alt-Svc "cipher-suite" parameter is OPTIONAL. If present, this 565 parameter MUST contain only one value that corresponds to an entry in 566 the TLS Cipher Suite Registry (see http://www.iana.org/assignments/ 567 tls-parameters/tls-parameters.xhtml#tls-parameters-4). Session 568 advertisments that omit this parameter imply that the session is 569 operating with cipher suite 0x00,0x00 (NULL_WITH_NULL_NULL). 571 3.2.2. Key Exchange 573 Key exchange is replaced with a "key" session parameter, which is 574 advertised as the Alt-Svc parameter "key" (Section 10.2.3). The 575 parameter carries a variable-length hex-encoded key for use with the 576 session cipher suite. 578 The Alt-Svc "key" parameter is OPTIONAL. Session advertisments that 579 omit this parameter imply that the key may be available via an out- 580 of-band method not described in this document. 582 3.2.3. Initialization Vector 584 Initialization Vector (IV) exchange is replaced with an "iv" session 585 parameter, which is advertised as the Alt-Svc parameter "iv" 586 (Section 10.2.4). The parameter carries a variable-length hex- 587 encoded IV for use with the session cipher suite and key. 589 The Alt-Svc "iv" parameter is OPTIONAL. Session advertisments that 590 omit this parameter imply that the IV may be available via an out-of- 591 band method not described in this document. 593 3.3. Session Identification 595 [QUIC-TRANSPORT] specifies how the QUIC Connection ID is used, in 596 particular the client-side generation of this value. In a 597 unidirectional multicast environment, there is no meaningful way for 598 a client to generate a Connection ID and use it. This document 599 defines a "session identifier" session parameter, which is advertised 600 as the Alt-Svc parameter "session-id" (Section 10.2.5). The 601 requirements for the usage of session identifiers have already been 602 described in Section 2.3. 604 The Alt-Svc "session-id" parameter is mandatory. Session 605 advertisments MUST contain at least one instance. It MAY be repeated 606 with different values, indicating that multiple sessions are present. 608 *Authors' Note:* We invite review comments on mandating a single 609 session identifier per advertised session, i.e. only one session 610 identifier per ASM {G} or SSM {S,G}. 612 3.4. Session Idle Timeout 614 Conventional QUIC connections may be implicitly terminated following 615 a period of idleness (lack of network activity). The required QUIC 616 TransportParameter "idle_timeout" provides a means for endpoints to 617 specify the timeout period. This document defines a "session idle 618 timeout" session parameter, which is advertised as the Alt-Svc 619 parameter "session-idle-timeout" (Section 10.2.6). This session 620 parameter mimics the behaviour of "idle_timeout", providing a means 621 for multicast QUIC sessions to define their own idle timeout periods. 623 Session idle timeout may be prevented by keep-alive strategies 624 Section 4.8. 626 The Alt-Svc "session-idle-timeout" parameter is mandatory. Session 627 advertisments MUST contain at least one instance. If the parameter 628 is repeated the first occurrence MUST be used and subsequent 629 occurrences MUST be ignored. 631 Receiving participants SHOULD leave multicast QUIC sessions when the 632 session idle timeout period has elapsed (Section 4.7). Leaving 633 participants MUST use the silent close method, in which no QUIC 634 "CONNECTION_CLOSE" frame is sent. 636 3.5. Session Peak Flow Rate 638 [QUIC-TRANSPORT] specifies a credit-based stream- and connection- 639 level flow control scheme which prevents a fast sender from 640 overwhelming a slow receiver. Window size connection parameters are 641 exchanged on connection establishment using the required QUIC 642 TransportParameters "initial_max_data" and "initial_max_stream_data". 643 In a unidirectional multicast environment, such a scheme is 644 infeasible. This document defines a "peak flow rate" session 645 parameter, expressed in units of bits per second, which is advertised 646 as the Alt-Svc parameter "peak-flow-rate" (Section 10.2.8). This 647 replaces "initial_max_data" and "initial_max_stream_data" completely, 648 instead indicating the maximum bit rate of QUIC "STREAM" frame 649 payloads transmitted on all multicast groups comprising the session. 651 The Alt-Svc "peak-flow-rate" parameter is OPTIONAL. If the parameter 652 is repeated the first occurrence MUST be used and subsequent 653 occurrences MUST be ignored. Session advertisements that omit the 654 parameter imply that the flow rate is unlimited. 656 A multicast sender SHOULD NOT cause the advertised peak flow rate of 657 a session to be exceeded. A receiver MAY leave any session where the 658 advertised peak flow rate is exceeded. 660 3.6. Resource Concurrency 662 [QUIC-TRANSPORT] considers concurrency in terms of the number of 663 active incoming streams, which is varied by the receiving endpoint 664 adjusting the maximum Stream ID. The initial value of maximum Stream 665 ID is controlled by the relevant required QUIC TransportParameters 666 "initial_max_stream_id_bidi" and "initial_max_stream_id_uni". They 667 are increased during the lifetime of a QUIC connection by the QUIC 668 "MAX_STREAM_ID" frame. In a unidirectional multicast environment, 669 there is no way for a receiver to specify an initial limit nor 670 increase it. Therefore in multicast QUIC, the maximum Stream ID 671 (initial and always) is 2^62. This mechanism is not used to manage 672 concurrency in multicast QUIC. 674 Due to the profiling of maximum Stream ID, there is no role for the 675 QUIC "STREAM_ID_BLOCKED" frame and it is prohibited. Participants 676 MUST NOT send this frame type. Reception of this frame type MUST be 677 handled as described in Section 4.10. 679 This document specifies a "maximum concurrent resources" session 680 parameter, which is advertised as the Alt-Svc parameter "max- 681 concurrent-resources" (Section 10.2.7). This parameter replaces 682 "initial_max_stream_id_bidi" and "initial_max_stream_id_uni". It 683 advertises the maximum number of concurrent active resources 684 generated by a sender in a given multicast QUIC session. 686 The Alt-Svc "max-concurrent-resources" parameter is OPTIONAL. If the 687 parameter is repeated the first occurrence MUST be used and 688 subsequent occurrences MUST be ignored. Session advertisements that 689 omit the parameter imply that the maximum concurrency is unlimited. 691 A multicast sender participating in a session MUST NOT cause the 692 advertised "max-concurrent-resources" to be exceeded. A receiver MAY 693 leave any session where the advertised limit is exceeded, in order to 694 protect itself from denial-of-service attacks. 696 3.7. Additional TransportParameter Considerations 698 *Authors' Note:* This section will consider TransportParameters 699 that have not already been addressed, as required. It will track 700 developments and issues that may arise. 702 3.8. Digest Algorithm 704 A method to provide content integrity is described in Section 6.1. 705 This specifies the means to convey a value computed by a particular 706 digest algorithm. The identity of the selected algorithm is also 707 indicated. Valid digest algorithms are collected in the IANA HTTP 708 Digest Algorithm Values registry (http://www.iana.org/assignments/ 709 http-dig-alg/http-dig-alg.xhtml#http-dig-alg-1). 711 This document specifies a "digest algorithm" session parameter, which 712 is advertised as the Alt-Svc parameter "digest-algorithm" 713 (Section 10.2.9). 715 *Authors' Note:* Section 6.1 contains an author's note on the 716 potential for content integrity to become mandatory. This section 717 will be updated in line with the outcome of that decision. 719 The Alt-Svc "digest-algorithm" parameter is OPTIONAL. Repetition of 720 the "digest algorithm" parameter in a single advertisement describes 721 an algorithm set that MAY be used across the session. Session 722 advertisements that omit the Alt-Svc parameter "digest-algorithm" 723 imply that either: 725 o the session does not use the content integrity mechanism, or 727 o the algorithm set is unrestricted, i.e. a sender may vary the 728 algorithm as it so chooses. This may lead to undesirable results 729 if receivers do not support a chosen algorithm. 731 Advertising the algorithm set for a session gives receivers the 732 opportunity to selectively join sessions where the algorithms are 733 known to be supported. This may help to mitigate latency issues in 734 the receiver resulting from joining a session only to discover some 735 of its parameters are not supported. 737 A multicast sender participating in a session MUST NOT use algorithms 738 outside the signalled digest algorithm set. A receiver MAY leave any 739 session where an algorithm outside the digest algorithm set is used. 741 3.9. Signature Algorithm 743 A method to provide content authenticity is described in Section 6.2. 744 This specifies the means to convey a value computed by a particular 745 signature algorithm. The identity of the selected algorithm is also 746 indicated. Valid signature algorithms are collected in the IANA 747 Signature Algorithms registry (http://www.iana.org/assignments/ 748 signature-algorithms). 750 This document specifies a "signature algorithm" session parameter, 751 which is advertised as the Alt-Svc parameter "signature-algorithm" 752 (Section 10.2.10). 754 *Authors' Note:* Section 6.2 contains an author's note on the 755 potential for content authenticity to become mandatory. This 756 section will be updated in line with the outcome of that decision. 758 The Alt-Svc "signature-algorithm" parameter is OPTIONAL. Repetition 759 of the "signature algorithm" parameter in a single advertisement 760 describes an algorithm set that MAY be used across the session. 761 Session advertisements that omit the Alt-Svc parameter "signature- 762 algorithm" imply that either: 764 o the session does not use the content authenticity mechanism, or 766 o the algorithm set is unrestricted i.e. a sender may vary the 767 algorithm as it so chooses. This may lead to undesirable results 768 if receivers do not support a chosen algorithm. 770 Advertising the algorithm set for a session gives receivers the 771 opportunity to selectively join sessions where the algorithms are 772 known to be supported. This may help to mitigate latency issues in 773 the receiver resulting from joining a session only to discover some 774 of its parameters are not supported. 776 A multicast sender participating in a session MUST NOT use algorithms 777 outside the signalled signature algorithm set. A receiver MAY leave 778 any session where an algorithm outside the signature algorithm set is 779 used. 781 4. QUIC Profile 783 *Authors' Note:* The QUIC transport document is subject to change. 784 This section is based on our best understanding of draft-ietf- 785 quic-transport-08. The authors will track developments and will 786 update this section accordingly. 788 The profile of [QUIC-TRANSPORT] is presented in this section. In 789 order to preserve compatibility with conventional QUIC, the 790 specification works with a limited scope of change. However, the 791 nature of unidirectional multicast communications means that some 792 protocol procedures or behaviours need to be modified. 794 4.1. Packet Size 796 The means for determining an appropriate size for QUIC packets are 797 described in Section 9 of [QUIC-TRANSPORT]. Implementations of this 798 specification SHOULD bear in mind that the Path Maximum Transmission 799 Unit (PTMU) may be affected by multicast IP technologies such as 800 Automatic Multicast Tunneling (AMT) [RFC7450]. Additionally, 801 consideration should be given toward the applicability of maximum 802 transmission unit discovery methods (such as PLPMTUD [RFC4821] and 803 PMTUD [RFC1191]) to multicast IP. 805 4.2. Packet Format 807 Endpoints implementing this specification MUST only send QUIC packets 808 with the short header form. This header form omits the Version 809 field. 811 *Authors' Note:* The authors welcome suggestions for conveying the 812 QUIC version in every multicast QUIC packet. 814 4.3. Connection Identifier 816 The Connection ID field MUST be present in every QUIC packet, and the 817 corresponding flag in the packet header MUST be set to indicate that 818 the Connection ID field is present. 820 4.4. Stream Identifier 822 The maximum Stream ID of a multicast QUIC session is 2^62, as 823 explained in Section 3.6. 825 Senders MUST NOT send any QUIC frames on QUIC stream 0. Receivers 826 MUST ignore QUIC frames received on stream 0. 828 4.5. Flow Control 830 Conventional QUIC provides stream- and connection-level flow control, 831 and endpoints manage this by sending QUIC "MAX_DATA" or 832 "MAX_STREAM_DATA" frames as required. When a sender is blocked from 833 sending flow-controlled frames, it sends an informational QUIC 834 "BLOCKED" or "STREAM_BLOCKED" frame. 836 In a unidirectional environment, the sender never has a receive 837 window and the receiver cannot send in-band updates. Therefore, the 838 management of flow-control windows and transmission of blockage 839 information is not supported by this profile. The QUIC "MAX_DATA", 840 "MAX_STREAM_DATA", "BLOCKED" and "STREAM_BLOCKED" frames are 841 prohibited by this profile. Participants MUST NOT send these frame 842 types. Reception of these frame types MUST be handled as described 843 in Section 4.10. 845 4.6. Stream Termination 847 A sender MAY prematurely terminate the transmission on any unreserved 848 QUIC Stream ID by setting the "FIN" bit of a QUIC "STREAM" frame, or 849 by sending a QUIC "RST_STREAM" frame (as specified in 850 [QUIC-TRANSPORT] and [QUIC-HTTP]). 852 Receiving participants MUST NOT make any attempt to send QUIC 853 "RST_STREAM" frames to the multicast group. 855 4.7. Session Shutdown 857 Explicit shutdown of a multicast QUIC session using QUIC methods is 858 not supported by this profile. 860 The QUIC "APPLICATION_CLOSE" and "CONNECTION_CLOSE" frames, and the 861 Public Reset packet are prohibited. Participants MUST NOT send these 862 and reception MUST be handled as described in Section 4.10. 864 The HTTP/QUIC "GOAWAY" frame is prohibited. Participants MUST NOT 865 send this and reception MUST be handled as described in Section 5.7. 867 Explicit session tear-down using HTTP semantics is allowed, as 868 described in Section 5.5. 870 Implicit shutdown by means of silent close is also supported, as 871 described in Section 3.4. 873 4.8. Session Keep-alive 875 The flow of traffic in a multicast QUIC session is driven by a 876 sender. There may be periods where the sender has no application 877 data to send for a period longer than the session idle timeout. This 878 profile repurposes the QUIC "PING" frame to act as a unidirectional 879 keep-alive message that may be sent in order to inform receivers that 880 the session should remain in the Fully-established state. 881 [QUIC-TRANSPORT] contains guidance on the sending frequency of QUIC 882 "PING" frames. 884 Senders MAY send a QUIC "PING" frame with an empty Data field at any 885 time in order to inform receivers that the session traffic flow has 886 not fallen idle. This frame MUST NOT be acknowledged. Indeed, QUIC 887 "ACK" frames are prohibited by this profile (Section 4.9). 889 Senders MUST NOT send a QUIC "PING" frame with a populated Data 890 field. This effectively means that QUIC "PONG" frames are also 891 prohibited by this profile. 893 Receiving participants MUST NOT make any attempt to send QUIC "PING" 894 frames. 896 4.9. Loss Detection and Recovery 898 Receivers implementing this profile MUST NOT make any attempt to 899 acknowledge the reception of QUIC packets. The QUIC "ACK" frame is 900 prohibited for both senders and receivers. Reception of this frame 901 MUST be handled as described in Section 4.10. 903 Section 7 specifies alternative strategies for loss recovery. 905 4.10. Prohibited QUIC Frames and Packets 907 The following QUIC packets MUST NOT be transmitted by participants: 908 0-RTT Protected, 1-RTT Protected (key phase 0), 1-RTT Protected (key 909 phase 1), Client Cleartext, Client Initial, Public Reset, Server 910 Cleartext, Server Initial, Version Negotiation. 912 The following QUIC frames MUST NOT be transmitted by participants: 913 "ACK", "APPLICATION_CLOSE", "BLOCKED", "CONNECTION_CLOSE", 914 "MAX_DATA", "MAX_STREAM_ID", "MAX_STREAM_DATA", "PING" (with Data), 915 "PONG", "STREAM_BLOCKED", "STREAM_ID_BLOCKED". 917 The following QUIC frames MUST NOT be transmitted by receivers: 918 "RST_STREAM". 920 Reception of a prohibited QUIC frame or packet is a protocol error. 921 Receivers MUST ignore all prohibited QUIC frames and packets. 923 5. HTTP/QUIC Profile 925 *Authors' Note:* The HTTP/QUIC mapping document is subject to 926 change. This section is based on our best understanding of draft- 927 ietf-quic-http-08. The authors will track developments and will 928 update this section accordingly. 930 HTTP over multicast QUIC depends on HTTP server push, as described in 931 Section 4.4 of [QUIC-HTTP]. Section 5.2 below applies an additional 932 constraint on the use of server push. A multicast sender 933 participating in a session pushes resources as a series of QUIC 934 "STREAM" frames carrying HTTP/QUIC "PUSH_PROMISE", "HEADERS" and 935 "DATA" frames. Examples of this are provided in Appendix B.2. 936 Senders MUST comply with the requirements of the session parameters, 937 as described earlier in Section 3. 939 The profile of HTTP/QUIC specified in this section places additional 940 constrains on the use of metadata compression (Section 5.3) and 941 prioritisation (Section 5.4). 943 5.1. HTTP Connection Settings 945 The HTTP/QUIC "SETTINGS" frame is prohibited by this profile. 946 Participants MUST NOT make any attempt to send this frame type. 947 Reception of this frame MUST be handled as described in Section 5.7. 949 5.2. Server Push 951 Server push is, by default, disabled for HTTP/QUIC connections. A 952 conventional HTTP/QUIC client enables and manages server push by 953 controlling the maximum Push ID ([QUIC-HTTP], Section 5.2.6), 954 achieved by sending the HTTP/QUIC "MAX_PUSH_ID" frame. 956 This profile mandates the use of server push, and specifies no means 957 to disable it. The maximum Push ID for multicast QUIC sessions 958 (initial and always) is 2^62. 960 Server push concurrency in multicast QUIC is described in 961 Section 3.6. There is no role for the HTTP/QUIC "MAX_PUSH_ID" frame 962 and it is prohibited. Participants MUST NOT send this frame type. 963 Reception of this frame type MUST be handled as described in 964 Section 5.7. 966 The HTTP/QUIC "CANCEL_PUSH" frame MAY be used by sending participants 967 to abort sending a response for the identified server push. Usage of 968 this frame should follow the guidance for servers in [QUIC-HTTP]. 970 Receiving participants MUST NOT make any attempt to send QUIC 971 "CANCEL_PUSH" frames to the multicast group. 973 Conventionally, pushed responses are associated with an explicit 974 request from a client. This is not possible when using a 975 unidirectional transport such as multicast IP. This profile reserves 976 the first client-initiated, bidirectional QUIC stream. HTTP/QUIC 977 "PUSH_PROMISE" frames MUST be sent on this reserved Stream ID. 979 *Authors' Note:* The exact value of this Stream ID is currently in 980 flux. This section will track developments and will be updated 981 accordingly. The possibility of sending HTTP/QUIC "PUSH_PROMISE" 982 frames on a control stream is discussed on 983 https://github.com/quicwg/base-drafts/issues/947. 985 5.3. Metadata Compression 987 The compression of HTTP header fields is considered in HPACK 988 [RFC7541], which describes two methods for the compression of HTTP 989 header fields: indexing (via static or dynamic tables) and Huffman 990 encoding. 992 A multicast QUIC session, as described in the present document, does 993 not provide the assurances (receiver participation, transport 994 reliability) required to sufficiently maintain the dynamic decoding 995 context. Therefore, this document requires that endpoints SHALL NOT 996 use dynamic indexing. It is RECOMMENDED that endpoints use static 997 indexing and/or Huffman encoding in order to benefit from the 998 remaining compression methods available. 1000 *Authors' Note:* In the context of QUIC, changes to HPACK may 1001 allow for better leverage of the transport. QPACK 1002 ([I-D.bishop-quic-http-and-qpack]), QCRAM 1003 ([I-D.krasic-quic-qcram]) and QMIN ([I-D.tikhonov-quic-qmin]) are 1004 active proposals in this space. This section will track 1005 developments and will be updated accordingly. 1007 5.4. Prioritisation 1009 The HTTP/QUIC "PRIORITY" frame is prohibited by this profile. 1010 Participants MUST NOT make any attempt to send this frame type. 1011 Reception of this frame MUST be handled as described in Section 5.7. 1013 5.5. Session Tear-down 1015 A multicast QUIC session MAY be explicitly torn down by means of the 1016 "Connection: close" HTTP header described in section 6.6 of 1017 [RFC7230]. A sender intending to leave the session SHOULD include 1018 the "Connection: close" header in its response metadata. A sender 1019 SHOULD transmit all outstanding frames related to remaining request/ 1020 response exchanges before ending transmission to the multicast group. 1021 A receiver SHOULD continue to receive and process frames until all 1022 outstanding request/response exchanges are complete. 1024 5.6. HTTP/QUIC Extension frames 1026 HTTP/QUIC extension frames (e.g. "ALTSVC") are prohibited by this 1027 profile. Participants MUST NOT make any attempt to send extension 1028 frame types. Reception of these MUST be handled as described in 1029 Section 5.7. 1031 5.7. Prohibited HTTP/QUIC Frames 1033 The following HTTP/QUIC frames MUST NOT be transmitted by 1034 participants: "GOAWAY", "MAX_PUSH_ID", "PRIORITY", "SETTINGS". 1036 In addition, all HTTP/QUIC extension frame types MUST NOT be 1037 transmitted by participants. 1039 The following HTTP/QUIC frames MUST NOT be transmitted by receivers: 1040 "CANCEL_PUSH". 1042 Reception of a prohibited HTTP/QUIC frame is a protocol error. 1043 Receivers MUST ignore prohibited HTTP/QUIC frames. 1045 6. Application-Layer Security 1047 As already described in Section 3.2, the implicit cipher suite used 1048 by a multicast QUIC session makes very limited provision for security 1049 in the transport and session layers. This section profiles the use 1050 of some additional features to provide equivalent functionality at 1051 the application-layer. 1053 6.1. Content Integrity 1055 In many applications, it is important to ensure that an HTTP 1056 representation has been received intact (i.e. has not suffered from 1057 transmission loss or random bit errors) before passing the received 1058 object on to the receiving application. A mechanism is therefore 1059 specified here to provide end-to-end content integrity protection for 1060 HTTP representations in transit. The use of this content integrity 1061 mechanism is RECOMMENDED. 1063 *Authors' Note:* We invite review comments on mandating the use of 1064 this content integrity mechanism. 1066 [RFC3230] specifies an instance digest HTTP header called "Digest". 1067 A sender MAY include this header in the HTTP/QUIC "HEADERS" frame of 1068 any representation it transmits and a receiver MAY use this header to 1069 validate the integrity of the received representation once it has 1070 been reassembled. Where this validation fails, the receiver SHOULD 1071 discard the representation without processing it further. 1073 Note that the digest value protects a whole HTTP instance (i.e. the 1074 representation of a resource at the point of transmission as opposed 1075 to the body of a particular HTTP message). In cases where partial 1076 representations are fragmented over one or more HTTP response 1077 messages, the digest value is computed over the complete 1078 representation prior to fragmentation into partial responses. 1080 Any of the algorithms specified in the IANA registry of digest 1081 algorithms (http://www.iana.org/assignments/http-dig-alg/http-dig- 1082 alg.xhtml#http-dig-alg-1) MAY be used in conjunction with the 1083 "Digest" header. There is no requirement for participants to support 1084 the full set of algorithms. 1086 6.2. Content Authenticity 1088 In some applications, it is important for a receiver to reassure 1089 itself that an HTTP representation has been received from an 1090 authentic source. It is also sometimes useful for a receiver to know 1091 that the information has not been tampered with in transit by a 1092 malicious intermediate actor. A mechanism is therefore specified 1093 here to prove the authenticity of HTTP messages in transit. The use 1094 of this content authenticity mechanism is RECOMMENDED for senders 1095 implementing this specification. 1097 *Authors' Note:* We invite review comments on mandating the use of 1098 this content authenticity mechanism. 1100 [I-D.cavage-http-signatures] specifies a means of securely signing 1101 metadata associated with any HTTP message. The resulting digital 1102 signature is conveyed in the "Signature" header of the message 1103 itself. The "Signature" header also conveys a list of HTTP header 1104 fields over which the signature was computed. A receiver MAY verify 1105 the "Signature" header in order to validate the authenticity of 1106 received metadata. Where this validation fails, the receiver SHOULD 1107 discard or ignore any related metadata and/or data without processing 1108 it further. 1110 Note that the signature proves the authenticity of the metadata in a 1111 single HTTP message. A "Signature" header MAY be included separately 1112 in the HTTP/QUIC "PUSH_PROMISE" frame (protecting the request 1113 metadata) and in the final (or only) HTTP/QUIC "HEADERS" frame 1114 relating to a particular resource (protecting the response metadata). 1115 In order to provide an additional level of protection, however, it is 1116 RECOMMENDED that the signature be computed over the combined request 1117 metadata (from the "PUSH_PROMISE" frame) and the corresponding 1118 response metadata (from the HTTP/QUIC "HEADERS" frames) of the same 1119 resource. This binds the request metadata and response metadata 1120 together, providing the receiver with additional reassurance of 1121 authenticity. In this latter case, the combined digital signature 1122 SHALL be conveyed in the final (or only) HTTP/QUIC "HEADERS" frame. 1124 In applications where the detection of replay attacks is a 1125 requirement, it is RECOMMENDED that the "Date" header be included in 1126 the scope of the signature. It is RECOMMENDED that receivers use the 1127 value of the "Date" header for replay detection using appropriate 1128 strategies (e.g. checking for freshness). The definition of such 1129 strategies is beyond the scope of this document. 1131 In applications where the authenticity and integrity of the 1132 transmission are both important, it is RECOMMENDED that the "Digest" 1133 header specified in Section 6.1 above is included in the scope of the 1134 signature. By signing the instance digest, the authenticity and 1135 integrity of the HTTP message body are also assured in addition to 1136 that of the metadata. 1138 Any of the algorithms specified in the IANA registry of signature 1139 algorithms (http://www.iana.org/assignments/signature-algorithms) MAY 1140 be used in conjunction with the "Signature" header. There is no 1141 requirement for participants to support the full set of algorithms. 1143 6.3. Content Confidentiality 1145 In applications where there is a requirement for the content itself 1146 to remain confidential, appropriate steps SHOULD be taken to protect 1147 the application payload, for example by encrypting it. This document 1148 does not preclude the use of application-level encryption, but does 1149 not specify a mechanism for the distribution of content decryption 1150 keys. 1152 7. Loss Recovery 1154 Because the acknowledgement of received packets to multicast groups 1155 is prohibited by this specification (Section 4.9) the detection of 1156 discarded or corrupted packets is the sole responsibility of the 1157 receiver, and such losses must be recovered by means other than the 1158 retransmission mechanism specified in [QUIC-TRANSPORT] and 1159 [QUIC-RECOVERY]. 1161 7.1. Forward Error Correction 1163 *Authors' Note:* A simple parity-based Forward Error Correction 1164 scheme was removed from the experimental QUIC wire protocol 1165 specification in version Q032. The IETF's QUIC Working Group is 1166 chartered to specify one (or more) new FEC schemes in the future. 1167 This section will track developments in this area, and will be 1168 updated accordingly. 1170 A sender MAY make use of a suitable Forward Error Correction scheme 1171 to allow a receiver to reconstruct lost packets from those that have 1172 been successfully received. 1174 7.2. Unicast Repair 1176 In the case where a lost QUIC packet cannot be recovered using 1177 Forward Error Correction, either because the number of packets lost 1178 exceeds the scheme's threshold for reconstruction, or because FEC is 1179 not in use on the multicast QUIC session, a receiver MAY instead 1180 recover the missing payload data using conventional unicast HTTP 1181 requests to an origin server. 1183 o The total size of the resource is indicated in the "content- 1184 length" response header carried in the HTTP/QUIC "HEADERS" frame. 1186 o The location of the missing data can be determined by examining 1187 the Offset field in the QUIC "STREAM" frame headers of 1188 successfully received QUIC packets. 1190 Using this information, a receiver MAY compose an efficient HTTP 1191 range request [RFC7233] to the origin server indicated in the URL. 1192 Several disjoint ranges MAY be combined into a single HTTP request. 1193 A receiver MAY direct its request to an alternative server using Alt- 1194 Svc information received on the multicast QUIC session, or else 1195 received as part of a previous unicast HTTP response according to the 1196 rules in [RFC7838]. 1198 8. Transmission of Partial Content 1200 Under certain circumstances, a sender may not be in full possession 1201 of a resource body when transmission begins, or may not be able to 1202 guarantee that a transmission will complete. In such cases, the 1203 sender MAY employ the syntax of an HTTP range request [RFC7233] to 1204 indicate partial content, as specified below. All receivers SHALL 1205 implement support for such HTTP range requests. 1207 If partial content is to be transmitted: 1209 o The "range" header (Section 3.1 of [RFC7233]) SHALL be present in 1210 the HTTP/QUIC "PUSH_PROMISE" frame. 1212 o The corresponding HTTP/QUIC "HEADERS" frame SHALL indicate HTTP 1213 status code 206. 1215 * The range being transmitted SHALL be indicated in a "content- 1216 range" header field and the size of the complete resource 1217 indicated in a "content-length" header field. 1219 9. Protocol Identifier 1221 The HTTP over multicast QUIC protocol specified in this document is 1222 identified by the application-layer protocol negotiation (ALPN) 1223 [RFC7301] identifier "hqm". The IANA registration of this protocol 1224 identifier can be found in Section 12.1. This reserves the ALPN 1225 identifier space but describes a protocol that does not use TLS. The 1226 usage of the "hqm" identifier for discoverability is described in 1227 Section 10. 1229 9.1. Draft Version Identification 1231 *RFC Editor's Note:* Please remove this section prior to 1232 publication of a final version of this document. 1234 Only implementations of the final, published RFC can identify 1235 themselves as "hqm". Until such an RFC exists, implementations MUST 1236 NOT identify themselves using this string. 1238 Implementations of draft versions of the protocol MUST add the string 1239 "-" and the corresponding draft number to the identifier. For 1240 example, draft-pardue-quic-http-mcast-00 is identified using the 1241 string "hqm-00". 1243 Non-compatible experiments that are based on these draft versions 1244 MUST append the string "-" and an experiment name to the identifier. 1245 For example, an experimental implementation based on draft-pardue- 1246 quic-http-mcast-09 which removes the requirement to ensure version 1247 matches might identify itself as "hqm-09-version-ignorant". Note 1248 that any label MUST conform to the "token" syntax defined in 1249 Section 3.2.6 of [RFC7230]. Experimenters are encouraged to 1250 coordinate their experiments. 1252 10. Discovery of Multicast QUIC Sessions 1254 The announcement and discovery of services operating over multicast 1255 IP has previously been specified by the Session Description Protocol 1256 (SDP) [RFC4566], Session Announcement Protocol [RFC2974] and Session 1257 Initiation Protocol [RFC3261]. These are typically deployed together 1258 and in conjunction with a multicast-friendly transport such as the 1259 Real-time Transport Protocol (RTP) [RFC3550]. 1261 In contrast, the present document specifies a mechanism for 1262 advertising services that is built into HTTP metadata and is 1263 consistent across unicast and multicast resource delivery modes. 1264 This means that a single application-layer can be used for service 1265 advertisement/discovery, and for bulk data transmission/reception. 1266 Specifically, the "Alt-Svc" HTTP header is specified as the means to 1267 advertise multicast services from a unicast service. A unicast HTTP 1268 response MAY be decorated with an Alt-Svc value that hints to the 1269 client about the availability of the resource via a multicast QUIC 1270 session. A client that supports such a multicast QUIC session MAY 1271 then transparently switch to it. 1273 Symmetrically, the "Alt-Svc" header can also be used to advertise the 1274 unicast service from a multicast service. A resource transmitted as 1275 part of a multicast QUIC session MAY be decorated with an Alt-Svc 1276 value that hints to the client about the availability of the resource 1277 via an alternative unicast HTTP server. A receiver MAY then use this 1278 HTTP server for unicast resource patching (Section 7.2). 1280 Where HTTP over multicast QUIC sessions are advertised using Alt-Svc, 1281 the protocol identifier SHALL be "hqm", as specified in Section 9. 1283 10.1. Source-specific Multicast Advertisement 1285 Source-specific multicast (SSM) [RFC4607] MAY be used for the 1286 delivery of multicast services. 1288 *Authors' Note:* We invite review comments on mandating the use of 1289 source-specific multicast only. 1291 This document specifies the "source-address" parameter for Alt-Svc, 1292 which is used to provide the SSM source address to endpoints. 1294 Syntax: 1296 source-address = uri-host; see RFC7230, Section 2.7 1298 For example: 1300 source-address="192.0.2.1" 1302 When a multicast QUIC session is provided using SSM, the "source- 1303 address" parameter MUST be advertised. 1305 10.2. Session Parameter Advertisement 1307 The concept of session parameters is introduced in Section 2.2. This 1308 section details how the session parameters are expressed as Alt-Svc 1309 parameters. 1311 10.2.1. Version 1313 The version of QUIC supported in a multicast QUIC session is 1314 advertised with the "quic" parameter. The requirements for endpoint 1315 usage of "quic" are specified in Section 3.1. 1317 10.2.2. Cipher Suite 1319 This document specifies the "cipher-suite" parameter for Alt-Svc, 1320 which carries the cipher suite in use by a multicast QUIC session. 1321 "cipher-suite" MUST contain one of the values contained in the TLS 1322 Cipher Suite Registry (http://www.iana.org/assignments/tls- 1323 parameters/tls-parameters.xhtml#tls-parameters-4): 1325 Syntax: 1327 cipher-suite = 4*4 HEXDIG 1329 For example, the following specifies cipher suite 0x13,0x01 1330 ("TLS_AES_128_GCM_SHA256"): 1332 cipher-suite=1301 1334 The requirements for endpoint usage of "cipher-suite" are described 1335 in Section 3.2. 1337 10.2.3. Session Key 1339 This document specifies the "key" parameter for Alt-Svc, which 1340 carries the cryptographic key in use by the multicast QUIC session. 1342 Syntax: 1344 key = *HEXDIG 1346 For example: 1348 key=4adf1eab9c2a37fd 1350 The requirements for endpoint usage of "key" are described in 1351 Section 3.2. 1353 10.2.4. Session Cipher Initialization Vector 1355 This document specifies the "iv" parameter for Alt-Svc, which carries 1356 the cipher Initialization Vector (IV) in use by the multicast QUIC 1357 session. 1359 Syntax: 1361 iv = *HEXDIG 1363 For example: 1365 iv=4dbe593acb4d1577ad6ba7dc3189834e 1367 The requirements for endpoint usage of "iv" are described in 1368 Section 3.2. 1370 10.2.5. Session Identification 1372 This document defines the "session-id" parameter for Alt-Svc, which 1373 carries the multicast QUIC session identifier. 1375 Syntax: 1377 session-id = 1*16HEXDIG ; 64-bit value 1379 For example, the following specifies session 101 (0x65 hexadecimal): 1381 session-id=65 1383 The requirements for endpoint usage of "session-id" are described in 1384 Section 2.3. 1386 10.2.6. Session Idle Timeout Period 1388 This document specifies the "session-idle-timeout" parameter for Alt- 1389 Svc, which carries the idle timeout period of a multicast QUIC 1390 session. 1392 Syntax: 1394 session-idle-timeout = *DIGIT ; number of seconds between 0 and 600 1396 For example, the following specifies a one-minute session idle 1397 timeout period: 1399 session-idle-timeout=60 1401 The requirements for endpoint usage of "session-idle-timeout" are 1402 described in Section 3.4. 1404 10.2.7. Resource Concurrency 1406 This document specifies the "max-concurrent-resources" parameter for 1407 Alt-Svc, which expresses the maximum number of concurrent active 1408 resources from the sender in a multicast QUIC session. 1410 Syntax: 1412 max-concurrent-resources = *DIGIT ; unsigned 32-bit integer 1414 For example, the following specifies that no more than 12 (decimal) 1415 resources will be concurrently active in the session: 1417 max-concurrent-resources=12 1419 The requirements for endpoint usage of "max-concurrent-resources" are 1420 described in Section 3.6. 1422 10.2.8. Session Peak Flow Rate 1424 This document specifies the "peak-flow-rate" parameter for Alt-Svc, 1425 which expresses the expected maximum aggregate transfer rate of data 1426 from all sources of the multicast QUIC session. 1428 Syntax: 1430 peak-flow-rate = *DIGIT ; bits per second 1432 For example, the following specifies a peak flow rate of 550 kbits/s 1433 in the session: 1435 peak-flow-rate=550000 1437 The requirements for endpoint usage of "peak-flow-rate" are described 1438 in Section 3.5. 1440 10.2.9. Digest Algorithm 1442 This document specifies the "digest-algorithm" parameter for Alt-Svc, 1443 which carries the digest algorithm in use by a multicast QUIC 1444 session. "digest-algorithm" MUST contain one of the values defined in 1445 the HTTP Digest Algorithm Values registry 1446 (https://www.iana.org/assignments/http-dig-alg/http-dig- 1447 alg.xhtml#http-dig-alg-1). 1449 Syntax: 1451 digest-algorithm = token 1453 For example, the following specifies a digest algorithm of SHA-256: 1455 digest-algorithm=SHA-256 1457 The requirements for endpoint usage of "digest-algorithm" are 1458 described in Section 3.8. 1460 10.2.10. Signature Algorithm 1462 This document specifies the "signature-algorithm" parameter for Alt- 1463 Svc, which carries the signature algorithm in use by a multicast QUIC 1464 session. "signature-algorithm" MUST contain one of the values defined 1465 in the Signature Algorithms registry 1466 (http://www.iana.org/assignments/signature-algorithms). 1468 Syntax: 1470 signature-algorithm = token 1472 For example, the following specifies a signature algorithm of SHA- 1473 256: 1475 signature-algorithm=rsa-sha256 1476 The requirements for endpoint usage of "signature-algorithm" are 1477 described in Section 3.9. 1479 11. Security and Privacy Considerations 1481 This document specifies a profile of QUIC and HTTP/QUIC that changes 1482 the security model. In order to address this, application-level 1483 security methods are described in Section 6. This document does not 1484 preclude the use of secure multicast approaches that may provide 1485 additional security assurances required for certain use cases. 1487 The use of side-channel or out-of-band technologies (potentially 1488 bidirectional interactions) to support multicast QUIC sessions are 1489 considered out of this document's scope. Services using such 1490 technologies should apply their security considerations accordingly. 1492 11.1. Pervasive Monitoring 1494 Certain multicast deployment architectures may require the use of a 1495 session decryption key shared by all participants. Furthermore, the 1496 discovery mechanism described in this document provides a means for a 1497 receiver to obtain a session decryption key without joining the 1498 session. The act of removing packet protection in order to inspect 1499 or modify application contents may, in certain deployments, be 1500 trivial. The exploration of restricting key learning or session 1501 joining to authorised participants goes beyond the scope of this 1502 document. 1504 Because in-band multicast interactions are unidirectional, the impact 1505 of Pervasive Monitoring [RFC7258] on in-band traffic flows is 1506 inherently reduced. Actors can only inspect or modify sender- 1507 initiated traffic. Additional measures for content confidentiality 1508 may mitigate the impact further. This is discussed in Section 6.3. 1510 Further Pervasive Monitoring concerns are addressed in the following 1511 sections. 1513 11.1.1. Large-scale Data Gathering and Correlation 1515 Multicast QUIC sessions decouple sending and receiving participants. 1516 Session participation is subject to operations that allow an endpoint 1517 to join or leave a multicast group, typically IGMP [RFC3376] or MLD 1518 [RFC3810]. The propagation intent of these messages travelling 1519 deeper through a network hierarchy generally leads to the 1520 anonymisation of data if implemented as specified. It may be 1521 possible to gather user-identifiable messages close to the network 1522 edge, for example a router logging such messages. However, this 1523 would require wide-ranging access across Internet Service Provider 1524 networks. Therefore, while such attacks are feasible, it can be 1525 asserted that gathering and correlating user-identifiable traffic is 1526 difficult to perform covertly and at scale. 1528 11.1.2. Changing Content 1530 Sessions that use a symmetric key for packet protection are subject 1531 to the possibility of a malicious actor modifying traffic at some 1532 point in the network between a legitimate sender and one (or more) 1533 receivers. Receiver-side validation, as specified in Section 6 of 1534 the present document, and also in [QUIC-TRANSPORT], allows for the 1535 detection of such modification. Two approaches help mitigate the 1536 impact of modification; the first is application-level methods that 1537 protect data (Section 6.1) and metadata (Section 6.2); the second is 1538 reduction of the QUIC packet attack surface by means of removal of 1539 many frame types (Section 4.10 and Section 5.7). 1541 11.2. Protection of Discovery Mechanism 1543 Multicast QUIC session advertisements SHOULD be conveyed over a 1544 secure transport that guarantees authenticity and integrity in order 1545 to mitigate attacks related to a malicious service advertisement, for 1546 example a "man in the middle" directing endpoints to a service that 1547 may lead to other attacks or exploitations. 1549 *Authors' Note:* We invite review comments on mandating the use of 1550 a secure transport for advertising sessions. 1552 Endpoints that make use of multicast QUIC session advertisements 1553 SHOULD have reasonable assurance that the alternative service is 1554 under control of, and valid for, the whole origin, as described in 1555 Section 2.1 of [RFC7838]. Section 6.2 discusses measures that may be 1556 used to fulfil this requirement. 1558 11.3. Spoofing 1560 11.3.1. Spoofed Ack Attacks 1562 The Spoofed "ACK" attack described in Section 13.1 of 1563 [QUIC-TRANSPORT] is out of scope because use of the QUIC "ACK" frame 1564 is prohibited (Section 4.9) by the present document. 1566 11.3.2. Sender Spoofing 1568 A malicious actor may be able to stage a spoof attack by sending fake 1569 QUIC packets to a multicast QUIC session. This could affect the 1570 operation or behaviour of receivers. In a multicast scenario, this 1571 form of attack has the potential to scale massively. 1573 The feasibility of spoofing a multicast sender is governed by the 1574 characteristics of the multicast deployment and network 1575 infrastructure. The use of source-specific multicast [RFC4607] may 1576 reduce the feasibility. The use of content authenticity 1577 (Section 6.2) may mitigate concerns for the application-level 1578 messages. However, there remains the possibility for transport-level 1579 messages to be spoofed. Multicast applications should consider 1580 further mitigations to address this concern. 1582 11.3.3. Receiver Spoofing 1584 Client source address concerns discussed in Section 7.5 of 1585 [QUIC-TRANSPORT] are out of scope because the connection 1586 establishment is replaced with session establishment in the present 1587 document. Further, the impact that spoofed receivers would have on 1588 the sender is minimal. The impact of malicious participants on the 1589 network is discussed in Section 11.6.2. 1591 11.4. Replay Attacks 1593 Conventional QUIC strategies for protecting against replay attacks 1594 apply similarly here. 1596 Certain multicast QUIC sessions may use a shared key for transport- 1597 level encryption, which would allow an attacker to record, decrypt, 1598 repackage and replay QUIC packets. Section 6.2 discusses how the 1599 application-level contents may be protected from replay (by signing 1600 the "Date" HTTP header), which provides some mitigation to the 1601 success rate or effects of replay attacks. 1603 11.5. Message Deletion 1605 Since HTTP over multicast QUIC is designed to tolerate unreliable 1606 delivery, the impacts of message deletion attacks are presumed to be 1607 small. Deletion of packets carrying HTTP headers will cause a 1608 receiver to ignore subsequent packets carrying body data. 1609 Furthermore, the use of multicast QUIC sessions is opportunistic; 1610 disruption in service (for example, deleting packets and causing a 1611 receiver to fail in construction of a content object) is mitigated by 1612 falling back to a unicast service. Considerations for how this may 1613 affect the performance of the unicast service are given in 1614 Section 11.6.3. 1616 11.6. Denial of Service 1617 11.6.1. Unprotected Frames and Packets 1619 The handling of unprotected QUIC packets is discussed in section 1620 9.1.4 of [QUIC-TLS]. The profile described in the present document 1621 provides the means for a multicast sender to protect QUIC packets 1622 with a shared key, which is not a strong protection. The weak 1623 protection of QUIC packets could present a denial-of-service risk. 1624 To mitigate the impact of handling such QUIC packets, certain frames 1625 and packets are prohibited as described in (Section 4.10 and 1626 Section 5.7). 1628 The frame types that are allowed by this profile do not present a 1629 risk of denial of service. Concerns over authenticity and integrity 1630 are addressed by the application-layer protection mechanisms 1631 described in Section 6. 1633 11.6.2. Network Performance Degradation 1635 The possibility for malfunctioning or malicious participants to 1636 degrade the network is a broad issue and considered out of scope for 1637 this document. Guidelines and concerns discussed in UDP Best 1638 Practices [RFC8085] and other sources apply equally here. This 1639 specification does not preclude the use of network performance 1640 degradation mitigation solutions such as network circuit breakers. 1642 11.6.3. Unicast Repair Stampeding Herd 1644 Deployments that support the unicast repair mechanism described in 1645 Section 7.2 should be aware that a triggering of this behaviour 1646 (either deliberate, planned or unplanned) in a large population of 1647 multicast receivers may cause a stampeding herd of client requests to 1648 the unicast repair service. Service operators SHOULD mitigate the 1649 impact of stampeding herd on their deployment. 1651 11.7. Receiver Resource Usage 1653 The application of receiver-side validation, as defined in the 1654 present document and in [QUIC-TRANSPORT], adds some protection 1655 against allocating resource to the processing of bad data. 1657 11.8. Unicast Repair Information Leakage 1659 The unicast repair mechanism may lead to the leakage of user 1660 behaviour data. An attacker could gain insight into any receiver 1661 participating in a multicast QUIC session, for example by monitoring 1662 the TCP port of the unicast alternative. This alone is no worse than 1663 current abilities to monitor unicast interactions, for example 1664 observing the SNI field contained in a TLS ClientHello. The complete 1665 protection of unicast interactions is beyond the scope of this 1666 document. However, knowledge that a user (or group of users) has 1667 participated in a session is sensitive and may be obtained by 1668 correlation between with observable multicast and unicast traffic. 1670 To give an example, a malicious "man in the middle" could purposely 1671 cause all receivers to perform a unicast repair (by disrupting the 1672 QUIC traffic flow in some way). The disruption is untargeted and may 1673 be simple to orchestrate, but the correlation of user activity data, 1674 especially across a distributed repair service (e.g. a CDN), requires 1675 resources that may reduce the attractiveness of such an attack. 1677 The ability for an attacker to disrupt multicast QUIC sessions is 1678 mitigated by this profile (mainly the prohibition of frames and 1679 packets). Application-layer security measures described in Section 6 1680 reduce the feasibility further. 1682 Multicast receivers concerned about this form of leakage can 1683 eliminate this risk completely by disabling support for unicast 1684 repair, at the potential cost of reduced service quality. 1686 12. IANA Considerations 1688 12.1. Registration of Protocol Identification String 1690 This document creates a new registration for the identification of 1691 the HTTP over multicast QUIC protocol in the "Application-Layer 1692 Protocol Negotiation (ALPN) Protocol IDs" registry established by 1693 [RFC7301]. 1695 The "hqm" string identifies HTTP semantics expressed as HTTP mapped 1696 to a QUIC layer and carried over IP multicast: 1698 Protocol: Bulk data transport using HTTP over multicast QUIC 1700 Identification Sequence: 0x68 0x71 0x6D ("hqm") 1702 Specification: This document, Section 9 1704 This entry reserves an identifier that is not allowed to appear in 1705 TLS Application-Layer Protocol Negotiation. 1707 12.2. Registration of Alt-Svc parameters 1709 This document creates seven registrations for the identification of 1710 parameters for the "Hypertext Transfer Protocol (HTTP) Alt-Svc 1711 Parameter Registry" established by [RFC7838] 1712 (http://www.iana.org/assignments/tls-extensiontype-values/tls- 1713 extensiontype-values.xhtml#alpn-protocol-ids). 1715 12.2.1. Source Address 1717 Parameter name: source-address 1719 Specification: This document, Section 10.1 1721 12.2.2. Cipher Suite 1723 Parameter name: cipher-suite 1725 Specification: This document, Section 10.2.2 1727 12.2.3. Key 1729 Parameter name: key 1731 Specification: This document, Section 10.2.3 1733 12.2.4. Initialization Vector 1735 Parameter name: iv 1737 Specification: This document, Section 10.2.4 1739 12.2.5. Session Identifier 1741 Parameter name: session-id 1743 Specification: This document, Section 10.2.5 1745 12.2.6. Session Idle Timeout 1747 Parameter name: session-idle-timeout 1749 Specification: This document, Section 10.2.6 1751 12.2.7. Maximum Concurrent Resources 1753 Parameter name: max-concurrent-resources 1755 Specification: This document, Section 10.2.7 1757 12.2.8. Peak Flow Rate 1759 Parameter name: peak-flow-rate 1761 Specification: This document, Section 10.2.8 1763 12.2.9. Digest Algorithm 1765 Parameter name: digest-algorithm 1767 Specification: This document, Section 10.2.9 1769 12.2.10. Signature Algorithm 1771 Parameter name: signature-algorithm 1773 Specification: This document, Section 10.2.10 1775 13. References 1777 13.1. Normative References 1779 [I-D.cavage-http-signatures] 1780 Cavage, M. and M. Sporny, "Signing HTTP Messages", draft- 1781 cavage-http-signatures-10 (work in progress), May 2018. 1783 [QUIC-HTTP] 1784 Bishop, M., Ed., "Hypertext Transfer Protocol (HTTP) over 1785 QUIC", draft-ietf-quic-http-08 (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-08 (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, 1795 . 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, 1808 . 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-08 (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-08 (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, 1874 . 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, 1888 . 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, 1903 . 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, 1916 . 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, 1929 . 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-02 2534 o No changes. 2536 D.2. Since draft-pardue-quic-http-mcast-01 2538 o Explicit guidance on maximum stream ID value permitted. 2540 o Updated guidance on PING (and PONG) frame. 2542 o Added a comparison table to appendix. 2544 o Remove invalid use of trailing headers. 2546 o Use the new HTTP/QUIC DATA frame. 2548 o Prohibit APPLICATION CLOSE frame, and move GOAWAY frame to HTTP/ 2549 QUIC section. 2551 o Redefine server push to reflect core document changes. 2553 o Remove default idle time out value. 2555 o Clarify session parameter requirements (session-idle-timeout 2556 became mandatory). 2558 o Update frame notation convention. 2560 D.3. Since draft-pardue-quic-http-mcast-00 2562 o Update references to QUIC I-Ds. 2564 o Relax session leaving requirements language. 2566 o Clarify handling of omitted session parameter advertisements. 2568 o Rename "Idle" state to "Quiescent". 2570 o Add digest algorithm session parameter. 2572 o Add signature algorithm session parameter. 2574 o Add Initialization Vector session parameter. 2576 o Replace COPT tag-value-pairs with TransportParameter values. 2578 o Add example of an advertisement for a session with content 2579 authenticity and integrity. 2581 Authors' Addresses 2583 Lucas Pardue 2584 BBC Research & Development 2586 Email: lucas.pardue@bbc.co.uk 2588 Richard Bradbury 2589 BBC Research & Development 2591 Email: richard.bradbury@bbc.co.uk