idnits 2.17.1 draft-pardue-quic-http-mcast-00.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- ** The document seems to lack a Security Considerations section. == There are 1 instance of lines with multicast IPv4 addresses in the document. If these are generic example addresses, they should be changed to use the 233.252.0.x range defined in RFC 5771 Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year -- The document date (February 10, 2017) is 2632 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-06 ** 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) ** Obsolete normative reference: RFC 7540 (Obsoleted by RFC 9113) -- 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 (~~), 3 warnings (==), 3 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Network Working Group L. Pardue 3 Internet-Draft R. Bradbury 4 Intended status: Informational BBC Research & Development 5 Expires: August 14, 2017 February 10, 2017 7 Hypertext Transfer Protocol (HTTP) over multicast QUIC 8 draft-pardue-quic-http-mcast-00 10 Abstract 12 This document specifies a profile of the QUIC protocol and the HTTP/ 13 QUIC mapping that facilitates the transfer of HTTP resources over 14 multicast IP using the QUIC transport as its framing and 15 packetisation layer. Compatibility with the QUIC protocol's syntax 16 and semantics is maintained as far as practical and additional 17 features are specified where this is not possible. 19 Status of This Memo 21 This Internet-Draft is submitted in full conformance with the 22 provisions of BCP 78 and BCP 79. 24 Internet-Drafts are working documents of the Internet Engineering 25 Task Force (IETF). Note that other groups may also distribute 26 working documents as Internet-Drafts. The list of current Internet- 27 Drafts is at http://datatracker.ietf.org/drafts/current/. 29 Internet-Drafts are draft documents valid for a maximum of six months 30 and may be updated, replaced, or obsoleted by other documents at any 31 time. It is inappropriate to use Internet-Drafts as reference 32 material or to cite them other than as "work in progress." 34 This Internet-Draft will expire on August 14, 2017. 36 Copyright Notice 38 Copyright (c) 2017 IETF Trust and the persons identified as the 39 document authors. All rights reserved. 41 This document is subject to BCP 78 and the IETF Trust's Legal 42 Provisions Relating to IETF Documents 43 (http://trustee.ietf.org/license-info) in effect on the date of 44 publication of this document. Please review these documents 45 carefully, as they describe your rights and restrictions with respect 46 to this document. Code Components extracted from this document must 47 include Simplified BSD License text as described in Section 4.e of 48 the Trust Legal Provisions and are provided without warranty as 49 described in the Simplified BSD License. 51 Table of Contents 53 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 4 54 1.1. Notational Conventions . . . . . . . . . . . . . . . . . 5 55 1.2. Definitions . . . . . . . . . . . . . . . . . . . . . . . 6 56 2. Multicast QUIC Sessions . . . . . . . . . . . . . . . . . . . 6 57 2.1. Session States . . . . . . . . . . . . . . . . . . . . . 7 58 2.1.1. Session Establishment . . . . . . . . . . . . . . . . 8 59 2.1.2. Session Termination . . . . . . . . . . . . . . . . . 8 60 2.1.3. Session Migration . . . . . . . . . . . . . . . . . . 9 61 2.2. Session Parameters . . . . . . . . . . . . . . . . . . . 9 62 2.3. Session Identification . . . . . . . . . . . . . . . . . 9 63 2.4. Session Security . . . . . . . . . . . . . . . . . . . . 10 64 3. Session Advertisement . . . . . . . . . . . . . . . . . . . . 10 65 3.1. Version Advertisement . . . . . . . . . . . . . . . . . . 11 66 3.2. Security Context . . . . . . . . . . . . . . . . . . . . 12 67 3.3. Session Identification . . . . . . . . . . . . . . . . . 12 68 3.4. Session Idle Timeout . . . . . . . . . . . . . . . . . . 12 69 3.5. Session Peak Flow Rate . . . . . . . . . . . . . . . . . 13 70 3.6. Resource Concurrency . . . . . . . . . . . . . . . . . . 13 71 3.7. Connection Options . . . . . . . . . . . . . . . . . . . 14 72 4. QUIC Profile . . . . . . . . . . . . . . . . . . . . . . . . 14 73 4.1. Packet Size . . . . . . . . . . . . . . . . . . . . . . . 14 74 4.2. Version Negotiation . . . . . . . . . . . . . . . . . . . 14 75 4.3. Connection Identifier . . . . . . . . . . . . . . . . . . 14 76 4.4. Stream Identifier . . . . . . . . . . . . . . . . . . . . 14 77 4.5. Flow Control . . . . . . . . . . . . . . . . . . . . . . 15 78 4.6. Stream Termination . . . . . . . . . . . . . . . . . . . 15 79 4.7. Session Shutdown . . . . . . . . . . . . . . . . . . . . 15 80 4.8. Session Keep-alive . . . . . . . . . . . . . . . . . . . 15 81 4.9. Loss Detection and Recovery . . . . . . . . . . . . . . . 16 82 4.10. Prohibited QUIC Frames and Packets . . . . . . . . . . . 16 83 5. HTTP/QUIC Profile . . . . . . . . . . . . . . . . . . . . . . 16 84 5.1. HTTP Connection Settings . . . . . . . . . . . . . . . . 17 85 5.2. Server Push . . . . . . . . . . . . . . . . . . . . . . . 17 86 5.3. Metadata Compression . . . . . . . . . . . . . . . . . . 17 87 5.4. Prioritisation . . . . . . . . . . . . . . . . . . . . . 18 88 5.5. Session Tear-down . . . . . . . . . . . . . . . . . . . . 18 89 5.6. HTTP/2 Extension frames . . . . . . . . . . . . . . . . . 18 90 5.7. Prohibited HTTP/2 Frames . . . . . . . . . . . . . . . . 18 91 6. Application-Layer Security . . . . . . . . . . . . . . . . . 18 92 6.1. Content Integrity . . . . . . . . . . . . . . . . . . . . 18 93 6.2. Content Authenticity . . . . . . . . . . . . . . . . . . 19 94 6.3. Content Confidentiality . . . . . . . . . . . . . . . . . 21 95 7. Loss Recovery . . . . . . . . . . . . . . . . . . . . . . . . 21 96 7.1. Forward Error Correction . . . . . . . . . . . . . . . . 21 97 7.2. Unicast Repair . . . . . . . . . . . . . . . . . . . . . 21 98 8. Transmission of Partial Content . . . . . . . . . . . . . . . 22 99 9. Protocol Identifier . . . . . . . . . . . . . . . . . . . . . 22 100 9.1. Draft Version Identification . . . . . . . . . . . . . . 22 101 10. Discovery of Multicast QUIC Sessions . . . . . . . . . . . . 23 102 10.1. Source-specific Multicast Advertisement . . . . . . . . 24 103 10.2. Session Parameter Advertisement . . . . . . . . . . . . 24 104 10.2.1. Version . . . . . . . . . . . . . . . . . . . . . . 24 105 10.2.2. Cipher Suite . . . . . . . . . . . . . . . . . . . . 24 106 10.2.3. Session Key . . . . . . . . . . . . . . . . . . . . 25 107 10.2.4. Session Identification . . . . . . . . . . . . . . . 25 108 10.2.5. Session Idle Timeout Period . . . . . . . . . . . . 25 109 10.2.6. Stream Concurrency . . . . . . . . . . . . . . . . . 26 110 10.2.7. Session Peak Flow Rate . . . . . . . . . . . . . . . 26 111 11. Security and Privacy Considerations . . . . . . . . . . . . . 26 112 11.1. Pervasive Monitoring . . . . . . . . . . . . . . . . . . 27 113 11.1.1. Large-scale Data Gathering and Correlation . . . . . 27 114 11.1.2. Changing Content . . . . . . . . . . . . . . . . . . 27 115 11.2. Protection of Discovery Mechanism . . . . . . . . . . . 28 116 11.3. Spoofing . . . . . . . . . . . . . . . . . . . . . . . . 28 117 11.3.1. Spoofed Ack Attacks . . . . . . . . . . . . . . . . 28 118 11.3.2. Sender Spoofing . . . . . . . . . . . . . . . . . . 28 119 11.3.3. Receiver Spoofing . . . . . . . . . . . . . . . . . 29 120 11.4. Replay Attacks . . . . . . . . . . . . . . . . . . . . . 29 121 11.5. Message Deletion . . . . . . . . . . . . . . . . . . . . 29 122 11.6. Denial of Service . . . . . . . . . . . . . . . . . . . 29 123 11.6.1. Unprotected Frames and Packets . . . . . . . . . . . 29 124 11.6.2. Network Performance Degradation . . . . . . . . . . 30 125 11.6.3. Unicast Repair Stampeding Herd . . . . . . . . . . . 30 126 11.7. Receiver Resource Usage . . . . . . . . . . . . . . . . 30 127 11.8. Unicast Repair Information Leakage . . . . . . . . . . . 30 128 12. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 31 129 12.1. Registration of Protocol Identification String . . . . . 31 130 12.2. Registration of Alt-Svc parameters . . . . . . . . . . . 31 131 12.2.1. Source Address . . . . . . . . . . . . . . . . . . . 31 132 12.2.2. Cipher Suite . . . . . . . . . . . . . . . . . . . . 32 133 12.2.3. Key . . . . . . . . . . . . . . . . . . . . . . . . 32 134 12.2.4. Session Identifier . . . . . . . . . . . . . . . . . 32 135 12.2.5. Session Idle Timeout . . . . . . . . . . . . . . . . 32 136 12.2.6. Maximum Concurrent Resources . . . . . . . . . . . . 32 137 12.2.7. Peak Flow Rate . . . . . . . . . . . . . . . . . . . 32 138 13. References . . . . . . . . . . . . . . . . . . . . . . . . . 32 139 13.1. Normative References . . . . . . . . . . . . . . . . . . 32 140 13.2. Informative References . . . . . . . . . . . . . . . . . 34 141 Appendix A. Acknowledgements . . . . . . . . . . . . . . . . . . 36 142 Appendix B. Examples . . . . . . . . . . . . . . . . . . . . . . 36 143 B.1. Session Advertisement . . . . . . . . . . . . . . . . . . 36 144 B.1.1. Source-specific Multicast QUIC Session . . . . . . . 36 145 B.1.2. Source-specific Multicast QUIC Session with Transport 146 Encryption using a Symmetric Key . . . . . . . . . . 36 147 B.2. Resource Transfer . . . . . . . . . . . . . . . . . . . . 37 148 B.2.1. Transfer without Content Integrity or Authenticity . 37 149 B.2.2. Transfer of Partial Content without Content Integrity 150 or Authenticity . . . . . . . . . . . . . . . . . . . 37 151 B.2.3. Transfer with Content Integrity and without 152 Authenticity . . . . . . . . . . . . . . . . . . . . 38 153 B.2.4. Partial Transfer with Content Integrity and without 154 Authenticity . . . . . . . . . . . . . . . . . . . . 39 155 B.2.5. Transfer with Content Integrity and Authenticity . . 39 156 B.2.6. Partial Transfer with Content Integrity and 157 Authenticity . . . . . . . . . . . . . . . . . . . . 40 158 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 41 160 1. Introduction 162 The means to bulk transfer resources over multicast IP [RFC1112] 163 using HTTP semantics presents an opportunity to more efficiently 164 deliver services at scale, while leveraging the wealth of existing 165 HTTP-related standards, tools and applications. Audio-visual 166 segmented media, in particular, would benefit from this mode of 167 transmission. 169 The carriage of HTTP over multicast IP may be satisfied using 170 existing technologies, for example the Real-time Transport Protocol 171 (RTP) [RFC3550]. However, such protocols typically require the 172 translation or encapsulation of HTTP. This introduces concerns for 173 providers of services, such as defining the translation, additional 174 workload, complication of workflows, manageability issues, versioning 175 issues, and so on. 177 In contrast, this document describes a simpler and more direct 178 expression of HTTP semantics over multicast IP. HTTP over multicast 179 QUIC is a profile of the QUIC protocol [QUIC-TRANSPORT] (Section 4) 180 and the HTTP/QUIC mapping [QUIC-HTTP] (Section 5). This includes the 181 repurposing of certain QUIC packet fields and changes to some 182 protocol procedures (e.g. prohibition of the usage of certain frame 183 types) which, in turn, change the behavioural expectations of 184 endpoints. However, the profile purposely limits the scope of change 185 in order to preserve maximum compatibility with conventional QUIC. 187 This profile prohibits the transmission of QUIC packets from receiver 188 to sender via multicast IP. The use of side-channel or out-of-band 189 feedback mechanisms is not prohibited by this specification, but is 190 out of scope and these are not considered further by the present 191 document. 193 Experience indicates that a generally available multicast deployment 194 is difficult to achieve on the Internet notwithstanding the 195 improvements that IPv6 [RFC2460] makes in this area. There is 196 evidence that discretely referenced multicast "islands" can more 197 pragmatically be deployed. Discovery of such islands by receivers, 198 as they become available, is typically difficult, however. To 199 address the problem, this document describes an HTTP-based discovery 200 mechanism that uses HTTP Alternative Services [RFC7838] to advertise 201 the existence of multicast QUIC sessions (Section 3). This provides 202 the means for multicast-capable endpoints to learn about and make use 203 of them in an opportunistic and user-imperceptible manner. This 204 mechanism results in a common HTTP application layer for both the 205 discovery and delivery of services across unicast and multicast 206 networks. This provides support for users and devices accessing 207 services over a heterogeneous network. This is a departure from 208 conventional multicast discovery technologies such as SDP [RFC4566] 209 and SAP [RFC2974]. 211 The discovery mechanism also addresses some of the issues related to 212 using QUIC over a unidirectional network association by replacing 213 connection establishment aspects that depend on a bidirectional 214 transport. 216 The present document includes a number of optional features. It is 217 anticipated that further specifications will define interoperability 218 profiles suited to particular application domains. 220 1.1. Notational Conventions 222 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 223 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 224 document are to be interpreted as described in [RFC2119]. 226 This document uses the Augmented BNF defined in [RFC5234] and updated 227 by [RFC7405] along with the "#rule" extension defined in Section 7 of 228 [RFC7230]. The rules below are defined in [RFC5234], [RFC7230], and 229 [RFC7234]: 231 o quoted-string = 233 o token = 235 o uri-host = 237 1.2. Definitions 239 Definitions of terms that are used in this document: 241 o endpoint: A host capable of being a participant in a multicast 242 QUIC session. 244 o multicast QUIC session: A logical unidirectional flow of metadata 245 and data over multicast IP, framed according to this 246 specification. The lifetime of a session is independent of any 247 endpoint. 249 o participant: A sender or receiver that is taking part in a 250 multicast QUIC session. 252 o sender: A participant sending multicast traffic according to this 253 specification. 255 o receiver: A participant receiving multicast traffic according to 256 this specification. 258 o session: See multicast QUIC session. 260 o session ID: The identifier for a multicast QUIC session. 262 o session parameter: Characteristic of a multicast QUIC session. 264 2. Multicast QUIC Sessions 266 An HTTP/QUIC connection [QUIC-TRANSPORT] carried over bidirectional 267 unicast is defined as a conversation between two QUIC endpoints that 268 multiplexes several logical streams within a single encryption 269 context. This is a one-to-one relationship. Furthermore, QUIC 270 connections achieve decoupling from the underlying network (IP and 271 port) by means of a Connection ID. Use of a consistent connection 272 identifier allows QUIC connections to survive changes to the network 273 connectivity. The establishment of a QUIC connection relies upon an 274 up-front, in-band exchange (and possible negotiation) of 275 cryptographic and transport parameters (conveyed in QUIC handshake 276 messages) and HTTP-specific settings (conveyed in HTTP/2 "SETTINGS" 277 frames). Such parameters may be required or optional and may be used 278 by either endpoint to control the characteristics of connection 279 usage. 281 This concept of a connection does not suit the carriage of HTTP/QUIC 282 over unidirectional network associations such as multicast IP. In 283 fact, there is no requirement for either endpoint (multicast sender 284 or receiver) to be in existence in order for the other to start or 285 join this one-sided conversation. The term "connection" is 286 misleading in this context; therefore we introduce an alternative 287 term "multicast QUIC session" or simply "session", which is defined 288 as the logical entity describing the characteristics of the 289 anticipated unidirectional flow of metadata and data. Such 290 characteristics are expressed as "session parameters", described in 291 Section 2.2. Advertisement of multicast QUIC sessions, specified in 292 Section 3, allows for the senders and receivers to discover a session 293 and to form multicast IP network associations that permit traffic 294 flow. 296 2.1. Session States 298 The lifecycle of a multicast QUIC session is decoupled from the 299 lifecycle of any particular endpoint. Multicast receivers or senders 300 that take part in a session are called participants. The state of a 301 session is influenced by the actions of participants. The loose 302 coupling of participants means that they are unlikely to have a 303 consistent shared view of the current state of a session. There is 304 no requirement for a participant to know the session state and the 305 present document does not define a method to explicitly determine it. 306 The definitions of session states provided below are intended to 307 assist higher-level operational treatment of sessions: 309 o Idle: the session has no participants and is ready to accept them. 311 o Half-established: the session has a participant. 313 o Fully-established: the session has a sender and at least one 314 receiver participant. 316 o Finished: the session has ended, and there are no participants. 318 Permitted states transitions are shown in Figure 1 below. 320 The transmission of QUIC packets is expected to occur only during the 321 Half-Established and Fully-Established states. 323 +------+ +------------------+ +-------------------+ 324 | |-------->| |------->| | 325 | Idle | | Half-Established | | Fully-Established | 326 | |<--------| |<-------| | 327 +------+ +------------------+ +-------------------+ 328 | | 329 | v 330 | +----------+ 331 | | | 332 +---------------->| Finished | 333 | | 334 +----------+ 336 Figure 1: Multicast QUIC session states 338 2.1.1. Session Establishment 340 A session begins in the Idle state. A typical session establishment 341 sequence would see the transition from Idle to Half-Established when 342 a sender joins the session. The transition from Half-Established to 343 Fully-Established occurs when at least one receiver joins the 344 session. 346 It is equally valid for a receiver to join a session in the Idle 347 state, triggering the transition to Half-Established. In this case, 348 the transition to Fully-Established takes place only when a sender 349 joins the session. 351 2.1.2. Session Termination 353 A session enters the Finished state when all participants leave it. 354 The methods for leaving a session are either explicit shutdown 355 (Section 5.5), implicit shutdown (i.e. idle timeout, Section 3.4) or 356 migration away (described in the next section). 358 In a typical case, a session that is in the Fully-Established state 359 would be closed in two stages. In the first stage the sender sends 360 explicit shutdown messages to the multicast group and subsequently 361 stops transmitting packets. This causes the session to transition 362 from Fully-Established to Half-Established. In the second stage, 363 receivers that have received explicit shutdown messages leave the 364 multicast group. Once all receivers have left the session it 365 transitions from Half-Established to Finished. 367 The transition from Idle to Finished could also occur in response to 368 out-of-band actions, for example the availability of a session being 369 withdrawn without any participants having made use of it. 371 2.1.3. Session Migration 373 Endpoints MAY migrate between multicast QUIC sessions (for example, 374 to make use of alternate session parameters that are preferred). 375 Session migration requires participants to leave the current session 376 and join the new session. These actions affect the state of the 377 respective sessions as explained above. 379 The discovery of multicast QUIC sessions is described in Section 3. 381 2.2. Session Parameters 383 The characteristics of multicast QUIC sessions are expressed as 384 session parameters, which cover cryptographic and transport 385 parameters, HTTP-specific settings and multicast-specific 386 configuration. 388 Session parameter exchange over IP multicast is difficult: 390 o In-band exchanges are one-way, and so the client does not have the 391 means to send session parameters. 393 o The lifecycle of any multicast sender is independent of the 394 multicast receiver. It is therefore unlikely that all receivers 395 will have joined a session in time to receive parameters sent at 396 the start of a multicast session. 398 A range of strategies exists to mitigate these points. However, each 399 has the possibility to add complexity to deployment and 400 manageability, transmission overhead, or other such concerns. This 401 document defines a solution that relies on the one-way announcement 402 of session parameters in advance of session establishment. This is 403 achieved using HTTP Alternative Services [RFC7838] and is explained 404 in Section 3. Other advertisement solutions are not prohibited but 405 are not explored in this document. 407 Session parameters MUST NOT change during the lifetime of a session. 408 This restriction also applies to HTTP-level settings (see 409 Section 5.1). 411 2.3. Session Identification 413 This document defines a 64-bit session identifier used to identify a 414 session. This "Session ID" affords independence from multicast IP, 415 creating the possibility for a session to span multiple multicast 416 groups, or to migrate a session to a different multicast group. 417 Assignment of Session ID is considered out of this document's scope. 419 The Session ID is carried in the Connection ID field of the QUIC 420 packet (see Section 4.3). 422 A multicast sender participating in a session MUST send QUIC packets 423 with a matching Session ID. A multicast receiver participating in a 424 session MUST validate that the Session ID of received QUIC packets 425 matches that advertised in the session parameters (Section 3, 426 Section 10.2) before any HTTP-level processing is done. In the case 427 of validation failure, the receiver SHOULD leave the session in order 428 to protect itself from denial-of-service attacks. 430 2.4. Session Security 432 *Authors' Note:* Security handshake (as described in WG documents) 433 is in flux. This section will track developments and will be 434 updated accordingly. 436 The QUIC Crypto and Transport handshake (see [QUIC-TRANSPORT], 437 [QUIC-TLS] and [QUICCrypto]) sets out methods to achieve the goals of 438 authenticated key exchange and record protection between two 439 endpoints forming a QUIC connection. The design facilitates low- 440 latency connection; 1-RTT or 0-RTT. The Crypto handshake [QUIC-TLS] 441 reserves QUIC stream 1 for TLS handshake messages. 443 This specification replaces the in-band security handshake, achieving 444 similar goals through the use of session parameters described in 445 Section 3.2. For the purpose of compatibility, the use of QUIC 446 stream 1 (see Section 4.4) is reserved. 448 Integrity and authenticity concerns are addressed in Section 6.1 and 449 Section 6.2 respectively. In order to protect themselves from attack 450 vectors, endpoints SHOULD NOT participate in sessions for which they 451 cannot establish reasonable confidence over the cipher suite or key 452 in use for that session. Participants SHOULD leave any session that 453 fails to successfully match anticipated security characteristics. 455 3. Session Advertisement 457 In this specification, connection negotiation is replaced with a 458 session advertisement mechanism based on HTTP Alternative Services 459 (Alt-Svc) [RFC7838]. This document specifies how the parameters of a 460 multicast QUIC session are expressed as Alt-Svc parameters. The 461 following sections provide a high-level view of these; further 462 details are provided in Section 10.2, with examples provided in 463 Appendix B.1. QUIC connection parameters not defined as, or related 464 to, Alt-Svc parameters are not used. 466 The definition of a session (including the session ID and its 467 parameters) is not the responsibility of any endpoint. Rather, 468 endpoints SHOULD use session advertisements to determine if they are 469 capable of participating in a given session. This document does not 470 specify which party is responsible for defining and/or advertising 471 multicast QUIC sessions. 473 The freshness of Alt-Svc multicast QUIC session advertisements is as 474 described in section 2.2 of [RFC7838]. 476 It is RECOMMENDED that session advertisements are carried over a 477 secure transport (such as HTTPS) which can guarantee the authenticity 478 and integrity of the Alt-Svc information. This addresses some of the 479 concerns around the protection of session establishment described in 480 Section 11.2. 482 *Authors' Note:* We invite review comments on mandating the use of 483 a secure transport for advertising sessions. 485 Senders MAY also advertise the availability of alternative sessions 486 by carrying Alt-Svc in a multicast QUIC session. 488 3.1. Version Advertisement 490 *Authors' Note:* Version negotiation (as described in WG 491 documents) is in flux. This section will track developments and 492 will be updated accordingly. 494 Conventional QUIC connection establishment begins with version 495 negotiation. In a unidirectional multicast environment, there is no 496 reasonable way to negotiate in such a manner. [QUIC-HTTP] defines an 497 Alt-Svc "quic" parameter that can be advertised to clients for use as 498 a version negotiation hint. This specification uses "quic" as a 499 session parameter for a similar purpose but with the additional 500 constraint that the parameter MUST appear exactly once: it is not 501 optional and the parameter MUST NOT be repeated. 503 This mechanism replaces the use of the Version field in the QUIC 504 packet (see Section 4.2). 506 A multicast sender participating in a session MUST send HTTP messages 507 in the format corresponding to the advertised version. If the sender 508 does not support the advertised version it MUST NOT send any data. A 509 receiver MUST NOT join a session where the "quic" parameter is 510 absent. A receiver SHOULD NOT join a session for which it does not 511 support the advertised version, in order to avoid wasting processing 512 resources. 514 3.2. Security Context 516 *Authors' Note:* Security handshake (as described in WG documents) 517 is in flux. This section will track developments and will be 518 updated accordingly. 520 This specification replaces the in-band security handshake: 522 o Cipher suite negotiation is replaced with a "cipher suite" session 523 parameter, which is advertised as the Alt-Svc parameter "cipher- 524 suite" (Section 10.2.2). If present, this parameter MUST contain 525 only one value that corresponds to an entry in the TLS Cipher 526 Suite Registry (see http://www.iana.org/assignments/tls- 527 parameters/tls-parameters.xhtml#tls-parameters-4). If absent, the 528 multicast QUIC session is assumed to be operating with cipher 529 suite 0x00,0x00 (NULL_WITH_NULL_NULL). 531 o Key exchange is replaced with a "key" session parameter, which is 532 advertised as the Alt-Svc parameter "key" (Section 10.2.3). The 533 parameter carries a variable-length hex-encoded key for use with 534 the session cipher suite. In the absence of the "key" parameter, 535 the key may be available via an out-of-band method not described 536 in this document. 538 In order to protect themselves, endpoints SHOULD NOT participate in 539 sessions for which they cannot establish reasonable confidence over 540 the cipher suite or key in use for that session. Endpoints SHOULD 541 leave any sessions which fail to successfully match anticipated 542 security characteristics. 544 3.3. Session Identification 546 [QUIC-TRANSPORT] specifies how the QUIC Connection ID is used, in 547 particular the client-side generation of this value. In a 548 unidirectional multicast environment, there is no meaningful way for 549 a client to generate a Connection ID and use it. This document 550 defines a "session identifier" session parameter, which is advertised 551 as the Alt-Svc parameter "session-id" (Section 10.2.4). The 552 requirements for the usage of session identifiers have already been 553 described in Section 2.3. 555 3.4. Session Idle Timeout 557 Conventional QUIC connections may be implicitly terminated following 558 a period of idleness (lack of network activity). The QUIC "ICSL" 559 required negotiation parameter provides a means for endpoints to 560 define a timeout period, the default period being 30 seconds. This 561 document defines a "session idle timeout" session parameter, which is 562 advertised as the Alt-Svc parameter "session-idle-timeout" 563 (Section 10.2.5). This session parameter mimics the behaviour of 564 "ICSL", providing a means for multicast QUIC sessions to define their 565 own idle timeout periods. 567 Receiving participants SHOULD leave multicast QUIC sessions when the 568 session idle timeout period has elapsed (Section 4.7). Leaving 569 participants MUST use the silent close method, in which no 570 "CONNECTION_CLOSE" QUIC frame is sent. 572 3.5. Session Peak Flow Rate 574 [QUIC-TRANSPORT] specifies a credit-based stream- and connection- 575 level flow control scheme which prevents a fast sender from 576 overwhelming a slow receiver. Window size connection parameters are 577 exchanged on connection establishment using the required QUIC 578 parameters "SFCW" and "CFCW". In a unidirectional multicast 579 environment, such a scheme is infeasible. This document defines a 580 "peak flow rate" session parameter, expressed in units of bits per 581 second, which is advertised as the Alt-Svc parameter "peak-flow-rate" 582 (Section 10.2.7). This replaces "CFCW" and indicates the maximum bit 583 rate of "STREAM" QUIC frame payloads transmitted on all multicast 584 groups comprising the session. 586 A multicast sender SHOULD NOT cause the advertised peak flow rate of 587 a session to be exceeded. A receiver MAY leave any session where the 588 advertised peak flow rate is exceeded. 590 3.6. Resource Concurrency 592 The QUIC handshake required parameter "MSPC" defines the maximum 593 number of concurrent streams a conventional QUIC endpoint can 594 initiate per connection. In a unidirectional multicast environment, 595 there is no way for a receiver to specify the limit. This document 596 specifies a new "maximum concurrent resources" session parameter, 597 which is advertised as the Alt-Svc parameter "max-concurrent- 598 resources" (Section 10.2.6). This parameter replaces "MSPC". It 599 advertises the maximum number of concurrent active resources 600 generated by a sender in a given multicast QUIC session. 602 A multicast sender participating in a session MUST NOT cause the 603 advertised "max-concurrent-resources" to be exceeded. A receiver 604 SHOULD leave any session where the advertised limit is exceeded, in 605 order to protect itself from denial-of-service attacks. 607 3.7. Connection Options 609 *Authors' Note:* Conventional QUIC Connection Options (COPTs) are 610 to be defined in WG documents. This section will track 611 developments and will be updated accordingly. 613 4. QUIC Profile 615 *Authors' Note:* The QUIC transport document is subject to change. 616 This section is based on draft-ietf-quic-transport-01. The 617 authors will track developments and will update this section 618 accordingly. 620 The profile of [QUIC-TRANSPORT] is presented in this section. In 621 order to preserve compatibility with conventional QUIC, the 622 specification works with a limited scope of change. However, the 623 nature of unidirectional multicast communications means that some 624 protocol procedures or behaviours need to be modified. 626 4.1. Packet Size 628 The means for determining an appropriate size for QUIC packets are 629 described in Section 8 of [QUIC-TRANSPORT]. Implementations of this 630 specification SHOULD bear in mind that the Path Maximum Transmission 631 Unit (PTMU) may be affected by multicast IP technologies such as 632 Automatic Multicast Tunneling (AMT) [RFC7450]. Additionally, 633 considerations should be given towards the applicability of maximum 634 transmission unit discovery methods (such as PLPMTUD [RFC4821] and 635 PMTUD [RFC1191]) to multicast IP. 637 4.2. Version Negotiation 639 Endpoints implementing this specification MUST NOT send QUIC packets 640 containing a Version field and MUST NOT set the "VERSION" flag in the 641 QUIC packet header. 643 4.3. Connection Identifier 645 The Connection ID field MUST be present in every QUIC packet, and the 646 corresponding flag in the packet header MUST be set to indicate that 647 the Connection ID field is present. 649 4.4. Stream Identifier 651 Senders MUST NOT send any QUIC frames on QUIC stream 1. Receivers 652 MUST ignore QUIC frames sent on stream 1. 654 4.5. Flow Control 656 Conventional QUIC provides stream- and connection-level flow control 657 and endpoints manage this by sending the "WINDOW_UPDATE" QUIC frame. 658 When a sender is blocked from sending flow-controlled frames, it 659 sends an informational "BLOCKED" QUIC frame. 661 In a unidirectional environment, the sender never has a receive 662 window and the receiver cannot send in-band updates. Therefore, the 663 management of flow-control windows and transmission of blockage 664 information is not supported by this profile. The "WINDOW_UPDATE" 665 and "BLOCKED" QUIC frames are prohibited by this profile. 666 Participants MUST NOT send these frame types. Reception of these 667 frame types MUST be handled as described in Section 4.10. 669 4.6. Stream Termination 671 A sender MAY prematurely terminate the transmission on any unreserved 672 QUIC stream ID by setting the "FIN" bit of a "STREAM" QUIC frame, or 673 by sending a "RST_STREAM" QUIC frame (as specified in 674 [QUIC-TRANSPORT] and [QUIC-HTTP]). 676 Receiving participants MUST NOT make any attempt to send "RST_STREAM" 677 to the multicast group. 679 4.7. Session Shutdown 681 Explicit shutdown of a multicast QUIC session using QUIC methods is 682 not supported by this profile. The "GOAWAY" and "CONNECTION_CLOSE" 683 QUIC frames, and the Public Reset packet are prohibited. 684 Participants MUST NOT send these and reception MUST be handled as 685 described in Section 4.10. 687 Explicit session tear-down using HTTP semantics is allowed, as 688 described in Section 5.5. 690 Implicit shutdown by means of silent close is also supported, as 691 described in Section 3.4. 693 4.8. Session Keep-alive 695 The flow of traffic in a multicast QUIC session is driven by a 696 sender. There may be periods where the sender has no data to send 697 for a period longer than the session idle timeout. This profile 698 repurposes the "PING" QUIC frame to act as a unidirectional keep- 699 alive message that may be sent in order to inform receivers that the 700 session should remain in the Fully-established state. 702 Senders MAY send a "PING" frame at any time in order to inform 703 receivers that the session traffic flow has not fallen idle. This 704 frame MUST NOT be acknowledged. (Indeed "ACK" frames are banned by 705 Section 4.9.) 707 Receiving participants MUST NOT make any attempt to send "PING" 708 frames. 710 4.9. Loss Detection and Recovery 712 Receivers implementing this profile MUST NOT make any attempt to 713 acknowledge the reception of QUIC packets. The "ACK" QUIC frame is 714 prohibited for both senders and receivers. Reception of this frame 715 MUST be handled as described in Section 4.10. 717 The "STOP_WAITING" QUIC frame is also prohibited by this profile. 718 Participants MUST NOT make any attempt to send this frame type. 719 Reception of this frame MUST be handled as described in Section 4.10. 721 {#loss-recovery} specifies alternative strategies for loss recovery. 723 4.10. Prohibited QUIC Frames and Packets 725 The following QUIC packets MUST NOT be transmitted by participants: 726 Public Reset, Version Negotiation. 728 The following QUIC frames MUST NOT be transmitted by participants: 729 "ACK", "BLOCKED", "CONNECTION_CLOSE", "GOAWAY", "STOP_WAITING", 730 "WINDOW_UPDATE". 732 The following QUIC frames MUST NOT be transmitted by receivers: 733 "RST_STREAM". 735 Reception of a prohibited QUIC frame or packet is a protocol error. 736 Receivers MUST ignore all prohibited QUIC frames and packets. 738 5. HTTP/QUIC Profile 740 *Authors' Note:* The HTTP/QUIC mapping document is subject to 741 change. This section is based on draft-ietf-quic-http-01. The 742 authors will track developments and will update this section 743 accordingly. 745 HTTP over multicast QUIC depends on HTTP server push, as described in 746 Section 4.5 of [QUIC-HTTP]. Section 5.2 below applies an additional 747 constraint on the use of server push. A multicast sender 748 participating in a session pushes resources as a series of QUIC 749 "STREAM" frames carrying HTTP/2 "PUSH_PROMISE", "HEADERS" and body 750 data. Examples of this are provided in Appendix B.2. Senders MUST 751 comply with the requirements of the session parameters, as described 752 earlier in Section 3. 754 The profile of HTTP/QUIC specified in this section places additional 755 constrains on the use of metadata compression (Section 5.3) and 756 prioritisation (Section 5.4). 758 5.1. HTTP Connection Settings 760 The "SETTINGS" HTTP/2 frame is prohibited by this profile. 761 Participants MUST NOT make any attempt to send this frame type. 762 Reception of this frame MUST be handled as described in Section 5.7. 764 5.2. Server Push 766 Server push is, by default, enabled for HTTP/QUIC connections. A 767 conventional HTTP/QUIC client may disable server push via an HTTP/2 768 "SETTINGS" frame but the use of that frame is prohibited by this 769 profile (Section 5.1). This profile mandates the use of server push, 770 and specifies no means to disable it. 772 Conventionally, pushed responses are associated with an explicit 773 request from a client. This is not possible when using a 774 unidirectional transport such as multicast IP. This profile reserves 775 the HTTP/2 stream ID that would normally be used for the first client 776 request. "PUSH_PROMISE" frames MUST reference this reserved ID. 778 *Authors' Note:* The exact value of this stream ID is currently in 779 flux. This section will track developments and will be updated 780 accordingly. 782 5.3. Metadata Compression 784 The compression of HTTP header fields is considered in HPACK 785 [RFC7541], which describes two methods for the compression of HTTP 786 header fields: indexing (via static or dynamic tables) and Huffman 787 encoding. In the context of QUIC, QPACK [QPACK] considers changes to 788 the mapping of HPACK that allow for better leverage of the transport. 790 A multicast QUIC session, as described in the present document, does 791 not provide the assurances (receiver participation, transport 792 reliability) required to sufficiently maintain the dynamic decoding 793 context. Therefore, this document requires that endpoints SHALL NOT 794 use dynamic indexing. It is RECOMMENDED that endpoints use static 795 indexing and/or Huffman encoding in order to benefit from the 796 remaining compression methods available. 798 5.4. Prioritisation 800 The "PRIORITY" HTTP/2 frame is prohibited by this profile. 801 Participants MUST NOT make any attempt to send this frame type. 802 Reception of this frame MUST be handled as described in Section 5.7. 804 5.5. Session Tear-down 806 A multicast QUIC session MAY be explicitly torn down by means of the 807 "Connection: close" HTTP header described in section 6.6 of 808 [RFC7230]. A sender intending to leave the session SHOULD include 809 the "Connection: close" header in its response metadata. A sender 810 SHOULD transmit all outstanding frames related to remaining request/ 811 response exchanges before ending transmission to the multicast group. 812 A receiver SHOULD continue to receive and process frames until all 813 outstanding request/response exchanges are complete. 815 5.6. HTTP/2 Extension frames 817 HTTP/2 extension frames (e.g. "ALTSVC") are prohibited by this 818 profile. Participants MUST NOT make any attempt to send extension 819 frame types. Reception of these MUST be handled as described in 820 Section 5.7. 822 5.7. Prohibited HTTP/2 Frames 824 The following HTTP/2 frames MUST NOT be transmitted by participants: 825 "PRIORITY", "SETTINGS". 827 In addition, all HTTP/2 extension frame types MUST NOT be transmitted 828 by participants. 830 Reception of a prohibited HTTP/2 frame is a protocol error. 831 Receivers MUST ignore prohibited HTTP/2 frames. 833 6. Application-Layer Security 835 As already described in Section 3.2, the implicit cipher suite used 836 by a multicast QUIC session makes very limited provision for security 837 in the transport and session layers. This section profiles the use 838 of some additional features to provide equivalent functionality at 839 the application-layer. 841 6.1. Content Integrity 843 In many applications, it is important to ensure that an HTTP 844 representation has been received intact and has not suffered from 845 transmission loss, random bit errors or malicious substitution before 846 passing the received object on to the receiving application. A 847 mechanism is therefore specified here to provide end-to-end content 848 integrity protection for HTTP representations in transit. The use of 849 this content integrity mechanism is RECOMMENDED. 851 *Authors' Note:* We invite review comments on mandating the use of 852 this content integrity mechanism. 854 [RFC3230] specifies an instance digest HTTP header called "Digest". 855 A sender MAY include this header in the "HEADERS" frame of any 856 representation it transmits and a receiver MAY use this header to 857 validate the integrity of the received representation once it has 858 been reassembled. Where this validation fails, the receiver SHOULD 859 discard the representation without processing it further. 861 Note that the digest value protects a whole HTTP instance (i.e. the 862 representation of a resource at the point of transmission as opposed 863 to the body of a particular HTTP message). In cases where partial 864 representations are fragmented over one or more HTTP response 865 messages, the digest value is computed over the complete 866 representation prior to fragmentation into partial responses. 868 In cases where the complete representation is not available at the 869 start of multicast transmission, the "Digest" header MAY be conveyed 870 as a trailing header field after the body data of the representation, 871 in accordance with Section 8.1 of [RFC7540]. 873 Any of the algorithms specified in the IANA registry of digest 874 algorithms (http://www.iana.org/assignments/http-dig-alg/http-dig- 875 alg.xhtml#http-dig-alg-1) MAY be used in conjunction with the 876 "Digest" header. There is no requirement for participants to support 877 the full set of algorithms. 879 6.2. Content Authenticity 881 In some applications, it is important for a receiver to reassure 882 itself that an HTTP representation has been received from an 883 authentic source. It is also sometimes useful for a receiver to know 884 that the information has not been tampered with in transit by a 885 malicious intermediate actor. A mechanism is therefore specified 886 here to prove the authenticity of HTTP messages in transit. The use 887 of this content authenticity mechanism is RECOMMENDED for senders 888 implementing this specification. 890 *Authors' Note:* We invite review comments on mandating the use of 891 this content authenticity mechanism. 893 [I-D.cavage-http-signatures] specifies a means of securely signing 894 metadata associated with any HTTP message. The resulting digital 895 signature is conveyed in the "Signature" header of the message 896 itself. The "Signature" header also conveys a list of HTTP header 897 fields over which the signature was computed. A receiver MAY verify 898 the "Signature" header in order to validate the authenticity of 899 received metadata. Where this validation fails, the receiver SHOULD 900 discard or ignore any related metadata and/or data without processing 901 it further. 903 Note that the signature proves the authenticity of the metadata in a 904 single HTTP message. A "Signature" header MAY be included separately 905 in the "PUSH_PROMISE" frame (protecting the request metadata) and in 906 the final (or only) "HEADERS" frame relating to a particular resource 907 (protecting the response metadata). In order to provide an 908 additional level of protection, however, it is RECOMMENDED that the 909 signature be computed over the combined request metadata (from the 910 "PUSH_PROMISE" frame) and the corresponding response metadata (from 911 the "HEADERS" frames) of the same resource. This binds the request 912 metadata and response metadata together, providing the receiver with 913 additional reassurance of authenticity. In this latter case, the 914 combined digital signature SHALL be conveyed in the final (or only) 915 "HEADERS" frame. 917 In cases where not all metadata is known at the start of 918 transmission, the "Signature" header MAY be conveyed as a trailing 919 header field after the body data of the representation, in accordance 920 with Section 8.1 of [RFC7540]. 922 In applications where the detection of replay attacks is a 923 requirement, it is RECOMMENDED that the "Date" header be included in 924 the scope of the signature. It is RECOMMENDED that receivers use the 925 value of the "Date" header for replay detection using appropriate 926 strategies (e.g. checking for freshness). The definition of such 927 strategies is beyond the scope of this document. 929 In applications where the authenticity and integrity of the 930 transmission are both important, it is RECOMMENDED that the "Digest" 931 header specified in Section 6.1 above is included in the scope of the 932 signature. By signing the instance digest, the authenticity and 933 integrity of the HTTP message body are also assured in addition to 934 that of the metadata. 936 Any of the algorithms specified in the IANA registry of signature 937 algorithms (http://www.iana.org/assignments/signature-algorithms) MAY 938 be used in conjunction with the "Signature" header. There is no 939 requirement for participants to support the full set of algorithms. 941 6.3. Content Confidentiality 943 In applications where there is a requirement for the content itself 944 to remain confidential, appropriate steps SHOULD be taken to protect 945 the application payload, for example by encrypting it. This document 946 does not preclude the use of application-level encryption, but does 947 not specify a mechanism for the distribution of content decryption 948 keys. 950 7. Loss Recovery 952 Because the acknowledgement of received packets to multicast groups 953 is prohibited by this specification (Section 4.9) the detection of 954 discarded or corrupted packets is the sole responsibility of the 955 receiver, and such losses must be recovered by means other than the 956 retransmission mechanism specified in [QUIC-TRANSPORT] and 957 [QUIC-RECOVERY]. 959 7.1. Forward Error Correction 961 *Authors' Note:* A simple parity-based Forward Error Correction 962 scheme was removed from the experimental QUIC wire protocol 963 specification in version Q032. The IETF's QUIC Working Group is 964 chartered to specify one (or more) new FEC schemes in the future. 965 This section will track developments in this area, and will be 966 updated accordingly. 968 A sender MAY make use of a suitable Forward Error Correction scheme 969 to allow a receiver to reconstruct lost packets from those that have 970 been successfully received. 972 7.2. Unicast Repair 974 In the case where a lost QUIC packet cannot be recovered using 975 Forward Error Correction, either because the number of packets lost 976 exceeds the scheme's threshold for reconstruction, or because FEC is 977 not in use on the multicast QUIC session, a receiver MAY instead 978 recover the missing payload data using conventional unicast HTTP 979 requests to an origin server. 981 o The total size of the resource is indicated in the "content- 982 length" response header carried in the "HEADERS" HTTP/2 frame. 984 o The location of the missing data can be determined by examining 985 the Offset field in the "STREAM" QUIC frame headers of 986 successfully received QUIC packets. 988 Using this information, a receiver MAY compose an efficient HTTP 989 range request [RFC7233] to the origin server indicated in the URL. 990 Several disjoint ranges MAY be combined into a single HTTP request. 991 A receiver MAY direct its request to an alternative server using Alt- 992 Svc information received on the multicast QUIC session, or else 993 received as part of a previous unicast HTTP response according to the 994 rules in [RFC7838]. 996 8. Transmission of Partial Content 998 Under certain circumstances, a sender may not be in full possession 999 of a resource body when transmission begins, or may not be able to 1000 guarantee that a transmission will complete. In such cases, the 1001 sender MAY employ the syntax of an HTTP range request [RFC7233] to 1002 indicate partial content, as specified below. All receivers SHALL 1003 implement support for such HTTP range requests. 1005 If partial content is to be transmitted: 1007 o The "range" header (Section 3.1 of [RFC7233]) SHALL be present in 1008 the "PUSH_PROMISE" HTTP/2 frame. 1010 o The corresponding "HEADERS" HTTP/2 frame SHALL indicate HTTP 1011 status code 206. 1013 * The range being transmitted SHALL be indicated in a "content- 1014 range" header field and the size of the complete resource 1015 indicated in a "content-length" header field. Either or both 1016 of these headers fields MAY be transmitted in a trailing 1017 "HEADERS" frame if their values are not known at the start of 1018 transmission. 1020 9. Protocol Identifier 1022 The HTTP over multicast QUIC protocol specified in this document is 1023 identified by the application-layer protocol negotiation (ALPN) 1024 [RFC7301] identifier "hqm". The IANA registration of this protocol 1025 identifier can be found in Section 12.1. This reserves the ALPN 1026 identifier space but describes a protocol that does not use TLS. The 1027 usage of the "hqm" identifier for discoverability is described in 1028 Section 10. 1030 9.1. Draft Version Identification 1032 *RFC Editor's Note:* Please remove this section prior to 1033 publication of a final version of this document. 1035 Only implementations of the final, published RFC can identify 1036 themselves as "hqm". Until such an RFC exists, implementations MUST 1037 NOT identify themselves using this string. 1039 Implementations of draft versions of the protocol MUST add the string 1040 "-" and the corresponding draft number to the identifier. For 1041 example, draft-pardue-quic-http-mcast-00 is identified using the 1042 string "hqm-00". 1044 Non-compatible experiments that are based on these draft versions 1045 MUST append the string "-" and an experiment name to the identifier. 1046 For example, an experimental implementation based on draft-pardue- 1047 quic-http-mcast-09 which removes the requirement to ensure version 1048 matches might identify itself as "hqm-09-version-ignorant". Note 1049 that any label MUST conform to the "token" syntax defined in 1050 Section 3.2.6 of [RFC7230]. Experimenters are encouraged to 1051 coordinate their experiments. 1053 10. Discovery of Multicast QUIC Sessions 1055 The announcement and discovery of services operating over multicast 1056 IP has previously been specified by the Session Description Protocol 1057 (SDP) [RFC4566], Session Announcement Protocol [RFC2974] and Session 1058 Initiation Protocol [RFC3261]. These are typically deployed together 1059 and in conjunction with a multicast-friendly transport such as the 1060 Real-time Transport Protocol (RTP) [RFC3550]. 1062 In contrast, the present document specifies a mechanism for 1063 advertising services that is built into HTTP metadata and is 1064 consistent across unicast and multicast resource delivery modes. 1065 This means that a single application-layer can be used for service 1066 advertisement/discovery, and for bulk data transmission/reception. 1067 Specifically, the "Alt-Svc" HTTP header is specified as the means to 1068 advertise multicast services from a unicast service. A unicast HTTP 1069 response MAY be decorated with an Alt-Svc value that hints to the 1070 client about the availability of the resource via a multicast QUIC 1071 session. A client that supports such a multicast QUIC session MAY 1072 then transparently switch to it. 1074 Symmetrically, the "Alt-Svc" header can also be used to advertise the 1075 unicast service from a multicast service. A resource transmitted as 1076 part of a multicast QUIC session MAY be decorated with an Alt-Svc 1077 value that hints to the client about the availability of the resource 1078 via an alternative unicast HTTP server. A receiver MAY then use this 1079 HTTP server for unicast resource patching (Section 7.2). 1081 Where HTTP over multicast QUIC sessions are advertised using Alt-Svc, 1082 the protocol identifier SHALL be "hqm", as specified in Section 9. 1084 10.1. Source-specific Multicast Advertisement 1086 Source-specific multicast (SSM) [RFC4607] MAY be used for the 1087 delivery of multicast services. 1089 *Authors' Note:* We invite review comments on mandating the use of 1090 source-specific multicast only. 1092 This document specifies the "source-address" parameter for Alt-Svc, 1093 which is used to provide the SSM source address to endpoints. 1095 Syntax: 1097 source-address = uri-host; see RFC7230, Section 2.7 1099 For example: 1101 source-address="192.0.2.1" 1103 When a multicast QUIC session is provided using SSM, the "source- 1104 address" parameter MUST be advertised. 1106 10.2. Session Parameter Advertisement 1108 The concept of session parameters is introduced in Section 2.2. This 1109 section details how the session parameters are expressed as Alt-Svc 1110 parameters. 1112 10.2.1. Version 1114 The version of QUIC supported in a multicast QUIC session is 1115 advertised with the "quic" parameter. The requirements for endpoint 1116 usage of "quic" are specified in Section 3.1. 1118 10.2.2. Cipher Suite 1120 This document specifies the "cipher-suite" parameter for Alt-Svc, 1121 which carries the cipher suite in use by a multicast QUIC session. 1122 "cipher-suite" MUST be contain one of the values contained in the TLS 1123 Cipher Suite Registry (http://www.iana.org/assignments/tls- 1124 parameters/tls-parameters.xhtml#tls-parameters-4): 1126 Syntax: 1128 cipher-suite = 4*4 HEXDIG 1130 For example, the following specifies cipher suite 0x13,0x01 1131 ("TLS_AES_128_GCM_SHA256"): 1133 cipher-suite=1301 1135 The requirements for endpoint usage of "cipher-suite" are described 1136 in Section 3.2. 1138 10.2.3. Session Key 1140 This document specifies the "key" parameter for Alt-Svc, which 1141 carries the cryptographic key in use by the multicast QUIC session. 1143 Syntax: 1145 key = *HEXDIG 1147 For example: 1149 key=4adf1eab9c2a37fd 1151 The requirements for endpoint usage of "key" are described in 1152 Section 3.2. 1154 10.2.4. Session Identification 1156 This document defines the "session-id" parameter for Alt-Svc, which 1157 carries the multicast QUIC session identifier. 1159 Syntax: 1161 session-id = 1*16HEXDIG ; 64-bit value 1163 For example, the following specifies session 101 (0x65 hexadecimal): 1165 session-id=65 1167 The requirements for endpoint usage of "session-id" are described in 1168 Section 2.3. 1170 10.2.5. Session Idle Timeout Period 1172 This document specifies the "session-idle-timeout" parameter for Alt- 1173 Svc, which carries the idle timeout period of a multicast QUIC 1174 session. 1176 Syntax: 1178 session-idle-timeout = *DIGIT ; number of seconds between 0 and 600 1179 For example, the following specifies a one-minute session idle 1180 timeout period: 1182 session-idle-timeout=60 1184 The requirements for endpoint usage of "session-idle-timeout" are 1185 described in Section 3.4. 1187 10.2.6. Stream Concurrency 1189 This document specifies the "max-concurrent-resources" parameter for 1190 Alt-Svc, which expresses the maximum number of concurrent active 1191 resources from the sender in a multicast QUIC session. 1193 max-concurrent-resources = *DIGIT ; unsigned 32-bit integer 1195 For example, the following specifies that no more than 12 (decimal) 1196 resources will be concurrently active in the session: 1198 max-concurrent-resources=12 1200 The requirements for endpoint usage of "max-concurrent-streams" are 1201 described in Section 3.6. 1203 10.2.7. Session Peak Flow Rate 1205 This parameter expresses the expected maximum transfer rate of data 1206 from all sources of the multicast QUIC session. 1208 peak-flow-rate = *DIGIT ; bits per second 1210 For example, the following specifies a peak flow rate of 550 kbits/s 1211 in the session: 1213 peak-flow-rate=550000 1215 The requirements for endpoint usage of "peak-flow-rate" are described 1216 in Section 3.5. 1218 11. Security and Privacy Considerations 1220 This document specifies a profile of QUIC and HTTP/QUIC that changes 1221 the security model. In order to address this, application-level 1222 security methods are described in Section 6. This document does not 1223 preclude the use of secure multicast approaches that may provide 1224 additional security assurances required for certain use cases. 1226 The use of side-channel or out-of-band technologies (potentially 1227 bidirectional interactions) to support multicast QUIC sessions are 1228 considered out of this document's scope. Services using such 1229 technologies should apply their security considerations accordingly. 1231 11.1. Pervasive Monitoring 1233 Certain multicast deployment architectures may require the use of a 1234 session decryption key shared by all participants. Furthermore, the 1235 discovery mechanism described in this document provides a means for a 1236 receiver to obtain a session decryption key without joining the 1237 session. The act of removing packet protection in order to inspect 1238 or modify application contents may, in certain deployments, be 1239 trivial. The exploration of restricting key learning or session 1240 joining to authorised participants goes beyond the scope of this 1241 document. 1243 Because in-band multicast interactions are unidirectional, the impact 1244 of Pervasive Monitoring [RFC7258] on in-band traffic flows is 1245 inherently reduced. Actors can only inspect or modify sender- 1246 initiated traffic. Additional measures for content confidentiality 1247 may mitigate the impact further. This is discussed in Section 6.3. 1249 Further Pervasive Monitoring concerns are addressed in the following 1250 sections. 1252 11.1.1. Large-scale Data Gathering and Correlation 1254 Multicast QUIC sessions decouple sending and receiving participants. 1255 Session participation is subject to operations that allow an endpoint 1256 to join or leave a multicast group, typically IGMP [RFC3376] or MLD 1257 [RFC3810]. The propagation intent of these messages travelling 1258 deeper through a network hierarchy generally leads to the 1259 anonymisation of data if implemented as specified. It may be 1260 possible to gather user-identifiable messages close to the network 1261 edge, for example a router logging such messages. However, this 1262 would require wide-ranging access across Internet Service Provider 1263 networks. Therefore, while such attacks are feasible, it can be 1264 asserted that gathering and correlating user-identifiable traffic is 1265 difficult to perform covertly and at scale. 1267 11.1.2. Changing Content 1269 Sessions that use a symmetric key for packet protection are subject 1270 to the possibility of a malicious actor modifying traffic at some 1271 point in the network between a legitimate sender and one (or more) 1272 receivers. Receiver-side validation, as specified in Section 6 of 1273 the present document, and also in [QUIC-TRANSPORT], allows for the 1274 detection of such modification. Two approaches help mitigate the 1275 impact of modification; the first is application-level methods that 1276 protect data (Section 6.1) and metadata (Section 6.2); the second is 1277 reduction of the QUIC packet attack surface by means of removal of 1278 many frame types (Section 4.10 and Section 5.7). 1280 11.2. Protection of Discovery Mechanism 1282 Multicast QUIC session advertisements SHOULD be conveyed over a 1283 secure transport that guarantees authenticity and integrity in order 1284 to mitigate attacks related to a malicious service advertisement, for 1285 example a "man in the middle" directing endpoints to a service that 1286 may lead to other attacks or exploitations. 1288 *Authors' Note:* We invite review comments on mandating the use of 1289 a secure transport for advertising sessions. 1291 Endpoints that make use of multicast QUIC session advertisements 1292 SHOULD have reasonable assurance that the alternative service is 1293 under control of, and valid for, the whole origin, as described in 1294 Section 2.1 of [RFC7838]. Section 6.2 discusses measures that may be 1295 used to fulfil this requirement. 1297 11.3. Spoofing 1299 11.3.1. Spoofed Ack Attacks 1301 The Spoofed "ACK" attack described in Section 12.1 of 1302 [QUIC-TRANSPORT] is out of scope because use of the "ACK" frame is 1303 prohibited (Section 4.9) by the present document. 1305 11.3.2. Sender Spoofing 1307 A malicious actor may be able to stage a spoof attack by sending fake 1308 QUIC packets to a multicast QUIC session. This could affect the 1309 operation or behaviour of receivers. In a multicast scenario, this 1310 form of attack has the potential to scale massively. 1312 The feasibility of spoofing a multicast sender is governed by the 1313 characteristics of the multicast deployment and network 1314 infrastructure. The use of source-specific multicast [RFC4607] may 1315 reduce the feasibility. The use of content authenticity 1316 (Section 6.2) may mitigate concerns for the application-level 1317 messages. However, there remains the possibility for transport-level 1318 messages to be spoofed. Multicast applications should consider 1319 further mitigations to address this concern. 1321 11.3.3. Receiver Spoofing 1323 Client source address concerns discussed in Section 6.2.2 of 1324 [QUIC-TRANSPORT] are out of scope because the connection 1325 establishment is replaced with session establishment in the present 1326 document. Further, the impact that spoofed receivers would have on 1327 the sender is minimal. The impact of malicious participants on the 1328 network is discussed in Section 11.6.2. 1330 11.4. Replay Attacks 1332 Conventional QUIC strategies for protecting against replay attacks 1333 apply similarly here. 1335 Certain multicast QUIC sessions may use a shared key for transport- 1336 level encryption, which would allow an attacker to record, decrypt, 1337 repackage and replay QUIC packets. Section 6.2 discusses how the 1338 application-level contents may be protected from replay (by signing 1339 the "Date" HTTP header), which provides some mitigation to the 1340 success rate or effects of replay attacks. 1342 11.5. Message Deletion 1344 Since HTTP over multicast QUIC is designed to tolerate unreliable 1345 delivery, the impacts of message deletion attacks are presumed to be 1346 small. Deletion of packets carrying HTTP headers will cause a 1347 receiver to ignore subsequent packets carrying body data. 1348 Furthermore, the use of multicast QUIC sessions is opportunistic; 1349 disruption in service (for example, deleting packets and causing a 1350 receiver to fail in construction of a content object) is mitigated by 1351 falling back to a unicast service. Considerations for how this may 1352 affect the performance of the unicast service are given in 1353 Section 11.6.3. 1355 11.6. Denial of Service 1357 11.6.1. Unprotected Frames and Packets 1359 The handling of unprotected QUIC packets is discussed in section 1360 7.1.4 of [QUIC-TLS]. The profile described in the present document 1361 provides the means for a multicast sender to protect QUIC packets 1362 with a shared key, which is not a strong protection. The weak 1363 protection of QUIC packets could present a denial-of-service risk. 1364 To mitigate the impact of handling such QUIC packets, certain frames 1365 and packets are prohibited as described in (Section 4.10 and 1366 Section 5.7). 1368 The frame types that are allowed by this profile do not present a 1369 risk of denial of service. Concerns over authenticity and integrity 1370 are addressed by the application-layer protection mechanisms 1371 described in Section 6. 1373 11.6.2. Network Performance Degradation 1375 The possibility for malfunctioning or malicious participants to 1376 degrade the network is a broad issue and considered out of scope for 1377 this document. Guidelines and concerns discussed in UDP Best 1378 Practices [I-D.ietf-tsvwg-rfc5405bis] and other sources apply equally 1379 here. This specification does not preclude the use of network 1380 performance degradation mitigation solutions such as network circuit 1381 breakers. 1383 11.6.3. Unicast Repair Stampeding Herd 1385 Deployments that support the unicast repair mechanism described in 1386 Section 7.2 should be aware that a triggering of this behaviour 1387 (either deliberate, planned or unplanned) in a large population of 1388 multicast receivers may cause a stampeding herd of client requests to 1389 the unicast repair service. Service operators SHOULD mitigate the 1390 impact of stampeding herd on their deployment. 1392 11.7. Receiver Resource Usage 1394 The application of receiver-side validation, as defined in the 1395 present document and in [QUIC-TRANSPORT], adds some protection 1396 against allocating resource to the processing of bad data. 1398 11.8. Unicast Repair Information Leakage 1400 The unicast repair mechanism may lead to the leakage of user 1401 behaviour data. An attacker could gain insight into any receiver 1402 participating in a multicast QUIC session, for example by monitoring 1403 the TCP port of the unicast alternative. This alone is no worse than 1404 current abilities to monitor unicast interactions, for example 1405 observing the SNI field contained in a TLS ClientHello. The complete 1406 protection of unicast interactions is beyond the scope of this 1407 document. However, knowledge that a user (or group of users) has 1408 participated in a session is sensitive and may be obtained by 1409 correlation between with observable multicast and unicast traffic. 1411 To give an example, a malicious "man in the middle" could purposely 1412 cause all receivers to perform a unicast repair (by disrupting the 1413 QUIC traffic flow in some way). The disruption is untargeted and may 1414 be simple to orchestrate, but the correlation of user activity data, 1415 especially across a distributed repair service (e.g. a CDN), requires 1416 resources that may reduce the attractiveness of such an attack. 1418 The ability for an attacker to disrupt multicast QUIC sessions is 1419 mitigated by this profile (mainly the prohibition of frames and 1420 packets). Application-layer security measures described in Section 6 1421 reduce the feasibility further. 1423 Multicast receivers concerned about this form of leakage can 1424 eliminate this risk completely by disabling support for unicast 1425 repair, at the potential cost of reduced service quality. 1427 12. IANA Considerations 1429 12.1. Registration of Protocol Identification String 1431 This document creates a new registration for the identification of 1432 the HTTP over multicast QUIC protocol in the "Application-Layer 1433 Protocol Negotiation (ALPN) Protocol IDs" registry established by 1434 [RFC7301]. 1436 The "hqm" string identifies HTTP semantics expressed as HTTP mapped 1437 to a QUIC layer and carried over IP multicast: 1439 Protocol: Bulk data transport using HTTP over multicast QUIC 1441 Identification Sequence: 0x68 0x71 0x6D ("hqm") 1443 Specification: This document, Section 9 1445 This entry reserves an identifier that is not allowed to appear in 1446 TLS Application-Layer Protocol Negotiation. 1448 12.2. Registration of Alt-Svc parameters 1450 This document creates seven registrations for the identification of 1451 parameters for the "Hypertext Transfer Protocol (HTTP) Alt-Svc 1452 Parameter Registry" established by [RFC7838] 1453 (http://www.iana.org/assignments/tls-extensiontype-values/tls- 1454 extensiontype-values.xhtml#alpn-protocol-ids). 1456 12.2.1. Source Address 1458 Parameter name: source-address 1460 Specification: This document, Section 10.1 1462 12.2.2. Cipher Suite 1464 Parameter name: cipher-suite 1466 Specification: This document, Section 10.2.2 1468 12.2.3. Key 1470 Parameter name: key 1472 Specification: This document, Section 10.2.3 1474 12.2.4. Session Identifier 1476 Parameter name: session-id 1478 Specification: This document, Section 10.2.4 1480 12.2.5. Session Idle Timeout 1482 Parameter name: session-idle-timeout 1484 Specification: This document, Section 10.2.5 1486 12.2.6. Maximum Concurrent Resources 1488 Parameter name: max-concurrent-resources 1490 Specification: This document, Section 10.2.6 1492 12.2.7. Peak Flow Rate 1494 Parameter name: peak-flow-rate 1496 Specification: This document, Section 10.2.7 1498 13. References 1500 13.1. Normative References 1502 [I-D.cavage-http-signatures] 1503 Cavage, M. and M. Sporny, "Signing HTTP Messages", draft- 1504 cavage-http-signatures-06 (work in progress), January 1505 2017. 1507 [QUIC-HTTP] 1508 Bishop, M., Ed., "Hypertext Transfer Protocol (HTTP) over 1509 QUIC". 1511 [QUIC-RECOVERY] 1512 Iyengar, J., Ed. and I. Swett, Ed., "QUIC Loss Detection 1513 and Congestion Control". 1515 [QUIC-TLS] 1516 Thomson, M., Ed. and S. Turner, Ed, Ed., "Using Transport 1517 Layer Security (TLS) to Secure QUIC". 1519 [QUIC-TRANSPORT] 1520 Iyengar, J., Ed. and M. Thomson, Ed., "QUIC: A UDP-Based 1521 Multiplexed and Secure Transport". 1523 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 1524 Requirement Levels", BCP 14, RFC 2119, 1525 DOI 10.17487/RFC2119, March 1997, 1526 . 1528 [RFC3230] Mogul, J. and A. Van Hoff, "Instance Digests in HTTP", 1529 RFC 3230, DOI 10.17487/RFC3230, January 2002, 1530 . 1532 [RFC4607] Holbrook, H. and B. Cain, "Source-Specific Multicast for 1533 IP", RFC 4607, DOI 10.17487/RFC4607, August 2006, 1534 . 1536 [RFC5234] Crocker, D., Ed. and P. Overell, "Augmented BNF for Syntax 1537 Specifications: ABNF", STD 68, RFC 5234, 1538 DOI 10.17487/RFC5234, January 2008, 1539 . 1541 [RFC7230] Fielding, R., Ed. and J. Reschke, Ed., "Hypertext Transfer 1542 Protocol (HTTP/1.1): Message Syntax and Routing", 1543 RFC 7230, DOI 10.17487/RFC7230, June 2014, 1544 . 1546 [RFC7233] Fielding, R., Ed., Lafon, Y., Ed., and J. Reschke, Ed., 1547 "Hypertext Transfer Protocol (HTTP/1.1): Range Requests", 1548 RFC 7233, DOI 10.17487/RFC7233, June 2014, 1549 . 1551 [RFC7234] Fielding, R., Ed., Nottingham, M., Ed., and J. Reschke, 1552 Ed., "Hypertext Transfer Protocol (HTTP/1.1): Caching", 1553 RFC 7234, DOI 10.17487/RFC7234, June 2014, 1554 . 1556 [RFC7301] Friedl, S., Popov, A., Langley, A., and E. Stephan, 1557 "Transport Layer Security (TLS) Application-Layer Protocol 1558 Negotiation Extension", RFC 7301, DOI 10.17487/RFC7301, 1559 July 2014, . 1561 [RFC7405] Kyzivat, P., "Case-Sensitive String Support in ABNF", 1562 RFC 7405, DOI 10.17487/RFC7405, December 2014, 1563 . 1565 [RFC7540] Belshe, M., Peon, R., and M. Thomson, Ed., "Hypertext 1566 Transfer Protocol Version 2 (HTTP/2)", RFC 7540, 1567 DOI 10.17487/RFC7540, May 2015, 1568 . 1570 [RFC7838] Nottingham, M., McManus, P., and J. Reschke, "HTTP 1571 Alternative Services", RFC 7838, DOI 10.17487/RFC7838, 1572 April 2016, . 1574 13.2. Informative References 1576 [I-D.ietf-tsvwg-rfc5405bis] 1577 Eggert, L., Fairhurst, G., and G. Shepherd, "UDP Usage 1578 Guidelines", draft-ietf-tsvwg-rfc5405bis-19 (work in 1579 progress), October 2016. 1581 [QPACK] Bishop, M., Ed., "HTTP over QUIC - Mapping and Header 1582 Compression". 1584 [QUICCrypto] 1585 Langley, A. and W. Chang, "QUIC Crypto", May 2016, 1586 . 1588 [RFC1112] Deering, S., "Host extensions for IP multicasting", STD 5, 1589 RFC 1112, DOI 10.17487/RFC1112, August 1989, 1590 . 1592 [RFC1191] Mogul, J. and S. Deering, "Path MTU discovery", RFC 1191, 1593 DOI 10.17487/RFC1191, November 1990, 1594 . 1596 [RFC2460] Deering, S. and R. Hinden, "Internet Protocol, Version 6 1597 (IPv6) Specification", RFC 2460, DOI 10.17487/RFC2460, 1598 December 1998, . 1600 [RFC2974] Handley, M., Perkins, C., and E. Whelan, "Session 1601 Announcement Protocol", RFC 2974, DOI 10.17487/RFC2974, 1602 October 2000, . 1604 [RFC3261] Rosenberg, J., Schulzrinne, H., Camarillo, G., Johnston, 1605 A., Peterson, J., Sparks, R., Handley, M., and E. 1606 Schooler, "SIP: Session Initiation Protocol", RFC 3261, 1607 DOI 10.17487/RFC3261, June 2002, 1608 . 1610 [RFC3376] Cain, B., Deering, S., Kouvelas, I., Fenner, B., and A. 1611 Thyagarajan, "Internet Group Management Protocol, Version 1612 3", RFC 3376, DOI 10.17487/RFC3376, October 2002, 1613 . 1615 [RFC3550] Schulzrinne, H., Casner, S., Frederick, R., and V. 1616 Jacobson, "RTP: A Transport Protocol for Real-Time 1617 Applications", STD 64, RFC 3550, DOI 10.17487/RFC3550, 1618 July 2003, . 1620 [RFC3810] Vida, R., Ed. and L. Costa, Ed., "Multicast Listener 1621 Discovery Version 2 (MLDv2) for IPv6", RFC 3810, 1622 DOI 10.17487/RFC3810, June 2004, 1623 . 1625 [RFC4566] Handley, M., Jacobson, V., and C. Perkins, "SDP: Session 1626 Description Protocol", RFC 4566, DOI 10.17487/RFC4566, 1627 July 2006, . 1629 [RFC4821] Mathis, M. and J. Heffner, "Packetization Layer Path MTU 1630 Discovery", RFC 4821, DOI 10.17487/RFC4821, March 2007, 1631 . 1633 [RFC5737] Arkko, J., Cotton, M., and L. Vegoda, "IPv4 Address Blocks 1634 Reserved for Documentation", RFC 5737, 1635 DOI 10.17487/RFC5737, January 2010, 1636 . 1638 [RFC6676] Venaas, S., Parekh, R., Van de Velde, G., Chown, T., and 1639 M. Eubanks, "Multicast Addresses for Documentation", 1640 RFC 6676, DOI 10.17487/RFC6676, August 2012, 1641 . 1643 [RFC7258] Farrell, S. and H. Tschofenig, "Pervasive Monitoring Is an 1644 Attack", BCP 188, RFC 7258, DOI 10.17487/RFC7258, May 1645 2014, . 1647 [RFC7450] Bumgardner, G., "Automatic Multicast Tunneling", RFC 7450, 1648 DOI 10.17487/RFC7450, February 2015, 1649 . 1651 [RFC7541] Peon, R. and H. Ruellan, "HPACK: Header Compression for 1652 HTTP/2", RFC 7541, DOI 10.17487/RFC7541, May 2015, 1653 . 1655 Appendix A. Acknowledgements 1657 The authors would like to thank the following for their contributions 1658 to the design described in the present document: Brandon Butterworth, 1659 Sam Hurst, Chris Poole, Craig Taylor and David Waring. 1661 Appendix B. Examples 1663 This appendix contains examples of multicast QUIC session 1664 advertisement and resource transfer (with and without application- 1665 layer content security). 1667 B.1. Session Advertisement 1669 This section shows several different examples of an HTTP service 1670 advertising a multicast QUIC session. Examples are given in IPv4 1671 form, using reserved address ranges as specified in [RFC5737] and 1672 [RFC6676]. 1674 B.1.1. Source-specific Multicast QUIC Session 1676 Advertisement of a multicast QUIC session operating on the source- 1677 specific multicast group address 232.0.0.1 on port 2000 with the 1678 source address 192.0.2.1. The session ID is 16 (0x10) and the idle 1679 timeout is one minute. At most 10 resources may be concurrently 1680 active in the session and the flow rate should not exceed 10 kbits/s. 1681 The multicast transport is unencrypted. 1683 HTTP Alternative Service header field: 1685 Alt-Svc: 1686 hqm="232.0.0.1:2000"; source-address="192.0.2.1"; quic=1; 1687 session-id=10; session-idle-timeout=60; 1688 max-concurrent-resources=10; peak-flow-rate=10000 1690 B.1.2. Source-specific Multicast QUIC Session with Transport Encryption 1691 using a Symmetric Key 1693 Advertisement of a multicast QUIC session operating on the IPv6 1694 globally-scoped source-specific multicast group address ff3e::1234 on 1695 port 2000 with the source address 2001:db8::1. The session ID is 16 1696 (0x10) and the idle timeout is one minute. At most 10 resources may 1697 be concurrently active in the session and the flow rate should not 1698 exceed 10 kbits/s. The multicast transport is encrypted using the 1699 AEAD cipher suite 0x13,0x01 ("TLS_AES_128_GCM_SHA256") and the shared 1700 session key provided. 1702 HTTP Alternative Service header field: 1704 Alt-Svc: 1705 hqm="[ff3e::1234]:2000"; source-address="2001:db8::1"; quic=1; 1706 session-id=10; session-idle-timeout=60; 1707 max-concurrent-resources=10; peak-flow-rate=10000; 1708 cipher-suite=1301; key=4adf1eab9c2a37fd 1710 B.2. Resource Transfer 1712 This section shows several different examples of the HTTP message 1713 patterns for a single resource. 1715 Examples that show "PUSH_PROMISE" or "HEADERS" HTTP/2 frames describe 1716 the contents of enclosed header block fragments. 1718 B.2.1. Transfer without Content Integrity or Authenticity 1720 "PUSH_PROMISE" HTTP/2 frame: 1722 :method: GET 1723 :scheme: https 1724 :path: /files/example.txt 1725 :authority: example.org 1727 "HEADERS" HTTP/2 frame; 1729 :status: 200 1730 content-length: 100 1731 content-type: text/plain 1732 date: Fri, 20 Jan 2017 10:00:00 GMT 1734 QUIC "STREAM" frame containing 100 bytes of response body data: 1736 ... 1738 B.2.2. Transfer of Partial Content without Content Integrity or 1739 Authenticity 1741 In this example, partial content is transferred as described in 1742 Section 8. The "Range" request header is used to indicate the 1743 sender's intention to transfer all 100 bytes of the representation, 1744 but the "Content-Range" trailing response header indicates that only 1745 the first 50 bytes were actually transferred. 1747 "PUSH_PROMISE" HTTP/2 frame: 1749 :method: GET 1750 :scheme: https 1751 :path: /files/example.txt 1752 :authority: example.org 1753 range: bytes=0-* 1755 Leading "HEADERS" HTTP/2 frame: 1757 :status: 206 1758 content-length: 100 1759 content-type: text/plain 1760 date: Fri, 20 Jan 2017 10:00:00 GMT 1762 "STREAM" QUIC frame containing 50 bytes of response body data: 1764 ... 1766 Trailing "HEADERS" HTTP/2 frame indicating the range of bytes sent: 1768 content-range: bytes 0-49/100 1770 B.2.3. Transfer with Content Integrity and without Authenticity 1772 In this example, content integrity is assured by the inclusion of the 1773 "Digest" response header, as described in Section 6.1. 1775 "PUSH_PROMISE" HTTP/2 frame: 1777 :method: GET 1778 :scheme: https 1779 :path: /files/example.txt 1780 :authority: example.org 1782 "HEADERS" HTTP/2 frame including the "Digest" header: 1784 :status: 200 1785 content-length: 100 1786 content-type: text/plain 1787 date: Fri, 20 Jan 2017 10:00:00 GMT 1788 digest: SHA-256=DieQ9zfRaDdyAilTVCvmBePuxMm+B6cNocP+QCrNSqo= 1790 "STREAM" QUIC frame containing 100 bytes of response body data: 1792 ... 1794 B.2.4. Partial Transfer with Content Integrity and without Authenticity 1796 In this example, partial content is transferred as described in 1797 Section 8. The "Range" request header is used to indicate the 1798 sender's intention to transfer all 100 bytes of the representation, 1799 but the "Content-Range" trailing response header indicates that only 1800 the first 50 bytes were actually transferred. Content integrity is 1801 assured by the inclusion of the "Digest" response header, as 1802 described in Section 6.1. 1804 "PUSH_PROMISE" HTTP/2 frame: 1806 :method: GET 1807 :scheme: https 1808 :path: /files/example.txt 1809 :authority: example.org 1810 range: bytes=0-* 1812 Leading "HEADERS" HTTP/2 frame including the "Digest" header: 1814 :status: 206 1815 content-length: 100 1816 content-type: text/plain 1817 date: Fri, 20 Jan 2017 10:00:00 GMT 1818 digest: SHA-256=DieQ9zfRaDdyAilTVCvmBePuxMm+B6cNocP+QCrNSqo= 1820 "STREAM" QUIC frame containing 50 bytes of response body data: 1822 ... 1824 Trailing "HEADERS" HTTP/2 frame indicating the range of bytes sent: 1826 content-range: bytes 0-49/100 1828 B.2.5. Transfer with Content Integrity and Authenticity 1830 In this example, content integrity is assured by the inclusion of the 1831 "Digest" response header, as described in Section 6.1. Content 1832 authenticity is assured separately for the request and the response 1833 messages by the "Signature" header which protects the header fields 1834 described in further detail below. The "Signature" header parameter 1835 "keyId" contains the URL of a file containing the public key related 1836 to the multicast sender's private key used to create the digital 1837 signature. 1839 "PUSH_PROMISE" HTTP/2 frame including a "Signature" header protecting 1840 the ":method" and ":path" (the request target), as well as the 1841 ":scheme" and ":authority" of the pseudo-request: 1843 :method: GET 1844 :scheme: https 1845 :path: /files/example.txt 1846 :authority: example.org 1847 signature: keyId="https://example.org/mcast-sender.example.org.pem", 1848 algorithm=rsa-sha256, 1849 headers="(request-target) :scheme :authority", 1850 signature="MGQCMFTaFptaM2FhgzJq2i9AaChuFDHjp6GiXVtRnI8BsA" 1852 "HEADERS" HTTP/2 frame including a "Signature" header protecting the 1853 ":method", ":path", ":scheme" and ":authority" of the pseudo-request 1854 above, plus the "Date" and "Digest" of the response: 1856 :status: 200 1857 content-length: 100 1858 content-type: text/plain 1859 date: Fri, 20 Jan 2017 10:00:00 GMT 1860 digest: SHA-256=DieQ9zfRaDdyAilTVCvmBePuxMm+B6cNocP+QCrNSqo= 1861 signature: keyId="https://example.org/mcast-sender.example.org.pem", 1862 algorithm=rsa-sha256, 1863 headers="(request-target) :scheme :authority date digest", 1864 signature="MGUCMBgx6cuwTzg0W29zNUra8xfMsEcb3rFA3Y" 1866 "STREAM" QUIC frame containing response body data: 1868 ... 1870 B.2.6. Partial Transfer with Content Integrity and Authenticity 1872 In this example, partial content is transferred and the "Range" 1873 header (as described in Section 8) is used to indicate that 50 bytes 1874 out of 100 bytes were transferred. Content integrity is provided by 1875 the inclusion of the "Digest" header, as described in Section 6.1. 1876 Authenticity is provided by the "Signature" header which protects the 1877 header fields described in further detail. The "Signature" header 1878 parameter "keyId" contains the URL of a file containing the public 1879 key related to the multicast sender's private key used to create the 1880 digital signature. 1882 "PUSH_PROMISE" HTTP/2 frame: 1884 :method: GET 1885 :scheme: https 1886 :path: /files/example.txt 1887 :authority: example.org 1888 range: bytes=0-* 1889 signature: keyId="https://example.org/mcast-sender.example.org.pem", 1890 algorithm=rsa-sha256, 1891 headers="(request-target) :scheme :authority range", 1892 signature="MGQCMFTaFptaM2FhgzJq2i9AaChuFDHjp6GiXVtRnI8BsA" 1894 Leading "HEADERS" HTTP/2 frame: 1896 :status: 206 1897 content-length: 100 1898 content-type: text/plain 1899 date: Fri, 20 Jan 2017 10:00:00 GMT 1900 digest: SHA-256=DieQ9zfRaDdyAilTVCvmBePuxMm+B6cNocP+QCrNSqo= 1902 QUIC "STREAM" frame containing response body data: 1904 ... 1906 Trailing "HEADERS" HTTP/2 frame protecting the ":method", ":path", 1907 ":scheme" and ":authority" of the pseudo-request above, plus the 1908 "Date", "Digest" and "Content-Range" of the response:: 1910 content-range: bytes 0-49/100 1911 signature: keyId="https://example.org/mcast-sender.example.org.pem", 1912 algorithm=rsa-sha256, 1913 headers="(request-target) :scheme :authority 1914 date digest content-range", 1915 signature="MGUCMBgx6cuwTzg0W29zNUra8xfMsEcb3rFA3Y" 1917 Authors' Addresses 1919 Lucas Pardue 1920 BBC Research & Development 1922 Email: lucas.pardue@bbc.co.uk 1924 Richard Bradbury 1925 BBC Research & Development 1927 Email: richard.bradbury@bbc.co.uk