idnits 2.17.1 draft-pardue-quic-http-mcast-04.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- ** The document seems to lack a Security Considerations section. ** There are 2 instances of too long lines in the document, the longest one being 8 characters in excess of 72. == There are 1 instance of lines with multicast IPv4 addresses in the document. If these are generic example addresses, they should be changed to use the 233.252.0.x range defined in RFC 5771 Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year == The document seems to lack the recommended RFC 2119 boilerplate, even if it appears to use RFC 2119 keywords -- however, there's a paragraph with a matching beginning. Boilerplate error? (The document does seem to have the reference to RFC 2119 which the ID-Checklist requires). -- The document date (February 5, 2019) is 1899 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-18 == Outdated reference: A later version (-21) exists of draft-ietf-quic-qpack-06 == Outdated reference: A later version (-34) exists of draft-ietf-quic-transport-18 ** Obsolete normative reference: RFC 3230 (Obsoleted by RFC 9530) ** Obsolete normative reference: RFC 7230 (Obsoleted by RFC 9110, RFC 9112) ** Obsolete normative reference: RFC 7233 (Obsoleted by RFC 9110) ** Obsolete normative reference: RFC 7234 (Obsoleted by RFC 9111) == Outdated reference: A later version (-34) exists of draft-ietf-quic-recovery-18 == Outdated reference: A later version (-34) exists of draft-ietf-quic-tls-18 -- Obsolete informational reference (is this intentional?): RFC 2460 (Obsoleted by RFC 8200) -- Obsolete informational reference (is this intentional?): RFC 4566 (Obsoleted by RFC 8866) Summary: 6 errors (**), 0 flaws (~~), 9 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 4 Intended status: Informational R. Bradbury 5 Expires: August 9, 2019 S. Hurst 6 BBC Research & Development 7 February 5, 2019 9 Hypertext Transfer Protocol (HTTP) over multicast QUIC 10 draft-pardue-quic-http-mcast-04 12 Abstract 14 This document specifies a profile of the QUIC protocol and the HTTP/3 15 mapping that facilitates the transfer of HTTP resources over 16 multicast IP using the QUIC transport as its framing and 17 packetisation layer. Compatibility with the QUIC protocol's syntax 18 and semantics is maintained as far as practical and additional 19 features are specified where this is not possible. 21 Status of This Memo 23 This Internet-Draft is submitted in full conformance with the 24 provisions of BCP 78 and BCP 79. 26 Internet-Drafts are working documents of the Internet Engineering 27 Task Force (IETF). Note that other groups may also distribute 28 working documents as Internet-Drafts. The list of current Internet- 29 Drafts is at https://datatracker.ietf.org/drafts/current/. 31 Internet-Drafts are draft documents valid for a maximum of six months 32 and may be updated, replaced, or obsoleted by other documents at any 33 time. It is inappropriate to use Internet-Drafts as reference 34 material or to cite them other than as "work in progress." 36 This Internet-Draft will expire on August 9, 2019. 38 Copyright Notice 40 Copyright (c) 2019 IETF Trust and the persons identified as the 41 document authors. All rights reserved. 43 This document is subject to BCP 78 and the IETF Trust's Legal 44 Provisions Relating to IETF Documents 45 (https://trustee.ietf.org/license-info) in effect on the date of 46 publication of this document. Please review these documents 47 carefully, as they describe your rights and restrictions with respect 48 to this document. Code Components extracted from this document must 49 include Simplified BSD License text as described in Section 4.e of 50 the Trust Legal Provisions and are provided without warranty as 51 described in the Simplified BSD License. 53 Table of Contents 55 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 4 56 1.1. Notational Conventions . . . . . . . . . . . . . . . . . 6 57 1.2. Definitions . . . . . . . . . . . . . . . . . . . . . . . 6 58 2. Multicast QUIC Sessions . . . . . . . . . . . . . . . . . . . 7 59 2.1. Session States . . . . . . . . . . . . . . . . . . . . . 8 60 2.1.1. Session Establishment . . . . . . . . . . . . . . . . 8 61 2.1.2. Session Termination . . . . . . . . . . . . . . . . . 9 62 2.1.3. Session Migration . . . . . . . . . . . . . . . . . . 9 63 2.2. Session Parameters . . . . . . . . . . . . . . . . . . . 9 64 2.3. Session Identification . . . . . . . . . . . . . . . . . 10 65 2.4. Session Security . . . . . . . . . . . . . . . . . . . . 11 66 3. Session Advertisement . . . . . . . . . . . . . . . . . . . . 11 67 3.1. Version Advertisement . . . . . . . . . . . . . . . . . . 12 68 3.2. Security Context . . . . . . . . . . . . . . . . . . . . 13 69 3.2.1. Cipher Suite . . . . . . . . . . . . . . . . . . . . 13 70 3.2.2. Key Exchange . . . . . . . . . . . . . . . . . . . . 13 71 3.2.3. Initialization Vector . . . . . . . . . . . . . . . . 13 72 3.3. Session Identification . . . . . . . . . . . . . . . . . 14 73 3.4. Session Idle Timeout . . . . . . . . . . . . . . . . . . 14 74 3.5. Session Peak Flow Rate . . . . . . . . . . . . . . . . . 15 75 3.6. Resource Concurrency . . . . . . . . . . . . . . . . . . 15 76 3.7. Additional TransportParameter Considerations . . . . . . 16 77 3.8. Digest Algorithm . . . . . . . . . . . . . . . . . . . . 16 78 3.9. Signature Algorithm . . . . . . . . . . . . . . . . . . . 17 79 4. QUIC Profile . . . . . . . . . . . . . . . . . . . . . . . . 18 80 4.1. Packet Size . . . . . . . . . . . . . . . . . . . . . . . 18 81 4.2. Packet Format . . . . . . . . . . . . . . . . . . . . . . 18 82 4.2.1. Packet Numbers . . . . . . . . . . . . . . . . . . . 18 83 4.2.2. Spin Bit . . . . . . . . . . . . . . . . . . . . . . 19 84 4.3. Connection Identifier . . . . . . . . . . . . . . . . . . 19 85 4.4. Stream Identifier . . . . . . . . . . . . . . . . . . . . 19 86 4.5. Flow Control . . . . . . . . . . . . . . . . . . . . . . 19 87 4.6. Stream Termination . . . . . . . . . . . . . . . . . . . 20 88 4.7. Session Shutdown . . . . . . . . . . . . . . . . . . . . 20 89 4.8. Connection Migration . . . . . . . . . . . . . . . . . . 20 90 4.9. Explicit Congestion Notification . . . . . . . . . . . . 21 91 4.10. Session Keep-alive . . . . . . . . . . . . . . . . . . . 21 92 4.11. Loss Detection and Recovery . . . . . . . . . . . . . . . 21 93 4.12. Prohibited QUIC Frames and Packets . . . . . . . . . . . 21 94 5. HTTP/3 Profile . . . . . . . . . . . . . . . . . . . . . . . 22 95 5.1. HTTP Connection Settings . . . . . . . . . . . . . . . . 22 96 5.2. Server Push . . . . . . . . . . . . . . . . . . . . . . . 22 97 5.3. Metadata Compression . . . . . . . . . . . . . . . . . . 23 98 5.4. Prioritisation . . . . . . . . . . . . . . . . . . . . . 24 99 5.5. Session Tear-down . . . . . . . . . . . . . . . . . . . . 24 100 5.6. HTTP/3 Extension frames . . . . . . . . . . . . . . . . . 24 101 5.7. Prohibited HTTP/3 Frames . . . . . . . . . . . . . . . . 24 102 6. Application-Layer Security . . . . . . . . . . . . . . . . . 24 103 6.1. Content Integrity . . . . . . . . . . . . . . . . . . . . 25 104 6.2. Content Authenticity . . . . . . . . . . . . . . . . . . 25 105 6.3. Content Confidentiality . . . . . . . . . . . . . . . . . 26 106 7. Loss Recovery . . . . . . . . . . . . . . . . . . . . . . . . 27 107 7.1. Forward Error Correction . . . . . . . . . . . . . . . . 27 108 7.2. Unicast Repair . . . . . . . . . . . . . . . . . . . . . 27 109 8. Transmission of Partial Content . . . . . . . . . . . . . . . 28 110 9. Protocol Identifier . . . . . . . . . . . . . . . . . . . . . 28 111 9.1. Draft Version Identification . . . . . . . . . . . . . . 28 112 10. Discovery of Multicast QUIC Sessions . . . . . . . . . . . . 29 113 10.1. Source-specific Multicast Advertisement . . . . . . . . 29 114 10.2. Session Parameter Advertisement . . . . . . . . . . . . 30 115 10.2.1. Version . . . . . . . . . . . . . . . . . . . . . . 30 116 10.2.2. Cipher Suite . . . . . . . . . . . . . . . . . . . . 30 117 10.2.3. Session Key . . . . . . . . . . . . . . . . . . . . 31 118 10.2.4. Session Cipher Initialization Vector . . . . . . . . 31 119 10.2.5. Session Identification . . . . . . . . . . . . . . . 31 120 10.2.6. Session Idle Timeout Period . . . . . . . . . . . . 32 121 10.2.7. Resource Concurrency . . . . . . . . . . . . . . . . 32 122 10.2.8. Session Peak Flow Rate . . . . . . . . . . . . . . . 32 123 10.2.9. Digest Algorithm . . . . . . . . . . . . . . . . . . 33 124 10.2.10. Signature Algorithm . . . . . . . . . . . . . . . . 33 125 11. Security and Privacy Considerations . . . . . . . . . . . . . 34 126 11.1. Pervasive Monitoring . . . . . . . . . . . . . . . . . . 34 127 11.1.1. Large-scale Data Gathering and Correlation . . . . . 34 128 11.1.2. Changing Content . . . . . . . . . . . . . . . . . . 35 129 11.2. Protection of Discovery Mechanism . . . . . . . . . . . 35 130 11.3. Spoofing . . . . . . . . . . . . . . . . . . . . . . . . 35 131 11.3.1. Spoofed Ack Attacks . . . . . . . . . . . . . . . . 35 132 11.3.2. Sender Spoofing . . . . . . . . . . . . . . . . . . 35 133 11.3.3. Receiver Spoofing . . . . . . . . . . . . . . . . . 36 134 11.4. Replay Attacks . . . . . . . . . . . . . . . . . . . . . 36 135 11.5. Message Deletion . . . . . . . . . . . . . . . . . . . . 36 136 11.6. Denial of Service . . . . . . . . . . . . . . . . . . . 36 137 11.6.1. Unprotected Frames and Packets . . . . . . . . . . . 37 138 11.6.2. Network Performance Degradation . . . . . . . . . . 37 139 11.6.3. Unicast Repair Stampeding Herd . . . . . . . . . . . 37 140 11.7. Receiver Resource Usage . . . . . . . . . . . . . . . . 37 141 11.8. Unicast Repair Information Leakage . . . . . . . . . . . 37 142 12. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 38 143 12.1. Registration of Protocol Identification String . . . . . 38 144 12.2. Registration of Alt-Svc parameters . . . . . . . . . . . 38 145 12.2.1. Source Address . . . . . . . . . . . . . . . . . . . 39 146 12.2.2. Cipher Suite . . . . . . . . . . . . . . . . . . . . 39 147 12.2.3. Key . . . . . . . . . . . . . . . . . . . . . . . . 39 148 12.2.4. Initialization Vector . . . . . . . . . . . . . . . 39 149 12.2.5. Session Identifier . . . . . . . . . . . . . . . . . 39 150 12.2.6. Session Idle Timeout . . . . . . . . . . . . . . . . 39 151 12.2.7. Maximum Concurrent Resources . . . . . . . . . . . . 39 152 12.2.8. Peak Flow Rate . . . . . . . . . . . . . . . . . . . 40 153 12.2.9. Digest Algorithm . . . . . . . . . . . . . . . . . . 40 154 12.2.10. Signature Algorithm . . . . . . . . . . . . . . . . 40 155 13. References . . . . . . . . . . . . . . . . . . . . . . . . . 40 156 13.1. Normative References . . . . . . . . . . . . . . . . . . 40 157 13.2. Informative References . . . . . . . . . . . . . . . . . 42 158 Appendix A. Acknowledgements . . . . . . . . . . . . . . . . . . 44 159 Appendix B. Examples . . . . . . . . . . . . . . . . . . . . . . 44 160 B.1. Session Advertisement . . . . . . . . . . . . . . . . . . 44 161 B.1.1. Source-specific Multicast QUIC Session . . . . . . . 44 162 B.1.2. Source-specific Multicast QUIC Session with Transport 163 Encryption using a Symmetric Key . . . . . . . . . . 44 164 B.1.3. Source-specific Multicast QUIC Session with Transport 165 Encryption, Content Integrity and Authenticity . . . 45 166 B.2. Resource Transfer . . . . . . . . . . . . . . . . . . . . 45 167 B.2.1. Transfer without Content Integrity or Authenticity . 46 168 B.2.2. Transfer of Partial Content without Content Integrity 169 or Authenticity . . . . . . . . . . . . . . . . . . . 46 170 B.2.3. Transfer with Content Integrity and without 171 Authenticity . . . . . . . . . . . . . . . . . . . . 47 172 B.2.4. Partial Transfer with Content Integrity and without 173 Authenticity . . . . . . . . . . . . . . . . . . . . 47 174 B.2.5. Transfer with Content Integrity and Authenticity . . 48 175 B.2.6. Partial Transfer with Content Integrity and 176 Authenticity . . . . . . . . . . . . . . . . . . . . 49 177 Appendix C. Summary of differences from unicast QUIC and HTTP/3 50 178 Appendix D. Changelog . . . . . . . . . . . . . . . . . . . . . 60 179 D.1. Since draft-pardue-quic-http-mcast-03 . . . . . . . . . . 60 180 D.2. Since draft-pardue-quic-http-mcast-02 . . . . . . . . . . 60 181 D.3. Since draft-pardue-quic-http-mcast-01 . . . . . . . . . . 60 182 D.4. Since draft-pardue-quic-http-mcast-00 . . . . . . . . . . 61 183 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 61 185 1. Introduction 187 The means to bulk transfer resources over multicast IP [RFC1112] 188 using HTTP semantics presents an opportunity to more efficiently 189 deliver services at scale, while leveraging the wealth of existing 190 HTTP-related standards, tools and applications. Audio-visual 191 segmented media, in particular, would benefit from this mode of 192 transmission. 194 The carriage of HTTP over multicast IP may be satisfied using 195 existing technologies, for example the Real-time Transport Protocol 196 (RTP) [RFC3550], File Delivery over Unidirectional Transport (FLUTE) 197 [RFC6726], and NACK-Oriented Reliable Multicast (NORM) [RFC5740]. 198 However, such protocols typically require the translation or 199 encapsulation of HTTP. This introduces concerns for providers of 200 services, such as defining the translation, additional workload, 201 complication of workflows, manageability issues, versioning issues, 202 and so on. 204 In contrast, this document describes a simpler and more direct 205 expression of HTTP semantics over multicast IP. HTTP over multicast 206 QUIC is a profile of the QUIC protocol [QUIC-TRANSPORT] (Section 4) 207 and the HTTP/3 mapping [QUIC-HTTP] (Section 5). This includes the 208 repurposing of certain QUIC packet fields and changes to some 209 protocol procedures (e.g. prohibition of the usage of certain frame 210 types) which, in turn, change the behavioural expectations of 211 endpoints. However, the profile purposely limits the scope of change 212 in order to preserve maximum syntactic and semantic compatibility 213 with conventional QUIC. For the reader's convenience, the 214 differences between this specification and conventional QUIC are 215 summarised in Appendix C. 217 This profile prohibits the transmission of QUIC packets from receiver 218 to sender via multicast IP. The use of side-channel or out-of-band 219 feedback mechanisms is not prohibited by this specification, but is 220 out of scope and these are not considered further by the present 221 document. 223 Experience indicates that a generally available multicast deployment 224 is difficult to achieve on the Internet notwithstanding the 225 improvements that IPv6 [RFC2460] makes in this area. There is 226 evidence that discretely referenced multicast "islands" can more 227 pragmatically be deployed. Discovery of such islands by receivers, 228 as they become available, is typically difficult, however. To 229 address the problem, this document describes an HTTP-based discovery 230 mechanism that uses HTTP Alternative Services [RFC7838] to advertise 231 the existence of multicast QUIC sessions (Section 3). This provides 232 the means for multicast-capable endpoints to learn about and make use 233 of them in an opportunistic and user-imperceptible manner. This 234 mechanism results in a common HTTP application layer for both the 235 discovery and delivery of services across unicast and multicast 236 networks. This provides support for users and devices accessing 237 services over a heterogeneous network. This is a departure from 238 conventional multicast discovery technologies such as SDP [RFC4566] 239 and SAP [RFC2974]. 241 The discovery mechanism also addresses some of the issues related to 242 using QUIC over a unidirectional network association by replacing 243 connection establishment aspects that depend on a bidirectional 244 transport. 246 The present document includes a number of optional features. It is 247 anticipated that further specifications will define interoperability 248 profiles suited to particular application domains. 250 1.1. Notational Conventions 252 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 253 "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and 254 "OPTIONAL" in this document are to be interpreted as described in BCP 255 14 [RFC2119] [RFC8174] when, and only when, they appear in all 256 captials, as shown here. 258 This document uses the Augmented BNF defined in [RFC5234] and updated 259 by [RFC7405] along with the "#rule" extension defined in Section 7 of 260 [RFC7230]. The rules below are defined in [RFC5234], [RFC7230], and 261 [RFC7234]: 263 o quoted-string = 265 o token = 267 o uri-host = 269 1.2. Definitions 271 Definitions of terms that are used in this document: 273 o endpoint: A host capable of being a participant in a multicast 274 QUIC session. 276 o multicast QUIC session: A logical unidirectional flow of metadata 277 and data over multicast IP, framed according to this 278 specification. The lifetime of a session is independent of any 279 endpoint. 281 o participant: A sender or receiver that is taking part in a 282 multicast QUIC session. 284 o sender: A participant sending multicast traffic according to this 285 specification. 287 o receiver: A participant receiving multicast traffic according to 288 this specification. 290 o session: See multicast QUIC session. 292 o session ID: The identifier for a multicast QUIC session. 294 o session parameter: Characteristic of a multicast QUIC session. 296 2. Multicast QUIC Sessions 298 A QUIC connection [QUIC-TRANSPORT] carried over bidirectional unicast 299 is defined as a conversation between two QUIC endpoints that 300 multiplexes several logical streams within a single encryption 301 context. This is a one-to-one relationship. Furthermore, QUIC 302 connections achieve decoupling from the underlying network (IP and 303 port) by means of a pair of Connection IDs, each uniquely identifying 304 the flow in one direction. Use of a consistent connection identifier 305 allows QUIC connections to survive changes to the network 306 connectivity. The establishment of a QUIC connection relies upon an 307 up-front, in-band exchange (and possible negotiation) of 308 cryptographic and transport parameters (conveyed in QUIC handshake 309 messages). 311 The mapping of HTTP semantics over the QUIC transport protocol 312 [QUIC-HTTP] facilitates the transfer of hypermedia over QUIC 313 connections. The establishment of a HTTP/3 connection relies upon 314 all the requirements stipulated for the transport, as well as 315 communication of HTTP-specific settings (conveyed in HTTP/3 316 "SETTINGS" frames). Such parameters may be required or optional and 317 may be used by either endpoint to control the characteristics of 318 connection usage. 320 This concept of a connection does not suit the carriage of HTTP/3 321 over unidirectional network associations such as multicast IP. In 322 fact, there is no requirement for either endpoint (multicast sender 323 or receiver) to be in existence in order for the other to start or 324 join this one-sided conversation. The term "connection" is 325 misleading in this context; therefore we introduce an alternative 326 term "multicast QUIC session" or simply "session", which is defined 327 as the logical entity describing the characteristics of the 328 anticipated unidirectional flow of metadata and data. Such 329 characteristics are expressed as "session parameters", described in 330 Section 2.2. Advertisement of multicast QUIC sessions, specified in 331 Section 3, allows for the senders and receivers to discover a session 332 and to form multicast IP network associations that permit traffic 333 flow. 335 2.1. Session States 337 The lifecycle of a multicast QUIC session is decoupled from the 338 lifecycle of any particular endpoint. Multicast receivers or senders 339 that take part in a session are called participants. The state of a 340 session is influenced by the actions of participants. The loose 341 coupling of participants means that they are unlikely to have a 342 consistent shared view of the current state of a session. There is 343 no requirement for a participant to know the session state and the 344 present document does not define a method to explicitly determine it. 345 The definitions of session states provided below are intended to 346 assist higher-level operational treatment of sessions: 348 o Quiescent: the session has no participants and is ready to accept 349 them. 351 o Half-established: the session has a participant. 353 o Fully-established: the session has a sender and at least one 354 receiver participant. 356 o Finished: the session has ended, and there are no participants. 358 Permitted states transitions are shown in Figure 1 below. 360 The transmission of QUIC packets is expected to occur only during the 361 Half-Established and Fully-Established states. 363 +-----------+ +------------------+ +-------------------+ 364 | |-------->| |------->| | 365 | Quiescent | | Half-Established | | Fully-Established | 366 | |<--------| |<-------| | 367 +-----------+ +------------------+ +-------------------+ 368 | | 369 | v 370 | +----------+ 371 | | | 372 +------------------>| Finished | 373 | | 374 +----------+ 376 Figure 1: Multicast QUIC session states 378 2.1.1. Session Establishment 380 A session begins in the Quiescent state. A typical session 381 establishment sequence would see the transition from Quiescent to 382 Half-Established when a sender joins the session. The transition 383 from Half-Established to Fully-Established occurs when at least one 384 receiver joins the session. 386 It is equally valid for a receiver to join a session in the Quiescent 387 state, triggering the transition to Half-Established. In this case, 388 the transition to Fully-Established takes place only when a sender 389 joins the session. 391 2.1.2. Session Termination 393 A session enters the Finished state when all participants leave it. 394 The methods for leaving a session are either explicit shutdown 395 (Section 5.5), implicit shutdown (i.e. idle timeout, Section 3.4) or 396 migration away (described in the next section). 398 In a typical case, a session that is in the Fully-Established state 399 would be closed in two stages. In the first stage the sender sends 400 explicit shutdown messages to the multicast group and subsequently 401 stops transmitting packets. This causes the session to transition 402 from Fully-Established to Half-Established. In the second stage, 403 receivers that have received explicit shutdown messages leave the 404 multicast group. Once all receivers have left the session it 405 transitions from Half-Established to Finished. 407 The transition from Quiescent to Finished could also occur in 408 response to out-of-band actions, for example the availability of a 409 session being withdrawn without any participants having made use of 410 it. 412 2.1.3. Session Migration 414 Endpoints MAY migrate between multicast QUIC sessions (for example, 415 to make use of alternate session parameters that are preferred). 416 Session migration requires participants to leave the current session 417 and join the new session. These actions affect the state of the 418 respective sessions as explained above. 420 The discovery of multicast QUIC sessions is described in Section 3. 422 2.2. Session Parameters 424 The characteristics of multicast QUIC sessions are expressed as 425 session parameters, which cover cryptographic and transport 426 parameters, HTTP-specific settings and multicast-specific 427 configuration. 429 Session parameter exchange over IP multicast is difficult: 431 o In-band exchanges are one-way, and so the client does not have the 432 means to send session parameters. 434 o The lifecycle of any multicast sender is independent of the 435 multicast receiver. It is therefore unlikely that all receivers 436 will have joined a session in time to receive parameters sent at 437 the start of a multicast session. 439 A range of strategies exists to mitigate these points. However, each 440 has the possibility to add complexity to deployment and 441 manageability, transmission overhead, or other such concerns. This 442 document defines a solution that relies on the one-way announcement 443 of session parameters in advance of session establishment. This is 444 achieved using HTTP Alternative Services [RFC7838] and is explained 445 in Section 3. Other advertisement solutions are not prohibited but 446 are not explored in this document. 448 Session parameters MUST NOT change during the lifetime of a session. 449 This restriction also applies to HTTP-level settings (see 450 Section 5.1). 452 2.3. Session Identification 454 This document defines an optional session identifier used to identify 455 a session. This "Session ID" affords independence from multicast IP, 456 creating the possibility for a session to span multiple multicast 457 groups, or to migrate a session to a different multicast group. 458 Assignment of Session ID is considered out of this document's scope. 460 The Session ID is carried in the Destination Connection ID field of 461 the QUIC packet (see Section 4.3). Source Connection IDs are not 462 used. 464 The maximum size of a Session ID is 144 bits. The size of the 465 Destination Connection ID field used to convey the Session ID SHALL 466 be the smallest number of full bytes required to represent the full 467 Session ID value advertised in the "session-id" session parameter 468 (Section 10.2.5). If no "session-id" parameter is advertised, then 469 this session has no explicit session ID, and the Destination 470 Connection ID field SHALL be omitted from all QUIC packets related to 471 the session. 473 A multicast sender participating in a session with an advertised 474 "session-id" session parameter MUST send QUIC packets with a matching 475 Session ID. Conversely, a multicast sender participating in a 476 session without an advertised "session-id" session parameter MUST NOT 477 send QUIC packets with a Destination Connection ID field. 479 A multicast receiver participating in a session with an advertised 480 "session-id" session parameter MUST validate that the Session ID of 481 received QUIC packets matches that advertised in the session 482 parameters (Section 10.2.5) before any HTTP-level processing is done. 483 In the case of validation failure, the receiver SHOULD ignore the 484 packet in order to protect itself from denial-of-service attacks. 486 2.4. Session Security 488 *Authors' Note:* Security handshake (as described in WG documents) 489 is in flux. This section will track developments and will be 490 updated accordingly. 492 The QUIC cryptographic handshake ([QUIC-TRANSPORT] and [QUIC-TLS]) 493 sets out methods to achieve the goals of authenticated key exchange 494 and QUIC packet protection between two endpoints forming a QUIC 495 connection. The design facilitates low-latency connection; 1-RTT or 496 0-RTT. This specification replaces the in-band security handshake, 497 achieving similar goals through the use of session parameters 498 described in Section 3.2. 500 Integrity and authenticity concerns are addressed in Section 6.1 and 501 Section 6.2 respectively. In order to protect themselves from attack 502 vectors, endpoints SHOULD NOT participate in sessions for which they 503 cannot establish reasonable confidence over the cipher suite or key 504 in use for that session. Participants MAY leave any session that 505 fails to successfully match anticipated security characteristics. 507 3. Session Advertisement 509 In this specification, connection negotiation is replaced with a 510 session advertisement mechanism based on HTTP Alternative Services 511 (Alt-Svc) [RFC7838]. This document specifies how the parameters of a 512 multicast QUIC session are expressed as Alt-Svc parameters. The 513 following sections provide a high-level view of these; further 514 details are provided in Section 10.2, with examples provided in 515 Appendix B.1. QUIC connection parameters not defined as, or related 516 to, Alt-Svc parameters are not used. 518 The definition of a session (including the session ID and its 519 parameters) is not the responsibility of any endpoint. Rather, 520 endpoints SHOULD use session advertisements to determine if they are 521 capable of participating in a given session. This document does not 522 specify which party is responsible for defining and/or advertising 523 multicast QUIC sessions. 525 Endpoints SHOULD NOT become participants in sessions where the 526 advertisement requirements set out in the present document are 527 unfulfilled. 529 The freshness of Alt-Svc multicast QUIC session advertisements is as 530 described in section 2.2 of [RFC7838]. 532 It is RECOMMENDED that session advertisements are carried over a 533 secure transport (such as HTTPS) which can guarantee the authenticity 534 and integrity of the Alt-Svc information. This addresses some of the 535 concerns around the protection of session establishment described in 536 Section 11.2. 538 *Authors' Note:* We invite review comments on mandating the use of 539 a secure transport for advertising sessions. 541 Senders MAY also advertise the availability of alternative sessions 542 by carrying Alt-Svc in a multicast QUIC session. 544 3.1. Version Advertisement 546 *Authors' Note:* Version negotiation (as described in WG 547 documents) is in flux. This section will track developments and 548 will be updated accordingly. 550 Conventional QUIC connection establishment begins with version 551 negotiation. In a unidirectional multicast environment, there is no 552 reasonable way to negotiate in such a manner. [QUIC-HTTP] defines an 553 Alt-Svc "quic" parameter that can be advertised to clients for use as 554 a version negotiation hint. This specification uses "quic" as a 555 session parameter for a similar purpose. This mechanism replaces the 556 use of the Version field in the QUIC packet long header (see 557 Section 4.2). 559 The Alt-Svc "quic" parameter is mandatory. Session advertisements 560 MUST contain exactly one instance of it and it MUST NOT be repeated. 562 A multicast sender participating in a session MUST send QUIC packets 563 and frames in the format corresponding to the advertised version. If 564 the sender does not support the advertised version it MUST NOT send 565 any data. A receiver MUST NOT join a session where the "quic" 566 parameter is absent. A receiver SHOULD NOT join a session for which 567 it does not support the advertised version, in order to avoid wasting 568 processing resources. 570 3.2. Security Context 572 *Authors' Note:* Security handshake (as described in WG documents) 573 is in flux. This section will track developments and will be 574 updated accordingly. 576 This specification replaces the in-band security handshake. The 577 session parameters "cipher suite", "key" and "iv" (described below) 578 allow for the establishment of a security context. In order to 579 protect themselves, endpoints SHOULD NOT participate in sessions for 580 which they cannot establish reasonable confidence over the cipher 581 suite, key, or IV in use for that session. Endpoints SHOULD leave 582 any sessions which fail to successfully match anticipated security 583 characteristics. 585 3.2.1. Cipher Suite 587 Cipher suite negotiation is replaced with a "cipher suite" session 588 parameter, which is advertised as the Alt-Svc parameter "cipher- 589 suite" (Section 10.2.2). 591 The Alt-Svc "cipher-suite" parameter is OPTIONAL. If present, this 592 parameter MUST contain only one value that corresponds to an entry in 593 the TLS Cipher Suite Registry (see http://www.iana.org/assignments/ 594 tls-parameters/tls-parameters.xhtml#tls-parameters-4). Session 595 advertisments that omit this parameter imply that the session is 596 operating with cipher suite 0x00,0x00 (NULL_WITH_NULL_NULL). 598 3.2.2. Key Exchange 600 Key exchange is replaced with a "key" session parameter, which is 601 advertised as the Alt-Svc parameter "key" (Section 10.2.3). The 602 parameter carries a variable-length hex-encoded key for use with the 603 session cipher suite. 605 The Alt-Svc "key" parameter is OPTIONAL. Session advertisments that 606 omit this parameter imply that the key may be available via an out- 607 of-band method not described in this document. 609 3.2.3. Initialization Vector 611 Initialization Vector (IV) exchange is replaced with an "iv" session 612 parameter, which is advertised as the Alt-Svc parameter "iv" 613 (Section 10.2.4). The parameter carries a variable-length hex- 614 encoded IV for use with the session cipher suite and key. 616 The Alt-Svc "iv" parameter is OPTIONAL. Session advertisments that 617 omit this parameter imply that the IV may be available via an out-of- 618 band method not described in this document. 620 3.3. Session Identification 622 [QUIC-TRANSPORT] specifies how the QUIC connection identifiers are 623 used, in particular the independent selection of these identfiers by 624 each endpoint for its peer. In a unidirectional multicast 625 environment, there is no meaningful way for an endpoint to generate a 626 connection identifier for its peer to use. This document defines a 627 "session identifier" session parameter, which is advertised as the 628 Alt-Svc parameter "session-id" (Section 10.2.5). The requirements 629 for the usage of session identifiers have already been described in 630 Section 2.3. 632 The Alt-Svc "session-id" parameter is optional. Session 633 advertisements MAY contain zero or more instances. The parameter MAY 634 be repeated with different values, indicating that multiple sessions 635 are multiplexed in the same multicast group. 637 *Authors' Note:* We invite review comments on mandating a single 638 session identifier per advertised session, i.e. only one session 639 identifier per ASM {G} or SSM {S,G}. 641 3.4. Session Idle Timeout 643 Conventional QUIC connections may be implicitly terminated following 644 a period of idleness (lack of network activity). The optional QUIC 645 TransportParameter "idle_timeout" provides a means for endpoints to 646 specify the timeout period. This document defines a "session idle 647 timeout" session parameter, which is advertised as the Alt-Svc 648 parameter "session-idle-timeout" (Section 10.2.6). This session 649 parameter mimics the behaviour of "idle_timeout", providing a means 650 for multicast QUIC sessions to define their own idle timeout periods. 652 Session idle timeout may be prevented by keep-alive strategies 653 Section 4.10. 655 The Alt-Svc "session-idle-timeout" parameter is optional. Session 656 advertisements MAY contain zero or more instances of this parameter. 657 If it is repeated, the first occurrence MUST be used and subsequent 658 occurrences MUST be ignored. Session advertisements that omit the 659 "session-idle-timeout" parameter, or set it to zero never time out. 661 Receiving participants SHOULD leave multicast QUIC sessions when the 662 session idle timeout period has elapsed (Section 4.7). Leaving 663 participants MUST use the silent close method, in which no QUIC 664 "CONNECTION_CLOSE" frame is sent. 666 3.5. Session Peak Flow Rate 668 [QUIC-TRANSPORT] specifies a credit-based stream- and connection- 669 level flow control scheme which prevents a fast sender from 670 overwhelming a slow receiver at the stream level, as well as an 671 aggregate level of all streams. Window size connection parameters 672 are exchanged on connection establishment using the required QUIC 673 TransportParameters "initial_max_data", 674 "initial_max_stream_data_bidi_local", 675 "initial_max_stream_data_bidi_remote" and 676 "initial_max_stream_data_uni". In a unidirectional multicast 677 environment, such a scheme is infeasible. 679 This document defines a "peak flow rate" session parameter, expressed 680 in units of bits per second, which is advertised as the Alt-Svc 681 parameter "peak-flow-rate" (Section 10.2.8). This completely 682 replaces the transport parameters listed above, instead indicating 683 the maximum bit rate of QUIC "STREAM" frame payloads transmitted on 684 all multicast groups comprising the session. It applies at the 685 aggregate level, and is not specific to any single stream. 687 The Alt-Svc "peak-flow-rate" parameter is OPTIONAL. If the parameter 688 is repeated the first occurrence MUST be used and subsequent 689 occurrences MUST be ignored. Session advertisements that omit the 690 parameter imply that the flow rate is unlimited. 692 A multicast sender SHOULD NOT cause the advertised peak flow rate of 693 a session to be exceeded. A receiver MAY leave any session where the 694 advertised peak flow rate is exceeded. 696 3.6. Resource Concurrency 698 [QUIC-TRANSPORT] considers concurrency in terms of the number of 699 active incoming streams, which is varied by the receiving endpoint 700 adjusting the maximum Stream ID. The initial value of maximum Stream 701 ID is controlled by the relevant required QUIC TransportParameters 702 "initial_max_streams_bidi" and "initial_max_streams_uni". They are 703 increased during the lifetime of a QUIC connection by the QUIC 704 "MAX_STREAMS" frame. In a unidirectional multicast environment, 705 there is no way for a receiver to specify an initial limit nor to 706 increase it. Therefore in multicast QUIC, the maximum Stream ID 707 (initial and always) is 2^62. This mechanism is not used to manage 708 concurrency in multicast QUIC. 710 Due to the profiling of maximum Stream ID, there is no role for the 711 QUIC "STREAMS_BLOCKED" frame and it is prohibited. Participants MUST 712 NOT send this frame type. Reception of this frame type MUST be 713 handled as described in Section 4.12. 715 This document specifies a "maximum concurrent resources" session 716 parameter, which is advertised as the Alt-Svc parameter "max- 717 concurrent-resources" (Section 10.2.7). This parameter replaces 718 "initial_max_stream_id_bidi" and "initial_max_stream_id_uni". It 719 advertises the maximum number of concurrent active resources 720 generated by a sender in a given multicast QUIC session. 722 The Alt-Svc "max-concurrent-resources" parameter is OPTIONAL. If the 723 parameter is repeated the first occurrence MUST be used and 724 subsequent occurrences MUST be ignored. Session advertisements that 725 omit the parameter imply that the maximum concurrency is unlimited. 727 A multicast sender participating in a session MUST NOT cause the 728 advertised "max-concurrent-resources" to be exceeded. A receiver MAY 729 leave any session where the advertised limit is exceeded, in order to 730 protect itself from denial-of-service attacks. 732 3.7. Additional TransportParameter Considerations 734 *Authors' Note:* This section will consider TransportParameters 735 that have not already been addressed, as required. It will track 736 developments and issues that may arise. 738 3.8. Digest Algorithm 740 A method to provide content integrity is described in Section 6.1. 741 This specifies the means to convey a value computed by a particular 742 digest algorithm. The identity of the selected algorithm is also 743 indicated. Valid digest algorithms are collected in the IANA HTTP 744 Digest Algorithm Values registry (http://www.iana.org/assignments/ 745 http-dig-alg/http-dig-alg.xhtml#http-dig-alg-1). 747 This document specifies a "digest algorithm" session parameter, which 748 is advertised as the Alt-Svc parameter "digest-algorithm" 749 (Section 10.2.9). 751 *Authors' Note:* Section 6.1 contains an author's note on the 752 potential for content integrity to become mandatory. This section 753 will be updated in line with the outcome of that decision. 755 The Alt-Svc "digest-algorithm" parameter is OPTIONAL. Repetition of 756 the "digest algorithm" parameter in a single advertisement describes 757 an algorithm set that MAY be used across the session. Session 758 advertisements that omit the Alt-Svc parameter "digest-algorithm" 759 imply that either: 761 o the session does not use the content integrity mechanism, or 763 o the algorithm set is unrestricted, i.e. a sender may vary the 764 algorithm as it so chooses. This may lead to undesirable results 765 if receivers do not support a chosen algorithm. 767 Advertising the algorithm set for a session gives receivers the 768 opportunity to selectively join sessions where the algorithms are 769 known to be supported. This may help to mitigate latency issues in 770 the receiver resulting from joining a session only to discover some 771 of its parameters are not supported. 773 A multicast sender participating in a session MUST NOT use algorithms 774 outside the signalled digest algorithm set. A receiver MAY leave any 775 session where an algorithm outside the digest algorithm set is used. 777 3.9. Signature Algorithm 779 A method to provide content authenticity is described in Section 6.2. 780 This specifies the means to convey a value computed by a particular 781 signature algorithm. The identity of the selected algorithm is also 782 indicated. Valid signature algorithms are collected in the IANA 783 Signature Algorithms registry (http://www.iana.org/assignments/ 784 signature-algorithms). 786 This document specifies a "signature algorithm" session parameter, 787 which is advertised as the Alt-Svc parameter "signature-algorithm" 788 (Section 10.2.10). 790 *Authors' Note:* Section 6.2 contains an author's note on the 791 potential for content authenticity to become mandatory. This 792 section will be updated in line with the outcome of that decision. 794 The Alt-Svc "signature-algorithm" parameter is OPTIONAL. Repetition 795 of the "signature algorithm" parameter in a single advertisement 796 describes an algorithm set that MAY be used across the session. 797 Session advertisements that omit the Alt-Svc parameter "signature- 798 algorithm" imply that either: 800 o the session does not use the content authenticity mechanism, or 802 o the algorithm set is unrestricted i.e. a sender may vary the 803 algorithm as it so chooses. This may lead to undesirable results 804 if receivers do not support a chosen algorithm. 806 Advertising the algorithm set for a session gives receivers the 807 opportunity to selectively join sessions where the algorithms are 808 known to be supported. This may help to mitigate latency issues in 809 the receiver resulting from joining a session only to discover some 810 of its parameters are not supported. 812 A multicast sender participating in a session MUST NOT use algorithms 813 outside the signalled signature algorithm set. A receiver MAY leave 814 any session where an algorithm outside the signature algorithm set is 815 used. 817 4. QUIC Profile 819 *Authors' Note:* The QUIC transport document is subject to change. 820 This section is based on our best understanding of draft-ietf- 821 quic-transport-08. The authors will track developments and will 822 update this section accordingly. 824 The profile of [QUIC-TRANSPORT] is presented in this section. In 825 order to preserve compatibility with conventional QUIC, the 826 specification works with a limited scope of change. However, the 827 nature of unidirectional multicast communications means that some 828 protocol procedures or behaviours need to be modified. 830 4.1. Packet Size 832 The means for determining an appropriate size for QUIC packets are 833 described in Section 14 of [QUIC-TRANSPORT]. Implementations of this 834 specification SHOULD bear in mind that the Path Maximum Transmission 835 Unit (PTMU) may be affected by multicast IP technologies such as 836 Automatic Multicast Tunneling (AMT) [RFC7450]. Additionally, 837 consideration should be given toward the applicability of maximum 838 transmission unit discovery methods (such as PLPMTUD [RFC4821] and 839 PMTUD [RFC1191]) to multicast IP. 841 4.2. Packet Format 843 Endpoints implementing this specification MUST only send QUIC packets 844 with the short header form. As short header packets do not include a 845 length, senders MUST NOT attempt to coalesce any QUIC packets in the 846 same UDP datagram. Therefore, all UDP datagrams sent by senders 847 conforming to this profile contain exactly one QUIC packet. 849 4.2.1. Packet Numbers 851 All packets for this profile SHALL be numbered in the application 852 data packet number space. The initial and handshake packet number 853 spaces are not used by this profile, as the handshake is replaced by 854 an out-of-band mechanism (see Section 2.4). 856 Because a recevier may join a session after the sender has already 857 sent several packets, it MUST NOT assume that the first packet number 858 will be 0. 860 4.2.2. Spin Bit 862 [QUIC-TRANSPORT] reserves a bit in the short packet header for the 863 latency spin bit [QUIC-SPIN] that may be used to measure network 864 round trip latency between a client and a server. This mechanism is 865 not usable in a unidirectional multicast packet flow. Senders SHALL 866 set the spin bit to zero in all packets. Receivers SHOULD ignore the 867 spin bit. 869 *Authors' Note:* The authors welcome suggestions for the use of 870 the spin bit in a multicast context. 872 4.3. Connection Identifier 874 The Destination Connection ID field MUST be present in every QUIC 875 packet if the session was advertised with a "session-id" session 876 parameter (Section 10.2.5). If there is no Session ID session 877 parameter, then the Destination Connection ID MUST NOT be present in 878 any QUIC packet for that session. In the case where multiple 879 sessions are multiplexed on the same 5-tuple network association, the 880 Destination Connection ID field MUST be present in every QUIC packet 881 and must be distinct for each session. 883 4.4. Stream Identifier 885 The maximum Stream ID of a multicast QUIC session is 2^62, as 886 explained in Section 3.6. With the exception of the first client- 887 initiated request Stream ID, which is reserved as described in 888 Section 5.2, all Stream ID values SHALL be of the server-initiated 889 unidirectional stream type. 891 4.5. Flow Control 893 Conventional QUIC provides stream- and connection-level flow control, 894 and endpoints manage this by sending QUIC "MAX_DATA" or 895 "MAX_STREAM_DATA" frames as required. When a sender is blocked from 896 sending flow-controlled frames, it sends an informational QUIC 897 "BLOCKED" or "STREAM_BLOCKED" frame. 899 In a unidirectional environment, the sender never has a receive 900 window and the receiver cannot send in-band updates. Therefore, the 901 management of flow-control windows and transmission of blockage 902 information is not supported by this profile. The QUIC "MAX_DATA", 903 "MAX_STREAM_DATA", "BLOCKED" and "STREAM_BLOCKED" frames are 904 prohibited by this profile. Participants MUST NOT send these frame 905 types. Reception of these frame types MUST be handled as described 906 in Section 4.12. 908 4.6. Stream Termination 910 A sender MAY prematurely terminate the transmission on any unreserved 911 QUIC Stream ID by setting the "FIN" bit of a QUIC "STREAM" frame, or 912 by sending a QUIC "RESET_STREAM" frame (as specified in 913 [QUIC-TRANSPORT] and [QUIC-HTTP]). 915 Receiving participants MUST NOT make any attempt to send QUIC 916 "RESET_STREAM" frames to the multicast group. 918 4.7. Session Shutdown 920 Explicit shutdown of a multicast QUIC session using QUIC methods is 921 not supported by this profile. 923 The QUIC "APPLICATION_CLOSE" and "CONNECTION_CLOSE" frames, and the 924 Stateless Reset packet are prohibited. Participants MUST NOT send 925 these and reception MUST be handled as described in Section 4.12. 927 The HTTP/3 "GOAWAY" frame is prohibited. Participants MUST NOT send 928 this and reception MUST be handled as described in Section 5.7. 930 *Author's Note*: Richard: Should the above be moved to the HTTP/3 931 profile section? (REMOVE BEFORE PUBLISHING) 933 Explicit session tear-down using HTTP semantics is allowed, as 934 described in Section 5.5. 936 Implicit shutdown by means of silent close is also supported, as 937 described in Section 3.4. 939 4.8. Connection Migration 941 [QUIC-TRANSPORT] has a connection migration feature that allows a 942 connection to survive changes to endpoint addresses. This profile 943 does not currently support connection migration, and as such the 944 "NEW_CONNECTION_ID" and "RETIRE_CONNECTION_ID" frames are prohibited. 945 Similarly, the "PATH_CHALLENGE" and "PATH_RESPONSE" frames are also 946 prohibited, but additionally because they require bidirectional 947 capability that this profile does not provide. 949 4.9. Explicit Congestion Notification 951 [QUIC-TRANSPORT] specifies that clients may use Explicit Congestion 952 Notification (ECN) [RFC3168]. ECN allows receivers to inform senders 953 of impending congestion before packets are dropped, and the sender 954 may then reduce its transmission rate. As ECN requires bidirectional 955 communication for the receiver to inform the sender of the 956 congestion, the use of ECN for this profile is prohibited. 958 *Author's Note*: It is the responsibility of a receiver to 959 determine whether network conditions permit the uncongested 960 reception of a given session based on the advertised "peak-flow- 961 rate" parameter. 963 4.10. Session Keep-alive 965 The flow of traffic in a multicast QUIC session is driven by a 966 sender. There may be periods where the sender has no application 967 data to send for a period longer than the session idle timeout. This 968 profile repurposes the QUIC "PING" frame to act as a unidirectional 969 keep-alive message that may be sent in order to inform receivers that 970 the session should remain in the Fully-established state. 971 [QUIC-TRANSPORT] contains guidance on the sending frequency of QUIC 972 "PING" frames. 974 Senders MAY send a QUIC "PING" frame at any time in order to inform 975 receivers that the session traffic flow has not fallen idle. This 976 frame MUST NOT be acknowledged. Indeed, QUIC "ACK" frames are 977 prohibited by this profile (Section 4.11). 979 Receiving participants MUST NOT make any attempt to send QUIC "PING" 980 frames. 982 4.11. Loss Detection and Recovery 984 Receivers implementing this profile MUST NOT make any attempt to 985 acknowledge the reception of QUIC packets. The QUIC "ACK" frame is 986 prohibited for both senders and receivers. Reception of this frame 987 MUST be handled as described in Section 4.12. 989 Section 7 specifies alternative strategies for loss recovery. 991 4.12. Prohibited QUIC Frames and Packets 993 The following QUIC packets MUST NOT be transmitted by participants: 994 Any packets with a long header (Initial, 0-RTT Protected, Handshake, 995 Retry), Version Negotiation, Stateless Reset. 997 The following QUIC frames MUST NOT be transmitted by participants: 998 "ACK", "CONNECTION_CLOSE", "CRYPTO", "DATA_BLOCKED", "MAX_DATA", 999 "MAX_STREAM_DATA", "MAX_STREAMS", "NEW_CONNECTION_ID", "NEW_TOKEN", 1000 "PATH_CHALLENGE", "PATH_RESPONSE", "RETIRE_CONNECTION_ID", 1001 "STOP_SENDING", "STREAM_DATA_BLOCKED", "STREAMS_BLOCKED". 1003 The following QUIC frames MUST NOT be transmitted by receivers: 1004 "PING", "RESET_STREAM". 1006 Reception of a prohibited QUIC frame or packet is a protocol error. 1007 Receivers MUST ignore all prohibited QUIC frames and packets. 1009 5. HTTP/3 Profile 1011 *Authors' Note:* The HTTP/3 mapping document is subject to change. 1012 This section is based on our best understanding of draft-ietf- 1013 quic-http-17. The authors will track developments and will update 1014 this section accordingly. 1016 HTTP over multicast QUIC depends on HTTP server push, as described in 1017 Section 4.4 of [QUIC-HTTP]. Section 5.2 below applies an additional 1018 constraint on the use of server push. A multicast sender 1019 participating in a session pushes resources as a series of QUIC 1020 "STREAM" frames carrying HTTP/3 "PUSH_PROMISE", "HEADERS" and "DATA" 1021 frames. Examples of this are provided in Appendix B.2. Senders MUST 1022 comply with the requirements of the session parameters, as described 1023 earlier in Section 3. 1025 The profile of HTTP/3 specified in this section places additional 1026 constrains on the use of metadata compression (Section 5.3) and 1027 prioritisation (Section 5.4). 1029 5.1. HTTP Connection Settings 1031 The HTTP/3 "SETTINGS" frame is prohibited by this profile. 1032 Participants MUST NOT make any attempt to send this frame type. 1033 Reception of this frame MUST be handled as described in Section 5.7. 1035 5.2. Server Push 1037 Server push is, by default, disabled for HTTP/3 connections. A 1038 conventional HTTP/3 client enables and manages server push by 1039 controlling the maximum Push ID ([QUIC-HTTP], Section 5.2.6), 1040 achieved by sending the HTTP/3 "MAX_PUSH_ID" frame. 1042 This profile mandates the use of server push, and specifies no means 1043 to disable it. The maximum Push ID for multicast QUIC sessions 1044 (initial and always) is 2^62. Values of Push ID SHALL be allocated 1045 in accordance with [QUIC-HTTP]. 1047 Server push concurrency in multicast QUIC is described in 1048 Section 3.6. There is no role for the HTTP/3 "MAX_PUSH_ID" frame and 1049 it is prohibited. Participants MUST NOT send this frame type. 1050 Reception of this frame type MUST be handled as described in 1051 Section 5.7. 1053 When opening a stream for a new server-pushed resource, the first 1054 byte on the stream is the Stream Type. For this profile, the Stream 1055 Type for any new server-initiated unidirectional stream MUST be 1056 Server Push ("P", "0x50"). 1058 The HTTP/3 "CANCEL_PUSH" frame MAY be used by sending participants to 1059 abort sending a response for the identified server push. Usage of 1060 this frame SHALL follow the guidance for servers in [QUIC-HTTP]. 1062 Receiving participants MUST NOT make any attempt to send HTTP/3 1063 "CANCEL_PUSH" frames to the multicast group. 1065 Conventionally, pushed responses are associated with an explicit 1066 request from a client. This is not possible when using a 1067 unidirectional transport such as multicast IP. This profile reserves 1068 the first client-initiated, bidirectional QUIC stream. HTTP/3 1069 "PUSH_PROMISE" frames MUST be sent on this reserved Stream ID. 1071 *Authors' Note:* The exact value of this Stream ID is currently in 1072 flux. This section will track developments and will be updated 1073 accordingly. It is currently expected to be Stream ID 0. 1075 5.3. Metadata Compression 1077 The compression of HTTP header fields is considered in QPACK 1078 [QUIC-QPACK], which describes two methods for the compression of HTTP 1079 header fields: indexing (via static or dynamic tables) and Huffman 1080 encoding. 1082 A multicast QUIC session, as described in the present document, does 1083 not provide the assurances (receiver participation, transport 1084 reliability) required to sufficiently maintain the dynamic decoding 1085 context. Therefore, this document requires that endpoints SHALL NOT 1086 use dynamic indexing. It is RECOMMENDED that endpoints use static 1087 indexing and/or Huffman encoding in order to benefit from the 1088 remaining compression methods available. 1090 5.4. Prioritisation 1092 The HTTP/3 "PRIORITY" frame is prohibited by this profile. 1093 Participants MUST NOT make any attempt to send this frame type. 1094 Reception of this frame MUST be handled as described in Section 5.7. 1096 5.5. Session Tear-down 1098 A multicast QUIC session MAY be explicitly torn down by means of the 1099 "Connection: close" HTTP header described in section 6.6 of 1100 [RFC7230]. A sender intending to leave the session SHOULD include 1101 the "Connection: close" header in its response metadata. A sender 1102 SHOULD transmit all outstanding frames related to remaining request/ 1103 response exchanges before ending transmission to the multicast group. 1104 A receiver SHOULD continue to receive and process frames until all 1105 outstanding request/response exchanges are complete. 1107 5.6. HTTP/3 Extension frames 1109 HTTP/3 extension frames (e.g. "ALTSVC") are prohibited by this 1110 profile. Participants MUST NOT make any attempt to send extension 1111 frame types. Reception of these MUST be handled as described in 1112 Section 5.7. 1114 5.7. Prohibited HTTP/3 Frames 1116 The following HTTP/3 frames MUST NOT be transmitted by participants: 1117 "DUPLICATE_PUSH", "GOAWAY", "MAX_PUSH_ID", "PRIORITY", "SETTINGS". 1119 In addition, all HTTP/3 extension frame types MUST NOT be transmitted 1120 by participants. 1122 The following HTTP/3 frames MUST NOT be transmitted by receivers: 1123 "CANCEL_PUSH". 1125 Reception of a prohibited HTTP/3 frame is a protocol error. 1126 Receivers MUST ignore prohibited HTTP/3 frames. 1128 6. Application-Layer Security 1130 As already described in Section 3.2, the implicit cipher suite used 1131 by a multicast QUIC session makes very limited provision for security 1132 in the transport and session layers. This section profiles the use 1133 of some additional features to provide equivalent functionality at 1134 the application-layer. 1136 6.1. Content Integrity 1138 In many applications, it is important to ensure that an HTTP 1139 representation has been received intact (i.e. has not suffered from 1140 transmission loss or random bit errors) before passing the received 1141 object on to the receiving application. A mechanism is therefore 1142 specified here to provide end-to-end content integrity protection for 1143 HTTP representations in transit. The use of this content integrity 1144 mechanism is RECOMMENDED. 1146 *Authors' Note:* We invite review comments on mandating the use of 1147 this content integrity mechanism. 1149 [RFC3230] specifies an instance digest HTTP header called "Digest". 1150 A sender MAY include this header in the HTTP/3 "HEADERS" frame of any 1151 representation it transmits and a receiver MAY use this header to 1152 validate the integrity of the received representation once it has 1153 been reassembled. Where this validation fails, the receiver SHOULD 1154 discard the representation without processing it further. 1156 Note that the digest value protects a whole HTTP instance (i.e. the 1157 representation of a resource at the point of transmission as opposed 1158 to the body of a particular HTTP message). In cases where partial 1159 representations are fragmented over one or more HTTP response 1160 messages, the digest value is computed over the complete 1161 representation prior to fragmentation into partial responses. 1163 Any of the algorithms specified in the IANA registry of digest 1164 algorithms (http://www.iana.org/assignments/http-dig-alg/http-dig- 1165 alg.xhtml#http-dig-alg-1) MAY be used in conjunction with the 1166 "Digest" header. There is no requirement for participants to support 1167 the full set of algorithms. 1169 6.2. Content Authenticity 1171 In some applications, it is important for a receiver to reassure 1172 itself that an HTTP representation has been received from an 1173 authentic source. It is also sometimes useful for a receiver to know 1174 that the information has not been tampered with in transit by a 1175 malicious intermediate actor. A mechanism is therefore specified 1176 here to prove the authenticity of HTTP messages in transit. The use 1177 of this content authenticity mechanism is RECOMMENDED for senders 1178 implementing this specification. 1180 *Authors' Note:* We invite review comments on mandating the use of 1181 this content authenticity mechanism. 1183 [I-D.cavage-http-signatures] specifies a means of securely signing 1184 metadata associated with any HTTP message. The resulting digital 1185 signature is conveyed in the "Signature" header of the message 1186 itself. The "Signature" header also conveys a list of HTTP header 1187 fields over which the signature was computed. A receiver MAY verify 1188 the "Signature" header in order to validate the authenticity of 1189 received metadata. Where this validation fails, the receiver SHOULD 1190 discard or ignore any related metadata and/or data without processing 1191 it further. 1193 Note that the signature proves the authenticity of the metadata in a 1194 single HTTP message. A "Signature" header MAY be included separately 1195 in the HTTP/3 "PUSH_PROMISE" frame (protecting the request metadata) 1196 and in the final (or only) HTTP/3 "HEADERS" frame relating to a 1197 particular resource (protecting the response metadata). In order to 1198 provide an additional level of protection, however, it is RECOMMENDED 1199 that the signature be computed over the combined request metadata 1200 (from the "PUSH_PROMISE" frame) and the corresponding response 1201 metadata (from the HTTP/3 "HEADERS" frames) of the same resource. 1202 This binds the request metadata and response metadata together, 1203 providing the receiver with additional reassurance of authenticity. 1204 In this latter case, the combined digital signature SHALL be conveyed 1205 in the final (or only) HTTP/3 "HEADERS" frame. 1207 In applications where the detection of replay attacks is a 1208 requirement, it is RECOMMENDED that the "Date" header be included in 1209 the scope of the signature. It is RECOMMENDED that receivers use the 1210 value of the "Date" header for replay detection using appropriate 1211 strategies (e.g. checking for freshness). The definition of such 1212 strategies is beyond the scope of this document. 1214 In applications where the authenticity and integrity of the 1215 transmission are both important, it is RECOMMENDED that the "Digest" 1216 header specified in Section 6.1 above is included in the scope of the 1217 signature. By signing the instance digest, the authenticity and 1218 integrity of the HTTP message body are also assured in addition to 1219 that of the metadata. 1221 Any of the algorithms specified in the IANA registry of signature 1222 algorithms (http://www.iana.org/assignments/signature-algorithms) MAY 1223 be used in conjunction with the "Signature" header. There is no 1224 requirement for participants to support the full set of algorithms. 1226 6.3. Content Confidentiality 1228 In applications where there is a requirement for the content itself 1229 to remain confidential, appropriate steps SHOULD be taken to protect 1230 the application payload, for example by encrypting it. This document 1231 does not preclude the use of application-level encryption, but does 1232 not specify a mechanism for the distribution of content decryption 1233 keys. 1235 7. Loss Recovery 1237 Because the acknowledgement of received packets to multicast groups 1238 is prohibited by this specification (Section 4.11) the detection of 1239 discarded or corrupted packets is the sole responsibility of the 1240 receiver, and such losses must be recovered by means other than the 1241 retransmission mechanism specified in [QUIC-TRANSPORT] and 1242 [QUIC-RECOVERY]. 1244 7.1. Forward Error Correction 1246 *Authors' Note:* A simple parity-based Forward Error Correction 1247 scheme was removed from the experimental QUIC wire protocol 1248 specification in version Q032. The IETF's QUIC Working Group is 1249 chartered to specify one (or more) new FEC schemes in the future. 1250 This section will track developments in this area, and will be 1251 updated accordingly. 1253 A sender MAY make use of a suitable Forward Error Correction scheme 1254 to allow a receiver to reconstruct lost packets from those that have 1255 been successfully received. 1257 7.2. Unicast Repair 1259 In the case where a lost QUIC packet cannot be recovered using 1260 Forward Error Correction, either because the number of packets lost 1261 exceeds the scheme's threshold for reconstruction, or because FEC is 1262 not in use on the multicast QUIC session, a receiver MAY instead 1263 recover the missing payload data using conventional unicast HTTP 1264 requests to an origin server. 1266 o The total size of the resource is indicated in the "content- 1267 length" response header carried in the HTTP/3 "HEADERS" frame. 1269 o The location of the missing data can be determined by examining 1270 the Offset field in the QUIC "STREAM" frame headers of 1271 successfully received QUIC packets. 1273 Using this information, a receiver MAY compose an efficient HTTP 1274 range request [RFC7233] to the origin server indicated in the URL. 1275 Several disjoint ranges MAY be combined into a single HTTP request. 1276 A receiver MAY direct its request to an alternative server using Alt- 1277 Svc information received on the multicast QUIC session, or else 1278 received as part of a previous unicast HTTP response according to the 1279 rules in [RFC7838]. 1281 8. Transmission of Partial Content 1283 Under certain circumstances, a sender may not be in full possession 1284 of a resource body when transmission begins, or may not be able to 1285 guarantee that a transmission will complete. In such cases, the 1286 sender MAY employ the syntax of an HTTP range request [RFC7233] to 1287 indicate partial content, as specified below. All receivers SHALL 1288 implement support for such HTTP range requests. 1290 If partial content is to be transmitted: 1292 o The "range" header (Section 3.1 of [RFC7233]) SHALL be present in 1293 the HTTP/3 "PUSH_PROMISE" frame. 1295 o The corresponding HTTP/3 "HEADERS" frame SHALL indicate HTTP 1296 status code 206. 1298 * The range being transmitted SHALL be indicated in a "content- 1299 range" header field and the size of the complete resource 1300 indicated in a "content-length" header field. 1302 9. Protocol Identifier 1304 The HTTP over multicast QUIC protocol specified in this document is 1305 identified by the application-layer protocol negotiation (ALPN) 1306 [RFC7301] identifier "hqm". The IANA registration of this protocol 1307 identifier can be found in Section 12.1. This reserves the ALPN 1308 identifier space but describes a protocol that does not use TLS. The 1309 usage of the "hqm" identifier for discoverability is described in 1310 Section 10. 1312 9.1. Draft Version Identification 1314 *RFC Editor's Note:* Please remove this section prior to 1315 publication of a final version of this document. 1317 Only implementations of the final, published RFC can identify 1318 themselves as "hqm". Until such an RFC exists, implementations MUST 1319 NOT identify themselves using this string. 1321 Implementations of draft versions of the protocol MUST add the string 1322 "-" and the corresponding draft number to the identifier. For 1323 example, draft-pardue-quic-http-mcast-00 is identified using the 1324 string "hqm-00". 1326 Non-compatible experiments that are based on these draft versions 1327 MUST append the string "-" and an experiment name to the identifier. 1328 For example, an experimental implementation based on draft-pardue- 1329 quic-http-mcast-09 which removes the requirement to ensure version 1330 matches might identify itself as "hqm-09-version-ignorant". Note 1331 that any label MUST conform to the "token" syntax defined in 1332 Section 3.2.6 of [RFC7230]. Experimenters are encouraged to 1333 coordinate their experiments. 1335 10. Discovery of Multicast QUIC Sessions 1337 The announcement and discovery of services operating over multicast 1338 IP has previously been specified by the Session Description Protocol 1339 (SDP) [RFC4566], Session Announcement Protocol [RFC2974] and Session 1340 Initiation Protocol [RFC3261]. These are typically deployed together 1341 and in conjunction with a multicast-friendly transport such as the 1342 Real-time Transport Protocol (RTP) [RFC3550]. 1344 In contrast, the present document specifies a mechanism for 1345 advertising services that is built into HTTP metadata and is 1346 consistent across unicast and multicast resource delivery modes. 1347 This means that a single application-layer can be used for service 1348 advertisement/discovery, and for bulk data transmission/reception. 1349 Specifically, the "Alt-Svc" HTTP header is specified as the means to 1350 advertise multicast services from a unicast service. A unicast HTTP 1351 response MAY be decorated with an Alt-Svc value that hints to the 1352 client about the availability of the resource via a multicast QUIC 1353 session. A client that supports such a multicast QUIC session MAY 1354 then transparently switch to it. 1356 Symmetrically, the "Alt-Svc" header can also be used to advertise the 1357 unicast service from a multicast service. A resource transmitted as 1358 part of a multicast QUIC session MAY be decorated with an Alt-Svc 1359 value that hints to the client about the availability of the resource 1360 via an alternative unicast HTTP server. A receiver MAY then use this 1361 HTTP server for unicast resource patching (Section 7.2). 1363 Where HTTP over multicast QUIC sessions are advertised using Alt-Svc, 1364 the protocol identifier SHALL be "hqm", as specified in Section 9. 1366 10.1. Source-specific Multicast Advertisement 1368 Source-specific multicast (SSM) [RFC4607] MAY be used for the 1369 delivery of multicast services. 1371 *Authors' Note:* We invite review comments on mandating the use of 1372 source-specific multicast only. 1374 This document specifies the "source-address" parameter for Alt-Svc, 1375 which is used to provide the SSM source address to endpoints. 1377 Syntax: 1379 source-address = uri-host; see RFC7230, Section 2.7 1381 For example: 1383 source-address="192.0.2.1" 1385 When a multicast QUIC session is provided using SSM, the "source- 1386 address" parameter MUST be advertised. 1388 10.2. Session Parameter Advertisement 1390 The concept of session parameters is introduced in Section 2.2. This 1391 section details how the session parameters are expressed as Alt-Svc 1392 parameters. 1394 10.2.1. Version 1396 The version of QUIC supported in a multicast QUIC session is 1397 advertised with the "quic" parameter. The requirements for endpoint 1398 usage of "quic" are specified in Section 3.1. 1400 10.2.2. Cipher Suite 1402 This document specifies the "cipher-suite" parameter for Alt-Svc, 1403 which carries the cipher suite in use by a multicast QUIC session. 1404 "cipher-suite" MUST contain one of the values contained in the TLS 1405 Cipher Suite Registry (http://www.iana.org/assignments/tls- 1406 parameters/tls-parameters.xhtml#tls-parameters-4): 1408 Syntax: 1410 cipher-suite = 4*4 HEXDIG 1412 For example, the following specifies cipher suite 0x13,0x01 1413 ("TLS_AES_128_GCM_SHA256"): 1415 cipher-suite=1301 1417 The requirements for endpoint usage of "cipher-suite" are described 1418 in Section 3.2. 1420 10.2.3. Session Key 1422 This document specifies the "key" parameter for Alt-Svc, which 1423 carries the cryptographic key in use by the multicast QUIC session. 1425 Syntax: 1427 key = *HEXDIG 1429 For example: 1431 key=4adf1eab9c2a37fd 1433 The requirements for endpoint usage of "key" are described in 1434 Section 3.2. 1436 10.2.4. Session Cipher Initialization Vector 1438 This document specifies the "iv" parameter for Alt-Svc, which carries 1439 the cipher Initialization Vector (IV) in use by the multicast QUIC 1440 session. 1442 Syntax: 1444 iv = *HEXDIG 1446 For example: 1448 iv=4dbe593acb4d1577ad6ba7dc3189834e 1450 The requirements for endpoint usage of "iv" are described in 1451 Section 3.2. 1453 10.2.5. Session Identification 1455 This document defines the "session-id" parameter for Alt-Svc, which 1456 carries the multicast QUIC session identifier. 1458 Syntax: 1460 session-id = *HEXDIG 1462 For example, the following specifies session 101 (0x65 hexadecimal): 1464 session-id=65 1466 The requirements for endpoint usage of "session-id" are described in 1467 Section 2.3. In the above example, the Destination Connection ID 1468 field in every QUIC packet header would be one byte in size. For a 1469 session-id of BADBEEF then then Destintation Connection ID field in 1470 every QUIC packet header would be four bytes in size. 1472 10.2.6. Session Idle Timeout Period 1474 This document specifies the "session-idle-timeout" parameter for Alt- 1475 Svc, which carries the idle timeout period of a multicast QUIC 1476 session. 1478 Syntax: 1480 session-idle-timeout = *DIGIT ; number of seconds between 0 and 600 1482 For example, the following specifies a one-minute session idle 1483 timeout period: 1485 session-idle-timeout=60 1487 The requirements for endpoint usage of "session-idle-timeout" are 1488 described in Section 3.4. 1490 10.2.7. Resource Concurrency 1492 This document specifies the "max-concurrent-resources" parameter for 1493 Alt-Svc, which expresses the maximum number of concurrent active 1494 resources from the sender in a multicast QUIC session. 1496 Syntax: 1498 max-concurrent-resources = *DIGIT ; unsigned 32-bit integer 1500 For example, the following specifies that no more than 12 (decimal) 1501 resources will be concurrently active in the session: 1503 max-concurrent-resources=12 1505 The requirements for endpoint usage of "max-concurrent-resources" are 1506 described in Section 3.6. 1508 10.2.8. Session Peak Flow Rate 1510 This document specifies the "peak-flow-rate" parameter for Alt-Svc, 1511 which expresses the expected maximum aggregate transfer rate of data 1512 from all sources of the multicast QUIC session. 1514 Syntax: 1516 peak-flow-rate = *DIGIT ; bits per second 1518 For example, the following specifies a peak flow rate of 550 kbits/s 1519 in the session: 1521 peak-flow-rate=550000 1523 The requirements for endpoint usage of "peak-flow-rate" are described 1524 in Section 3.5. 1526 10.2.9. Digest Algorithm 1528 This document specifies the "digest-algorithm" parameter for Alt-Svc, 1529 which carries the digest algorithm in use by a multicast QUIC 1530 session. "digest-algorithm" MUST contain one of the values defined in 1531 the HTTP Digest Algorithm Values registry 1532 (https://www.iana.org/assignments/http-dig-alg/http-dig- 1533 alg.xhtml#http-dig-alg-1). 1535 Syntax: 1537 digest-algorithm = token 1539 For example, the following specifies a digest algorithm of SHA-256: 1541 digest-algorithm=SHA-256 1543 The requirements for endpoint usage of "digest-algorithm" are 1544 described in Section 3.8. 1546 10.2.10. Signature Algorithm 1548 This document specifies the "signature-algorithm" parameter for Alt- 1549 Svc, which carries the signature algorithm in use by a multicast QUIC 1550 session. "signature-algorithm" MUST contain one of the values defined 1551 in the Signature Algorithms registry 1552 (http://www.iana.org/assignments/signature-algorithms). 1554 Syntax: 1556 signature-algorithm = token 1558 For example, the following specifies a signature algorithm of SHA- 1559 256: 1561 signature-algorithm=rsa-sha256 1562 The requirements for endpoint usage of "signature-algorithm" are 1563 described in Section 3.9. 1565 11. Security and Privacy Considerations 1567 This document specifies a profile of QUIC and HTTP/3 that changes the 1568 security model. In order to address this, application-level security 1569 methods are described in Section 6. This document does not preclude 1570 the use of secure multicast approaches that may provide additional 1571 security assurances required for certain use cases. 1573 The use of side-channel or out-of-band technologies (potentially 1574 bidirectional interactions) to support multicast QUIC sessions are 1575 considered out of this document's scope. Services using such 1576 technologies should apply their security considerations accordingly. 1578 11.1. Pervasive Monitoring 1580 Certain multicast deployment architectures may require the use of a 1581 session decryption key shared by all participants. Furthermore, the 1582 discovery mechanism described in this document provides a means for a 1583 receiver to obtain a session decryption key without joining the 1584 session. The act of removing packet protection in order to inspect 1585 or modify application contents may, in certain deployments, be 1586 trivial. The exploration of restricting key learning or session 1587 joining to authorised participants goes beyond the scope of this 1588 document. 1590 Because in-band multicast interactions are unidirectional, the impact 1591 of Pervasive Monitoring [RFC7258] on in-band traffic flows is 1592 inherently reduced. Actors can only inspect or modify sender- 1593 initiated traffic. Additional measures for content confidentiality 1594 may mitigate the impact further. This is discussed in Section 6.3. 1596 Further Pervasive Monitoring concerns are addressed in the following 1597 sections. 1599 11.1.1. Large-scale Data Gathering and Correlation 1601 Multicast QUIC sessions decouple sending and receiving participants. 1602 Session participation is subject to operations that allow an endpoint 1603 to join or leave a multicast group, typically IGMP [RFC3376] or MLD 1604 [RFC3810]. The propagation intent of these messages travelling 1605 deeper through a network hierarchy generally leads to the 1606 anonymisation of data if implemented as specified. It may be 1607 possible to gather user-identifiable messages close to the network 1608 edge, for example a router logging such messages. However, this 1609 would require wide-ranging access across Internet Service Provider 1610 networks. Therefore, while such attacks are feasible, it can be 1611 asserted that gathering and correlating user-identifiable traffic is 1612 difficult to perform covertly and at scale. 1614 11.1.2. Changing Content 1616 Sessions that use a symmetric key for packet protection are subject 1617 to the possibility of a malicious actor modifying traffic at some 1618 point in the network between a legitimate sender and one (or more) 1619 receivers. Receiver-side validation, as specified in Section 6 of 1620 the present document, and also in [QUIC-TRANSPORT], allows for the 1621 detection of such modification. Two approaches help mitigate the 1622 impact of modification; the first is application-level methods that 1623 protect data (Section 6.1) and metadata (Section 6.2); the second is 1624 reduction of the QUIC packet attack surface by means of removal of 1625 many frame types (Section 4.12 and Section 5.7). 1627 11.2. Protection of Discovery Mechanism 1629 Multicast QUIC session advertisements SHOULD be conveyed over a 1630 secure transport that guarantees authenticity and integrity in order 1631 to mitigate attacks related to a malicious service advertisement, for 1632 example a "man in the middle" directing endpoints to a service that 1633 may lead to other attacks or exploitations. 1635 *Authors' Note:* We invite review comments on mandating the use of 1636 a secure transport for advertising sessions. 1638 Endpoints that make use of multicast QUIC session advertisements 1639 SHOULD have reasonable assurance that the alternative service is 1640 under control of, and valid for, the whole origin, as described in 1641 Section 2.1 of [RFC7838]. Section 6.2 discusses measures that may be 1642 used to fulfil this requirement. 1644 11.3. Spoofing 1646 11.3.1. Spoofed Ack Attacks 1648 The Spoofed "ACK" attack described in Section 13.1 of 1649 [QUIC-TRANSPORT] is out of scope because use of the QUIC "ACK" frame 1650 is prohibited (Section 4.11) by the present document. 1652 11.3.2. Sender Spoofing 1654 A malicious actor may be able to stage a spoof attack by sending fake 1655 QUIC packets to a multicast QUIC session. This could affect the 1656 operation or behaviour of receivers. In a multicast scenario, this 1657 form of attack has the potential to scale massively. 1659 The feasibility of spoofing a multicast sender is governed by the 1660 characteristics of the multicast deployment and network 1661 infrastructure. The use of source-specific multicast [RFC4607] may 1662 reduce the feasibility. The use of content authenticity 1663 (Section 6.2) may mitigate concerns for the application-level 1664 messages. However, there remains the possibility for transport-level 1665 messages to be spoofed. Multicast applications should consider 1666 further mitigations to address this concern. 1668 11.3.3. Receiver Spoofing 1670 Client source address concerns discussed in Section 7.5 of 1671 [QUIC-TRANSPORT] are out of scope because the connection 1672 establishment is replaced with session establishment in the present 1673 document. Further, the impact that spoofed receivers would have on 1674 the sender is minimal. The impact of malicious participants on the 1675 network is discussed in Section 11.6.2. 1677 11.4. Replay Attacks 1679 Conventional QUIC strategies for protecting against replay attacks 1680 apply similarly here. 1682 Certain multicast QUIC sessions may use a shared key for transport- 1683 level encryption, which would allow an attacker to record, decrypt, 1684 repackage and replay QUIC packets. Section 6.2 discusses how the 1685 application-level contents may be protected from replay (by signing 1686 the "Date" HTTP header), which provides some mitigation to the 1687 success rate or effects of replay attacks. 1689 11.5. Message Deletion 1691 Since HTTP over multicast QUIC is designed to tolerate unreliable 1692 delivery, the impacts of message deletion attacks are presumed to be 1693 small. Deletion of packets carrying HTTP headers will cause a 1694 receiver to ignore subsequent packets carrying body data. 1695 Furthermore, the use of multicast QUIC sessions is opportunistic; 1696 disruption in service (for example, deleting packets and causing a 1697 receiver to fail in construction of a content object) is mitigated by 1698 falling back to a unicast service. Considerations for how this may 1699 affect the performance of the unicast service are given in 1700 Section 11.6.3. 1702 11.6. Denial of Service 1703 11.6.1. Unprotected Frames and Packets 1705 The handling of unprotected QUIC packets is discussed in section 1706 9.1.4 of [QUIC-TLS]. The profile described in the present document 1707 provides the means for a multicast sender to protect QUIC packets 1708 with a shared key, which is not a strong protection. The weak 1709 protection of QUIC packets could present a denial-of-service risk. 1710 To mitigate the impact of handling such QUIC packets, certain frames 1711 and packets are prohibited as described in (Section 4.12 and 1712 Section 5.7). 1714 The frame types that are allowed by this profile do not present a 1715 risk of denial of service. Concerns over authenticity and integrity 1716 are addressed by the application-layer protection mechanisms 1717 described in Section 6. 1719 11.6.2. Network Performance Degradation 1721 The possibility for malfunctioning or malicious participants to 1722 degrade the network is a broad issue and considered out of scope for 1723 this document. Guidelines and concerns discussed in UDP Best 1724 Practices [RFC8085] and other sources apply equally here. This 1725 specification does not preclude the use of network performance 1726 degradation mitigation solutions such as network circuit breakers. 1728 11.6.3. Unicast Repair Stampeding Herd 1730 Deployments that support the unicast repair mechanism described in 1731 Section 7.2 should be aware that a triggering of this behaviour 1732 (either deliberate, planned or unplanned) in a large population of 1733 multicast receivers may cause a stampeding herd of client requests to 1734 the unicast repair service. Service operators SHOULD mitigate the 1735 impact of stampeding herd on their deployment. 1737 11.7. Receiver Resource Usage 1739 The application of receiver-side validation, as defined in the 1740 present document and in [QUIC-TRANSPORT], adds some protection 1741 against allocating resource to the processing of bad data. 1743 11.8. Unicast Repair Information Leakage 1745 The unicast repair mechanism may lead to the leakage of user 1746 behaviour data. An attacker could gain insight into any receiver 1747 participating in a multicast QUIC session, for example by monitoring 1748 the TCP port of the unicast alternative. This alone is no worse than 1749 current abilities to monitor unicast interactions, for example 1750 observing the SNI field contained in a TLS ClientHello. The complete 1751 protection of unicast interactions is beyond the scope of this 1752 document. However, knowledge that a user (or group of users) has 1753 participated in a session is sensitive and may be obtained by 1754 correlation between with observable multicast and unicast traffic. 1756 To give an example, a malicious "man in the middle" could purposely 1757 cause all receivers to perform a unicast repair (by disrupting the 1758 QUIC traffic flow in some way). The disruption is untargeted and may 1759 be simple to orchestrate, but the correlation of user activity data, 1760 especially across a distributed repair service (e.g. a CDN), requires 1761 resources that may reduce the attractiveness of such an attack. 1763 The ability for an attacker to disrupt multicast QUIC sessions is 1764 mitigated by this profile (mainly the prohibition of frames and 1765 packets). Application-layer security measures described in Section 6 1766 reduce the feasibility further. 1768 Multicast receivers concerned about this form of leakage can 1769 eliminate this risk completely by disabling support for unicast 1770 repair, at the potential cost of reduced service quality. 1772 12. IANA Considerations 1774 12.1. Registration of Protocol Identification String 1776 This document creates a new registration for the identification of 1777 the HTTP over multicast QUIC protocol in the "Application-Layer 1778 Protocol Negotiation (ALPN) Protocol IDs" registry established by 1779 [RFC7301]. 1781 The "hqm" string identifies HTTP semantics expressed as HTTP mapped 1782 to a QUIC layer and carried over IP multicast: 1784 Protocol: Bulk data transport using HTTP over multicast QUIC 1786 Identification Sequence: 0x68 0x71 0x6D ("hqm") 1788 Specification: This document, Section 9 1790 This entry reserves an identifier that is not allowed to appear in 1791 TLS Application-Layer Protocol Negotiation. 1793 12.2. Registration of Alt-Svc parameters 1795 This document creates seven registrations for the identification of 1796 parameters for the "Hypertext Transfer Protocol (HTTP) Alt-Svc 1797 Parameter Registry" established by [RFC7838] 1798 (http://www.iana.org/assignments/tls-extensiontype-values/tls- 1799 extensiontype-values.xhtml#alpn-protocol-ids). 1801 12.2.1. Source Address 1803 Parameter name: source-address 1805 Specification: This document, Section 10.1 1807 12.2.2. Cipher Suite 1809 Parameter name: cipher-suite 1811 Specification: This document, Section 10.2.2 1813 12.2.3. Key 1815 Parameter name: key 1817 Specification: This document, Section 10.2.3 1819 12.2.4. Initialization Vector 1821 Parameter name: iv 1823 Specification: This document, Section 10.2.4 1825 12.2.5. Session Identifier 1827 Parameter name: session-id 1829 Specification: This document, Section 10.2.5 1831 12.2.6. Session Idle Timeout 1833 Parameter name: session-idle-timeout 1835 Specification: This document, Section 10.2.6 1837 12.2.7. Maximum Concurrent Resources 1839 Parameter name: max-concurrent-resources 1841 Specification: This document, Section 10.2.7 1843 12.2.8. Peak Flow Rate 1845 Parameter name: peak-flow-rate 1847 Specification: This document, Section 10.2.8 1849 12.2.9. Digest Algorithm 1851 Parameter name: digest-algorithm 1853 Specification: This document, Section 10.2.9 1855 12.2.10. Signature Algorithm 1857 Parameter name: signature-algorithm 1859 Specification: This document, Section 10.2.10 1861 13. References 1863 13.1. Normative References 1865 [I-D.cavage-http-signatures] 1866 Cavage, M. and M. Sporny, "Signing HTTP Messages", draft- 1867 cavage-http-signatures-10 (work in progress), May 2018. 1869 [QUIC-HTTP] 1870 Bishop, M., Ed., "Hypertext Transfer Protocol Version 3 1871 (HTTP/3)", draft-ietf-quic-http-18 (work in progress). 1873 [QUIC-QPACK] 1874 Krasic, C., Ed., Bishop, M., Ed., and A. Frindell, Ed., 1875 "QPACK: Header Compression for HTTP over QUIC", draft- 1876 ietf-quic-qpack-06 (work in progress). 1878 [QUIC-TRANSPORT] 1879 Iyengar, J., Ed. and M. Thomson, Ed., "QUIC: A UDP-Based 1880 Multiplexed and Secure Transport", draft-ietf-quic- 1881 transport-18 (work in progress). 1883 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 1884 Requirement Levels", BCP 14, RFC 2119, 1885 DOI 10.17487/RFC2119, March 1997, 1886 . 1888 [RFC3168] Ramakrishnan, K., Floyd, S., and D. Black, "The Addition 1889 of Explicit Congestion Notification (ECN) to IP", 1890 RFC 3168, DOI 10.17487/RFC3168, September 2001, 1891 . 1893 [RFC3230] Mogul, J. and A. Van Hoff, "Instance Digests in HTTP", 1894 RFC 3230, DOI 10.17487/RFC3230, January 2002, 1895 . 1897 [RFC4607] Holbrook, H. and B. Cain, "Source-Specific Multicast for 1898 IP", RFC 4607, DOI 10.17487/RFC4607, August 2006, 1899 . 1901 [RFC5234] Crocker, D., Ed. and P. Overell, "Augmented BNF for Syntax 1902 Specifications: ABNF", STD 68, RFC 5234, 1903 DOI 10.17487/RFC5234, January 2008, 1904 . 1906 [RFC7230] Fielding, R., Ed. and J. Reschke, Ed., "Hypertext Transfer 1907 Protocol (HTTP/1.1): Message Syntax and Routing", 1908 RFC 7230, DOI 10.17487/RFC7230, June 2014, 1909 . 1911 [RFC7233] Fielding, R., Ed., Lafon, Y., Ed., and J. Reschke, Ed., 1912 "Hypertext Transfer Protocol (HTTP/1.1): Range Requests", 1913 RFC 7233, DOI 10.17487/RFC7233, June 2014, 1914 . 1916 [RFC7234] Fielding, R., Ed., Nottingham, M., Ed., and J. Reschke, 1917 Ed., "Hypertext Transfer Protocol (HTTP/1.1): Caching", 1918 RFC 7234, DOI 10.17487/RFC7234, June 2014, 1919 . 1921 [RFC7301] Friedl, S., Popov, A., Langley, A., and E. Stephan, 1922 "Transport Layer Security (TLS) Application-Layer Protocol 1923 Negotiation Extension", RFC 7301, DOI 10.17487/RFC7301, 1924 July 2014, . 1926 [RFC7405] Kyzivat, P., "Case-Sensitive String Support in ABNF", 1927 RFC 7405, DOI 10.17487/RFC7405, December 2014, 1928 . 1930 [RFC7838] Nottingham, M., McManus, P., and J. Reschke, "HTTP 1931 Alternative Services", RFC 7838, DOI 10.17487/RFC7838, 1932 April 2016, . 1934 [RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC 1935 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, 1936 May 2017, . 1938 13.2. Informative References 1940 [QUIC-RECOVERY] 1941 Iyengar, J., Ed. and I. Swett, Ed., "QUIC Loss Detection 1942 and Congestion Control", draft-ietf-quic-recovery-18 (work 1943 in progress). 1945 [QUIC-SPIN] 1946 Trammell, B., Ed. and M. Kuehlewind, "The QUIC Latency 1947 Spin Bit", draft-ietf-quic-spin-exp-01 (work in progress). 1949 [QUIC-TLS] 1950 Thomson, M., Ed. and S. Turner, Ed, Ed., "Using Transport 1951 Layer Security (TLS) to Secure QUIC", draft-ietf-quic- 1952 tls-18 (work in progress). 1954 [RFC1112] Deering, S., "Host extensions for IP multicasting", STD 5, 1955 RFC 1112, DOI 10.17487/RFC1112, August 1989, 1956 . 1958 [RFC1191] Mogul, J. and S. Deering, "Path MTU discovery", RFC 1191, 1959 DOI 10.17487/RFC1191, November 1990, 1960 . 1962 [RFC2460] Deering, S. and R. Hinden, "Internet Protocol, Version 6 1963 (IPv6) Specification", RFC 2460, DOI 10.17487/RFC2460, 1964 December 1998, . 1966 [RFC2974] Handley, M., Perkins, C., and E. Whelan, "Session 1967 Announcement Protocol", RFC 2974, DOI 10.17487/RFC2974, 1968 October 2000, . 1970 [RFC3261] Rosenberg, J., Schulzrinne, H., Camarillo, G., Johnston, 1971 A., Peterson, J., Sparks, R., Handley, M., and E. 1972 Schooler, "SIP: Session Initiation Protocol", RFC 3261, 1973 DOI 10.17487/RFC3261, June 2002, 1974 . 1976 [RFC3376] Cain, B., Deering, S., Kouvelas, I., Fenner, B., and A. 1977 Thyagarajan, "Internet Group Management Protocol, Version 1978 3", RFC 3376, DOI 10.17487/RFC3376, October 2002, 1979 . 1981 [RFC3550] Schulzrinne, H., Casner, S., Frederick, R., and V. 1982 Jacobson, "RTP: A Transport Protocol for Real-Time 1983 Applications", STD 64, RFC 3550, DOI 10.17487/RFC3550, 1984 July 2003, . 1986 [RFC3810] Vida, R., Ed. and L. Costa, Ed., "Multicast Listener 1987 Discovery Version 2 (MLDv2) for IPv6", RFC 3810, 1988 DOI 10.17487/RFC3810, June 2004, 1989 . 1991 [RFC4566] Handley, M., Jacobson, V., and C. Perkins, "SDP: Session 1992 Description Protocol", RFC 4566, DOI 10.17487/RFC4566, 1993 July 2006, . 1995 [RFC4821] Mathis, M. and J. Heffner, "Packetization Layer Path MTU 1996 Discovery", RFC 4821, DOI 10.17487/RFC4821, March 2007, 1997 . 1999 [RFC5737] Arkko, J., Cotton, M., and L. Vegoda, "IPv4 Address Blocks 2000 Reserved for Documentation", RFC 5737, 2001 DOI 10.17487/RFC5737, January 2010, 2002 . 2004 [RFC5740] Adamson, B., Bormann, C., Handley, M., and J. Macker, 2005 "NACK-Oriented Reliable Multicast (NORM) Transport 2006 Protocol", RFC 5740, DOI 10.17487/RFC5740, November 2009, 2007 . 2009 [RFC6676] Venaas, S., Parekh, R., Van de Velde, G., Chown, T., and 2010 M. Eubanks, "Multicast Addresses for Documentation", 2011 RFC 6676, DOI 10.17487/RFC6676, August 2012, 2012 . 2014 [RFC6726] Paila, T., Walsh, R., Luby, M., Roca, V., and R. Lehtonen, 2015 "FLUTE - File Delivery over Unidirectional Transport", 2016 RFC 6726, DOI 10.17487/RFC6726, November 2012, 2017 . 2019 [RFC7258] Farrell, S. and H. Tschofenig, "Pervasive Monitoring Is an 2020 Attack", BCP 188, RFC 7258, DOI 10.17487/RFC7258, May 2021 2014, . 2023 [RFC7450] Bumgardner, G., "Automatic Multicast Tunneling", RFC 7450, 2024 DOI 10.17487/RFC7450, February 2015, 2025 . 2027 [RFC8085] Eggert, L., Fairhurst, G., and G. Shepherd, "UDP Usage 2028 Guidelines", BCP 145, RFC 8085, DOI 10.17487/RFC8085, 2029 March 2017, . 2031 Appendix A. Acknowledgements 2033 The authors would like to thank the following for their contributions 2034 to the design described in the present document: Brandon Butterworth, 2035 Chris Poole, Craig Taylor and David Waring. 2037 We are also grateful to Thomas Swindells and Magnus Westerlund for 2038 their helpful review comments. 2040 Appendix B. Examples 2042 This appendix contains examples of multicast QUIC session 2043 advertisement and resource transfer (with and without application- 2044 layer content security). 2046 B.1. Session Advertisement 2048 This section shows several different examples of an HTTP service 2049 advertising a multicast QUIC session. Examples are given in IPv4 2050 form, using reserved address ranges as specified in [RFC5737] and 2051 [RFC6676]. 2053 B.1.1. Source-specific Multicast QUIC Session 2055 Advertisement of a multicast QUIC session operating on the source- 2056 specific multicast group address 232.0.0.1 on port 2000 with the 2057 source address 192.0.2.1. The session ID is 16 (0x10) and the idle 2058 timeout is one minute. At most 10 resources may be concurrently 2059 active in the session and the flow rate should not exceed 10 kbits/s. 2060 The multicast transport is unencrypted. 2062 HTTP Alternative Service header field: 2064 Alt-Svc: 2065 hqm="232.0.0.1:2000"; source-address="192.0.2.1"; quic=1; 2066 session-id=10; session-idle-timeout=60; 2067 max-concurrent-resources=10; peak-flow-rate=10000 2069 B.1.2. Source-specific Multicast QUIC Session with Transport Encryption 2070 using a Symmetric Key 2072 Advertisement of a multicast QUIC session operating on the IPv6 2073 globally-scoped source-specific multicast group address ff3e::1234 on 2074 port 2000 with the source address 2001:db8::1. The session ID is 16 2075 (0x10) and the idle timeout is one minute. At most 10 resources may 2076 be concurrently active in the session and the flow rate should not 2077 exceed 10 kbits/s. The multicast transport is encrypted using the 2078 AEAD cipher suite 0x13,0x01 ("TLS_AES_128_GCM_SHA256") with the 2079 shared session key and IV provided. 2081 HTTP Alternative Service header field: 2083 Alt-Svc: 2084 hqm="[ff3e::1234]:2000"; source-address="2001:db8::1"; quic=1; 2085 session-id=10; session-idle-timeout=60; 2086 max-concurrent-resources=10; peak-flow-rate=10000; 2087 cipher-suite=1301; key=4adf1eab9c2a37fd; iv=4dbe593acb4d1577ad6ba7dc3189834e 2089 B.1.3. Source-specific Multicast QUIC Session with Transport 2090 Encryption, Content Integrity and Authenticity 2092 Advertisement of a multicast QUIC session operating on the IPv6 2093 globally-scoped source-specific multicast group address ff3e::1234 on 2094 port 2000 with the source address 2001:db8::1. The session ID is 16 2095 (0x10) and the idle timeout is one minute. At most 10 resources may 2096 be concurrently active in the session and the flow rate should not 2097 exceed 10 kbits/s. The multicast transport is encrypted using the 2098 AEAD cipher suite 0x13,0x01 ("TLS_AES_128_GCM_SHA256") with the 2099 shared session key and IV provided. Content integrity is in use with 2100 the digest algorithm set restricted to SHA-256. Content authenticity 2101 is in use with the signature algorithm set restricted to rsa-sha256. 2103 HTTP Alternative Service header field: 2105 Alt-Svc: 2106 hqm="[ff3e::1234]:2000"; source-address="2001:db8::1"; quic=1; 2107 session-id=10; session-idle-timeout=60; 2108 max-concurrent-resources=10; peak-flow-rate=10000; 2109 cipher-suite=1301; key=4adf1eab9c2a37fd; iv=4dbe593acb4d1577ad6ba7dc3189834e 2110 digest-algorithm=SHA-256; signature-algorithm=rsa-sha256 2112 B.2. Resource Transfer 2114 This section shows several different examples of the HTTP message 2115 patterns for a single resource. 2117 Examples that show HTTP/3 "PUSH_PROMISE" or "HEADERS" frames describe 2118 the contents of enclosed header block fragments. 2120 B.2.1. Transfer without Content Integrity or Authenticity 2122 HTTP/3 "PUSH_PROMISE" frame: 2124 :method: GET 2125 :scheme: https 2126 :path: /files/example.txt 2127 :authority: example.org 2129 HTTP/3 "HEADERS" frame; 2131 :status: 200 2132 content-length: 100 2133 content-type: text/plain 2134 date: Fri, 20 Jan 2017 10:00:00 GMT 2136 HTTP/3 "DATA" frame containing 100 bytes of response body data: 2138 ... 2140 B.2.2. Transfer of Partial Content without Content Integrity or 2141 Authenticity 2143 In this example, partial content is transferred as described in 2144 Section 8. The "Range" request header is used to indicate the 2145 sender's original intention to transfer all 100 bytes of the 2146 representation. The "Content-Range" response header indicates that 2147 only the first 50 bytes were actually sent. 2149 HTTP/3 "PUSH_PROMISE" frame: 2151 :method: GET 2152 :scheme: https 2153 :path: /files/example.txt 2154 :authority: example.org 2155 range: bytes=0-* 2157 HTTP/3 "HEADERS" frame: 2159 :status: 206 2160 content-length: 100 2161 content-range: bytes 0-49/100 2162 content-type: text/plain 2163 date: Fri, 20 Jan 2017 10:00:00 GMT 2165 HTTP/3 "DATA" frame containing 50 bytes of response body data: 2167 ... 2169 B.2.3. Transfer with Content Integrity and without Authenticity 2171 In this example, content integrity is assured by the inclusion of the 2172 "Digest" response header, as described in Section 6.1. 2174 HTTP/3 "PUSH_PROMISE" frame: 2176 :method: GET 2177 :scheme: https 2178 :path: /files/example.txt 2179 :authority: example.org 2181 HTTP/3 "HEADERS" frame including the "Digest" header: 2183 :status: 200 2184 content-length: 100 2185 content-type: text/plain 2186 date: Fri, 20 Jan 2017 10:00:00 GMT 2187 digest: SHA-256=DieQ9zfRaDdyAilTVCvmBePuxMm+B6cNocP+QCrNSqo= 2189 HTTP/3 "DATA" frame containing 100 bytes of response body data: 2191 ... 2193 B.2.4. Partial Transfer with Content Integrity and without Authenticity 2195 In this example, partial content is transferred as described in 2196 Section 8. The "Range" request header is used to indicate the 2197 sender's intention to transfer all 100 bytes of the representation. 2198 The "Content-Range" response header indicates that only the first 50 2199 bytes were actually sent. Content integrity is assured by the 2200 inclusion of the "Digest" response header, as described in 2201 Section 6.1. 2203 HTTP/3 "PUSH_PROMISE" frame: 2205 :method: GET 2206 :scheme: https 2207 :path: /files/example.txt 2208 :authority: example.org 2209 range: bytes=0-* 2211 HTTP/3 "HEADERS" frame including the "Digest" header: 2213 :status: 206 2214 content-length: 100 2215 content-range: bytes 0-49/100 2216 content-type: text/plain 2217 date: Fri, 20 Jan 2017 10:00:00 GMT 2218 digest: SHA-256=DieQ9zfRaDdyAilTVCvmBePuxMm+B6cNocP+QCrNSqo= 2220 HTTP/3 "DATA" frame containing 50 bytes of response body data: 2222 ... 2224 B.2.5. Transfer with Content Integrity and Authenticity 2226 In this example, content integrity is assured by the inclusion of the 2227 "Digest" response header, as described in Section 6.1. Content 2228 authenticity is assured separately for the request and the response 2229 messages by the "Signature" header which protects the header fields 2230 described in further detail below. The "Signature" header parameter 2231 "keyId" contains the URL of a file containing the public key related 2232 to the multicast sender's private key used to create the digital 2233 signature. 2235 HTTP/3 "PUSH_PROMISE" frame including a "Signature" header protecting 2236 the ":method" and ":path" (the request target), as well as the 2237 ":scheme" and ":authority" of the pseudo-request: 2239 :method: GET 2240 :scheme: https 2241 :path: /files/example.txt 2242 :authority: example.org 2243 signature: keyId="https://example.org/mcast-sender.example.org.pem", 2244 algorithm=rsa-sha256, 2245 headers="(request-target) :scheme :authority", 2246 signature="MGQCMFTaFptaM2FhgzJq2i9AaChuFDHjp6GiXVtRnI8BsA" 2248 HTTP/3 "HEADERS" frame including a "Signature" header protecting the 2249 ":method", ":path", ":scheme" and ":authority" of the pseudo-request 2250 above, plus the "Date" and "Digest" of the response: 2252 :status: 200 2253 content-length: 100 2254 content-type: text/plain 2255 date: Fri, 20 Jan 2017 10:00:00 GMT 2256 digest: SHA-256=DieQ9zfRaDdyAilTVCvmBePuxMm+B6cNocP+QCrNSqo= 2257 signature: keyId="https://example.org/mcast-sender.example.org.pem", 2258 algorithm=rsa-sha256, 2259 headers="(request-target) :scheme :authority date digest", 2260 signature="MGUCMBgx6cuwTzg0W29zNUra8xfMsEcb3rFA3Y" 2262 HTTP/3 "DATA" frame containing response body data: 2264 ... 2266 B.2.6. Partial Transfer with Content Integrity and Authenticity 2268 In this example, partial content is transferred and the "Range" 2269 header (as described in Section 8) is used to indicate that 50 bytes 2270 out of 100 bytes were transferred. Content integrity is provided by 2271 the inclusion of the "Digest" header, as described in Section 6.1. 2272 Authenticity is provided by the "Signature" header which protects the 2273 header fields described in further detail. The "Signature" header 2274 parameter "keyId" contains the URL of a file containing the public 2275 key related to the multicast sender's private key used to create the 2276 digital signature. 2278 HTTP/3 "PUSH_PROMISE" frame: 2280 :method: GET 2281 :scheme: https 2282 :path: /files/example.txt 2283 :authority: example.org 2284 range: bytes=0-* 2285 signature: keyId="https://example.org/mcast-sender.example.org.pem", 2286 algorithm=rsa-sha256, 2287 headers="(request-target) :scheme :authority range", 2288 signature="MGQCMFTaFptaM2FhgzJq2i9AaChuFDHjp6GiXVtRnI8BsA" 2290 HTTP/3 "HEADERS" frame protecting the ":method", ":path", ":scheme" 2291 and ":authority" of the pseudo-request above, plus the "Date", 2292 "Digest" and "Content-Range" of the response: 2294 :status: 206 2295 content-length: 100 2296 content-range: bytes 0-49/100 2297 content-type: text/plain 2298 date: Fri, 20 Jan 2017 10:00:00 GMT 2299 digest: SHA-256=DieQ9zfRaDdyAilTVCvmBePuxMm+B6cNocP+QCrNSqo= 2300 signature: keyId="https://example.org/mcast-sender.example.org.pem", 2301 algorithm=rsa-sha256, 2302 headers="(request-target) :scheme :authority 2303 date digest content-range", 2304 signature="MGUCMBgx6cuwTzg0W29zNUra8xfMsEcb3rFA3Y" 2306 HTTP/3 "DATA" frame containing response body data: 2308 ... 2310 Appendix C. Summary of differences from unicast QUIC and HTTP/3 2312 +----------------+-----------------------+--------------------------+ 2313 | Protocol | Unicast QUIC | Multicast QUIC profile | 2314 | feature | | | 2315 +----------------+-----------------------+--------------------------+ 2316 | Packet number | QUIC transport | All packets are numbered | 2317 | spaces | packets are seperated | in the application data | 2318 | | into three distinct | packet number space. | 2319 | | packet number spaces: | | 2320 | | initial, handshake | | 2321 | | and application data. | | 2322 | | | | 2323 | Transport | Combined | Not used. | 2324 | handshake | cryptographic and | | 2325 | | transport handshake | | 2326 | | stream conveying TLS | | 2327 | | handshake messages in | | 2328 | | QUIC Initial and | | 2329 | | Handshake packets. | | 2330 | | | | 2331 | TLS cipher | Client's preferred | Cipher suite optionally | 2332 | suite | cipher suite included | advertised out of band | 2333 | | in Client Hello | via Alt-Svc "cipher- | 2334 | | message. | suite" parameter. | 2335 | | | Default cipher suite is | 2336 | | | "0x00,0x00 | 2337 | | | (NULL_WITH_NULL_NULL)". | 2338 | | | | 2339 | TLS session | Session key included | Session key optionally | 2340 | key | in Server Hello | advertised out of band | 2341 | | message. | via Alt-Svc "key" | 2342 | | | parameter. | 2343 | | | | 2344 | TLS | Initialization vector | Initialization vector | 2345 | initialization | included in Server | optionally advertised | 2346 | vector | Hello message. | out of band via Alt-Svc | 2347 | | | "iv" parameter. | 2348 +----------------+-----------------------+--------------------------+ 2350 Table 1: Cryptography and Transport 2352 +----------------------------+----------------+---------------------+ 2353 | Protocol feature | Unicast QUIC | Multicast QUIC | 2354 | | | profile | 2355 +----------------------------+----------------+---------------------+ 2356 | "initial_max_data" | Connection- | Not used. Peak flow | 2357 | | level flow | rate of a session | 2358 | | control window | optionally | 2359 | | size. | advertised out of | 2360 | | | band via Alt-Svc | 2361 | | | "peak-flow-rate" | 2362 | | | parameter. | 2363 | | | | 2364 | "initial_max_stream_data_b | Locally- | Not used. No | 2365 | idi_local" | initiated | bidirectional | 2366 | | bidirectional | streams in this | 2367 | | stream flow | profile. | 2368 | | control window | | 2369 | | size. | | 2370 | | | | 2371 | "initial_max_stream_data_b | Remotely- | Not used. No | 2372 | idi_remote" | initiated | bidirectional | 2373 | | bidirectional | streams in this | 2374 | | stream flow | profile. | 2375 | | control window | | 2376 | | size. | | 2377 | | | | 2378 | "initial_max_stream_data_u | Unidirectional | Not used. Peak flow | 2379 | ni" | stream flow | rate of a session | 2380 | | control window | optionally | 2381 | | size. | advertised out of | 2382 | | | band via Alt-Svc | 2383 | | | "peak-flow-rate | 2384 | | | parameter". | 2385 | | | | 2386 | "initial_max_streams_bidi" | Maximum stream | Not used. Maximum | 2387 | and | concurrency. | concurrent | 2388 | "initial_max_streams_uni" | | resources in a | 2389 | | | session optionally | 2390 | | | advertised out of | 2391 | | | band via Alt-Svc | 2392 | | | "max-concurrent- | 2393 | | | resources" | 2394 | | | parameter. | 2395 +----------------------------+----------------+---------------------+ 2397 Table 2: Required Transport Parameters 2399 +------------------------+------------------+-----------------------+ 2400 | Protocol feature | Unicast QUIC | Multicast QUIC | 2401 | | | profile | 2402 +------------------------+------------------+-----------------------+ 2403 | "original_connection_i | The value of the | Not used. No client | 2404 | d" | Destination | interaction. | 2405 | | Connection ID | | 2406 | | field from the | | 2407 | | first Initial | | 2408 | | packet sent by | | 2409 | | the client. | | 2410 | | | | 2411 | "idle_timeout" | How long to keep | Not used. Advertised | 2412 | | an idle | out of band via Alt- | 2413 | | connection open | Svc "session-idle- | 2414 | | for before | timeout" parameter; | 2415 | | closing. Takes a | defaults to 0 (never | 2416 | | default of 0 | close on idle) if not | 2417 | | (never close on | specified. | 2418 | | idle) if not | | 2419 | | specified. | | 2420 | | | | 2421 | "stateless_reset_token | Used in | Not used. Stateless | 2422 | " | verifying a | reset is not used by | 2423 | | stateless reset. | this profile. | 2424 | | | | 2425 | "max_packet_size" | Limit of the | Not used. Maximum | 2426 | | size of packets | packet size for a | 2427 | | that an endpoint | session optionally | 2428 | | is willing to | advertised out of | 2429 | | receive. | band via Alt-Svc | 2430 | | | "max-packet-size" | 2431 | | | parameter. | 2432 | | | | 2433 | "ack_delay_exponent" | The exponent | Not used. "ACK" | 2434 | | used to decode | frames are prohibited | 2435 | | the ACK Delay | by this profile. | 2436 | | field in the | | 2437 | | "ACK" frame. | | 2438 | | | | 2439 | "max_ack_delay" | Maximum time in | Not used. "ACK" | 2440 | | milliseconds by | frames are prohibited | 2441 | | which an | by this profile. | 2442 | | endpoint will | | 2443 | | delay sending ac | | 2444 | | knowledgements. | | 2445 | | | | 2446 | "disable_migration" | Signals if an | Not used. Session | 2447 | | endpoint does | migration not | 2448 | | not support | currently supported | 2449 | | connection | by this profile. | 2450 | | migration. | | 2451 | | | | 2452 | "preferred_address" | Used to effect a | Not used. No | 2453 | | change in server | handshake in this | 2454 | | address at the | profile. | 2455 | | end of the | | 2456 | | handshake. | | 2457 +------------------------+------------------+-----------------------+ 2459 Table 3: Optional Transport Parameters 2461 +-------------+---------------------+-------------------------------+ 2462 | Protocol | Unicast QUIC | Multicast QUIC profile | 2463 | feature | | | 2464 +-------------+---------------------+-------------------------------+ 2465 | Maximum | Determined by path | Determined by path MTU | 2466 | packet size | MTU discovery or | discovery or other heuristic. | 2467 | | other heuristic. | | 2468 | | | | 2469 | Long header | Used for packets | Prohibited. | 2470 | packet | that are sent prior | | 2471 | | to the completion | | 2472 | | of version | | 2473 | | negotiation and | | 2474 | | before packet | | 2475 | | protection keys are | | 2476 | | established. | | 2477 | | | | 2478 | Version | Protocol version | Not permitted. Protocol | 2479 | negotiation | negotiation between | version advertised out of | 2480 | packet | initiating client | band via Alt-Svc "quic" | 2481 | | and server. | parameter. | 2482 | | | | 2483 | Stateless | Used by a peer to | Not permitted. (Potential | 2484 | reset | terminate a | denial-of-service attack | 2485 | packet | connection that has | vector.) | 2486 | | become unusable. | | 2487 | | | | 2488 | Short | Used for packets | Used to convey QUIC frames | 2489 | header | that are sent once | (see below). | 2490 | packet | a connection has | | 2491 | | been established. | | 2492 | | Used to convey QUIC | | 2493 | | frames (see below). | | 2494 | | | | 2495 | Source | Connection IDs | Source Connection ID not | 2496 | Connection | negotiated between | used. Destination Connection | 2497 | ID field, | client and server | ID redefined to be a | 2498 | Destination | during handshake | Multicast Session ID which is | 2499 | Connection | and may be changed | optionally advertised out of | 2500 | ID field | subsequently using | band via the Alt-Svc | 2501 | | the | "session-id" parameter. May | 2502 | | "NEW_CONNECTION_ID" | be omitted from packets if | 2503 | | frame. | the address/port tuple is | 2504 | | | sufficient to identify the | 2505 | | | session, in which case it is | 2506 | | | not advertised. | 2507 +-------------+---------------------+-------------------------------+ 2509 Table 4: QUIC Packet Layer 2511 +------------------------+----------------------+---------------------+ 2512 | Protocol feature | Unicast QUIC | Multicast QUIC | 2513 | | | profile | 2514 +------------------------+----------------------+---------------------+ 2515 | "PADDING" frame | Used to pad out a | Permitted, but | 2516 | | QUIC packet with | wasteful of network | 2517 | | zero bytes. (The | capacity. | 2518 | | first packet sent on | | 2519 | | a connection must be | | 2520 | | at least 1200 bytes | | 2521 | | long to prove that | | 2522 | | the network can | | 2523 | | transmit packets of | | 2524 | | at least this size.) | | 2525 | | | | 2526 | "PING" frame | Used by an endpoint | Used by the | 2527 | | to verify that its | multicast sender as | 2528 | | peer is still alive. | a session keep- | 2529 | | Acknowledged using a | alive notification. | 2530 | | regular "ACK" frame. | Never acknowledged. | 2531 | | | | 2532 | "ACK" frame | Used by a receiver | Both "ACK" frame | 2533 | | to acknowledge | types are | 2534 | | receipt of data from | prohibited. | 2535 | | its peer. | | 2536 | | | | 2537 | "RESET_STREAM" frame | Request by receiver | Indication to | 2538 | | for sender to | receivers that the | 2539 | | terminate a stream | multicast sender | 2540 | | transmission | has prematurely | 2541 | | prematurely. | terminated a stream | 2542 | | | transmission. | 2543 | | | Prohibited for | 2544 | | | receivers to send. | 2545 | | | | 2546 | "STOP_SENDING" frame | Flow control back | Prohibited. | 2547 | | pressure. Used to | | 2548 | | signal to a peer | | 2549 | | that incoming data | | 2550 | | on a stream is being | | 2551 | | discarded on receipt | | 2552 | | at the application's | | 2553 | | request. This | | 2554 | | abruptly terminates | | 2555 | | a stream. | | 2556 | | | | 2557 | "CRYPTO" frame | Used to transmit | Prohibited. | 2558 | | cryptographic | | 2559 | | handshake messages. | | 2560 | | | | 2561 | "NEW_TOKEN" frame | Used by a server to | Prohibited. Session | 2562 | | supply a token to | migration not | 2563 | | its client to be | currently supported | 2564 | | sent in the header | by this profile. | 2565 | | of an initial packet | | 2566 | | for a future | | 2567 | | connection. Used to | | 2568 | | facilitate | | 2569 | | connection | | 2570 | | migration. | | 2571 | | | | 2572 | "STREAM" frame | Conveys application- | Conveys | 2573 | | layer payloads (see | application-layer | 2574 | | HTTP/3 mapping | payloads (see | 2575 | | below). | HTTP/3 mapping | 2576 | | | below). | 2577 | | | | 2578 | "FIN" bit on "STREAM" | Indication by sender | Indication by the | 2579 | frame | to its peer that a | multicast sender | 2580 | | stream transmission | that a stream | 2581 | | has finished. | transmission has | 2582 | | | finished. | 2583 | | | | 2584 | "MAX_DATA" frame | Flow control update | Prohibited. | 2585 | | notification. | | 2586 | | | | 2587 | "MAX_STREAM_DATA" | Flow control update | Prohibited. | 2588 | frame | notification. | | 2589 | | | | 2590 | "MAX_STREAMS" frame | Used by an endpoint | Prohibited. | 2591 | | to inform a peer of | | 2592 | | the maximum stream | | 2593 | | ID that it is | | 2594 | | permitted to open. | | 2595 | | | | 2596 | "DATA_BLOCKED" frame | Notification to | Prohibited. | 2597 | | receiver that | | 2598 | | sender's | | 2599 | | transmission is | | 2600 | | blocked pending an | | 2601 | | update to its flow | | 2602 | | control window by | | 2603 | | peer. | | 2604 | | | | 2605 | "STREAM_DATA_BLOCKED" | Notification to | Prohibited. | 2606 | frame | receiver that | | 2607 | | sender's | | 2608 | | transmission of a | | 2609 | | single stream is | | 2610 | | blocked pending an | | 2611 | | update to its flow | | 2612 | | control window by | | 2613 | | peer. | | 2614 | | | | 2615 | "STREAMS_BLOCKED" | Notification to | Prohibited. | 2616 | frames | receiver that the | | 2617 | | sender wishes to | | 2618 | | open a stream but is | | 2619 | | unable to do so | | 2620 | | because the maximum | | 2621 | | stream ID has been | | 2622 | | reached for a given | | 2623 | | stream type. | | 2624 | | | | 2625 | "NEW_CONNECTION_ID" | Used to provide a | Prohibited. Session | 2626 | frame | peer with | migration not | 2627 | | alternative | currently supported | 2628 | | connection IDs that | by this profile. | 2629 | | can be used to break | | 2630 | | linkability when | | 2631 | | migrating | | 2632 | | connections. | | 2633 | | | | 2634 | "RETIRE_CONNECTION_ID" | Indicates that an | Prohibited. Session | 2635 | frame | endpoint will no | migration not | 2636 | | longer use a | currently supported | 2637 | | connection ID that | by this profile. | 2638 | | was issued by its | | 2639 | | peer. | | 2640 | | | | 2641 | "PATH_CHALLENGE" frame | Used to check | Prohibited. | 2642 | | reachability to a | | 2643 | | peer and for path | | 2644 | | validation during | | 2645 | | connection | | 2646 | | migration. | | 2647 | | | | 2648 | "PATH_RESPONSE" frame | Sent in response to | Prohibited. | 2649 | | a "PATH_CHALLENGE" | | 2650 | | frame. | | 2651 | | | | 2652 | "CONNECTION_CLOSE" | Notification (by | Prohibited. Use | 2653 | frame | either peer) of | HTTP explicit | 2654 | | graceful connection | session tear-down | 2655 | | shutdown. | instead (see | 2656 | | | Section 5.5). | 2657 +------------------------+----------------------+---------------------+ 2659 Table 5: QUIC Framing Layer 2661 +------------------+------------------+-----------------------------+ 2662 | Protocol feature | Unicast HTTP/3 | Multicast HTTP/3 profile | 2663 +------------------+------------------+-----------------------------+ 2664 | Stream Type | Type of | Only Server Push type is | 2665 | | unidirectional | permitted. | 2666 | | stream. | | 2667 | | | | 2668 | Push ID | Identifies a | Identifies a promised | 2669 | | promised | resource conveyed in an | 2670 | | resource | earlier "PUSH_PROMISE" | 2671 | | conveyed in an | frame. | 2672 | | earlier | | 2673 | | "PUSH_PROMISE" | | 2674 | | frame. | | 2675 | | | | 2676 | "DATA" frame | Carriage of HTTP | Carriage of HTTP response | 2677 | | request/response | message body. | 2678 | | message body. | | 2679 | | | | 2680 | "HEADERS" frame | Carriage of HTTP | Carriage of HTTP response | 2681 | | request/response | message metadata. Trailing | 2682 | | message | "HEADERS" frame is | 2683 | | metadata. | permitted. | 2684 | | Trailing | | 2685 | | "HEADERS" frame | | 2686 | | is permitted. | | 2687 | | | | 2688 | "PRIORITY" frame | Dynamic | Prohibited. | 2689 | | adjustment of | | 2690 | | stream priority. | | 2691 | | | | 2692 | "CANCEL_PUSH" | Used to request | Permitted only for senders. | 2693 | frame | cancellation of | | 2694 | | server push | | 2695 | | prior to the | | 2696 | | push stream | | 2697 | | being created. | | 2698 | | | | 2699 | "SETTINGS" frame | Negotiation of | Prohibited. | 2700 | | HTTP/3 | | 2701 | | connection | | 2702 | | settings. | | 2703 | | | | 2704 | "PUSH_PROMISE" | Carriage of HTTP | Carriage of HTTP pseudo- | 2705 | frame | pseudo-request | request message metadata. | 2706 | | message | All HTTP representation | 2707 | | metadata. | transfers over multicast | 2708 | | | begin this way. Stream ID | 2709 | | | of the first client- | 2710 | | | initiated bidirectional | 2711 | | | stream is reserved and all | 2712 | | | "PUSH_PROMISE" frames | 2713 | | | reference this as the | 2714 | | | client request from which | 2715 | | | they are notionally | 2716 | | | derived. This stream | 2717 | | | remains open while a sender | 2718 | | | is participating in the | 2719 | | | multicast QUIC session. | 2720 | | | | 2721 | "GOAWAY" frame | Early | Prohibited. Use HTTP | 2722 | | notification (by | explicit session tear-down | 2723 | | either endpoint) | instead. | 2724 | | of future | | 2725 | | connection | | 2726 | | closure, | | 2727 | | allowing for | | 2728 | | orderly | | 2729 | | completion of | | 2730 | | open streams. | | 2731 | | | | 2732 | "MAX_PUSH_ID" | Used by a | Prohibited. | 2733 | frame | receiver to | | 2734 | | control the | | 2735 | | number of server | | 2736 | | pushes that a | | 2737 | | sender can | | 2738 | | initiate. | | 2739 | | | | 2740 | "DUPLICATE_PUSH" | Used by servers | Prohibited. | 2741 | frame | to indicate that | | 2742 | | an existing | | 2743 | | pushed resource | | 2744 | | is related to | | 2745 | | multiple client | | 2746 | | requests. | | 2747 | | | | 2748 | "ALTSVC" HTTP/2 | Signalling | Prohibited. | 2749 | extension frame | alternative | | 2750 | | service for | | 2751 | | HTTP/3 session. | | 2752 | | | | 2753 | Other HTTP/2 | | Prohibited. | 2754 | extension frames | | | 2755 +------------------+------------------+-----------------------------+ 2757 Table 6: HTTP/3 Mapping 2759 +-------------+----------------------------------+------------------+ 2760 | Protocol | Unicast HTTP/3 | Multicast HTTP/3 | 2761 | feature | | profile | 2762 +-------------+----------------------------------+------------------+ 2763 | Huffman | Header blocks may use Huffman | Header blocks | 2764 | string | codes to compress literal string | may use Huffman | 2765 | compression | values. | codes to | 2766 | | | compress literal | 2767 | | | string values. | 2768 | | | | 2769 | Static | Header blocks may refer to | Header blocks | 2770 | table | indexed entries in the static | may refer to | 2771 | | table. | indexed entries | 2772 | | | in the static | 2773 | | | table. | 2774 | | | | 2775 | Dynamic | Header blocks may insert entries | Prohibited, size | 2776 | table | into the dynamic table and | is currently | 2777 | | subsequent header blocks may | locked to 0. | 2778 | | refer to their indexes. Unused | | 2779 | | as size is currently locked to | | 2780 | | 0. | | 2781 +-------------+----------------------------------+------------------+ 2783 Table 7: HTTP Metadata Compression Layer 2785 Appendix D. Changelog 2787 *RFC Editor's Note:* Please remove this section prior to 2788 publication of a final version of this document. 2790 D.1. Since draft-pardue-quic-http-mcast-03 2792 o Update references to QUIC I-Ds. 2794 o Change crypto handshake text now that it's no longer done on 2795 Stream ID 0. 2797 o Update to reference Source and Destination Connection IDs. 2799 o Prohibit the use of connection coalescing, migration and ECN. 2801 o Update allowed and disallowed packets and frames to match the core 2802 specs 2804 o Remove references to the PONG frame (draft-ietf-quic-transport-10) 2806 o Change HTTP/QUIC to HTTP/3 (draft-ietf-quic-http-17) 2808 o Change HPACK to QPACK (draft-ietf-quic-http-10) 2810 o Prohibit the DUPLICATE_PUSH frame 2812 o Clarify packet number space (only use application data space, not 2813 initial or handshake) 2815 o Add statement on QUIC latency spin bit 2817 o Removed sentence stating that multiple Connection IDs cannot be 2818 used concurrently in a unicast QUIC session, in accordance with 2819 [QUIC-TRANSPORT] section 5.1.2. 2821 D.2. Since draft-pardue-quic-http-mcast-02 2823 o No changes. 2825 D.3. Since draft-pardue-quic-http-mcast-01 2827 o Explicit guidance on maximum stream ID value permitted. 2829 o Updated guidance on PING (and PONG) frame. 2831 o Added a comparison table to appendix. 2833 o Remove invalid use of trailing headers. 2835 o Use the new HTTP/QUIC DATA frame. 2837 o Prohibit APPLICATION CLOSE frame, and move GOAWAY frame to HTTP/ 2838 QUIC section. 2840 o Redefine server push to reflect core document changes. 2842 o Remove default idle time out value. 2844 o Clarify session parameter requirements (session-idle-timeout 2845 became mandatory). 2847 o Update frame notation convention. 2849 D.4. Since draft-pardue-quic-http-mcast-00 2851 o Update references to QUIC I-Ds. 2853 o Relax session leaving requirements language. 2855 o Clarify handling of omitted session parameter advertisements. 2857 o Rename "Idle" state to "Quiescent". 2859 o Add digest algorithm session parameter. 2861 o Add signature algorithm session parameter. 2863 o Add Initialization Vector session parameter. 2865 o Replace COPT tag-value-pairs with TransportParameter values. 2867 o Add example of an advertisement for a session with content 2868 authenticity and integrity. 2870 Authors' Addresses 2872 Lucas Pardue 2874 Email: lucaspardue.24.7@gmail.com 2876 Richard Bradbury 2877 BBC Research & Development 2879 Email: richard.bradbury@bbc.co.uk 2880 Sam Hurst 2881 BBC Research & Development 2883 Email: sam.hurst@bbc.co.uk