idnits 2.17.1 draft-pardue-quic-http-mcast-01.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 date (August 11, 2017) is 2449 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-07 == Outdated reference: A later version (-34) exists of draft-ietf-quic-http-04 == Outdated reference: A later version (-34) exists of draft-ietf-quic-recovery-04 == Outdated reference: A later version (-34) exists of draft-ietf-quic-tls-04 == Outdated reference: A later version (-34) exists of draft-ietf-quic-transport-04 ** 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) == Outdated reference: A later version (-04) exists of draft-krasic-quic-qcram-02 == Outdated reference: A later version (-07) exists of draft-bishop-quic-http-and-qpack-02 -- 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: 7 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 R. Bradbury 4 Intended status: Informational BBC Research & Development 5 Expires: February 12, 2018 August 11, 2017 7 Hypertext Transfer Protocol (HTTP) over multicast QUIC 8 draft-pardue-quic-http-mcast-01 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 February 12, 2018. 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 . . . . . . . . . . . . . . . . . . 13 69 3.5. Session Peak Flow Rate . . . . . . . . . . . . . . . . . 13 70 3.6. Resource Concurrency . . . . . . . . . . . . . . . . . . 13 71 3.7. Additional TransportParameter Considerations . . . . . . 14 72 3.8. Digest Algorithm . . . . . . . . . . . . . . . . . . . . 14 73 3.9. Signature Algorithm . . . . . . . . . . . . . . . . . . . 15 74 4. QUIC Profile . . . . . . . . . . . . . . . . . . . . . . . . 16 75 4.1. Packet Size . . . . . . . . . . . . . . . . . . . . . . . 16 76 4.2. Version Negotiation . . . . . . . . . . . . . . . . . . . 16 77 4.3. Connection Identifier . . . . . . . . . . . . . . . . . . 17 78 4.4. Stream Identifier . . . . . . . . . . . . . . . . . . . . 17 79 4.5. Flow Control . . . . . . . . . . . . . . . . . . . . . . 17 80 4.6. Stream Termination . . . . . . . . . . . . . . . . . . . 17 81 4.7. Session Shutdown . . . . . . . . . . . . . . . . . . . . 17 82 4.8. Session Keep-alive . . . . . . . . . . . . . . . . . . . 18 83 4.9. Loss Detection and Recovery . . . . . . . . . . . . . . . 18 84 4.10. Prohibited QUIC Frames and Packets . . . . . . . . . . . 18 85 5. HTTP/QUIC Profile . . . . . . . . . . . . . . . . . . . . . . 19 86 5.1. HTTP Connection Settings . . . . . . . . . . . . . . . . 19 87 5.2. Server Push . . . . . . . . . . . . . . . . . . . . . . . 19 88 5.3. Metadata Compression . . . . . . . . . . . . . . . . . . 20 89 5.4. Prioritisation . . . . . . . . . . . . . . . . . . . . . 20 90 5.5. Session Tear-down . . . . . . . . . . . . . . . . . . . . 20 91 5.6. HTTP/2 Extension frames . . . . . . . . . . . . . . . . . 20 92 5.7. Prohibited HTTP/2 Frames . . . . . . . . . . . . . . . . 21 93 6. Application-Layer Security . . . . . . . . . . . . . . . . . 21 94 6.1. Content Integrity . . . . . . . . . . . . . . . . . . . . 21 95 6.2. Content Authenticity . . . . . . . . . . . . . . . . . . 22 96 6.3. Content Confidentiality . . . . . . . . . . . . . . . . . 23 97 7. Loss Recovery . . . . . . . . . . . . . . . . . . . . . . . . 23 98 7.1. Forward Error Correction . . . . . . . . . . . . . . . . 23 99 7.2. Unicast Repair . . . . . . . . . . . . . . . . . . . . . 24 100 8. Transmission of Partial Content . . . . . . . . . . . . . . . 24 101 9. Protocol Identifier . . . . . . . . . . . . . . . . . . . . . 25 102 9.1. Draft Version Identification . . . . . . . . . . . . . . 25 103 10. Discovery of Multicast QUIC Sessions . . . . . . . . . . . . 25 104 10.1. Source-specific Multicast Advertisement . . . . . . . . 26 105 10.2. Session Parameter Advertisement . . . . . . . . . . . . 27 106 10.2.1. Version . . . . . . . . . . . . . . . . . . . . . . 27 107 10.2.2. Cipher Suite . . . . . . . . . . . . . . . . . . . . 27 108 10.2.3. Session Key . . . . . . . . . . . . . . . . . . . . 27 109 10.2.4. Session Cipher Initialization Vector . . . . . . . . 28 110 10.2.5. Session Identification . . . . . . . . . . . . . . . 28 111 10.2.6. Session Idle Timeout Period . . . . . . . . . . . . 28 112 10.2.7. Resource Concurrency . . . . . . . . . . . . . . . . 29 113 10.2.8. Session Peak Flow Rate . . . . . . . . . . . . . . . 29 114 10.2.9. Digest Algorithm . . . . . . . . . . . . . . . . . . 29 115 10.2.10. Signature Algorithm . . . . . . . . . . . . . . . . 30 116 11. Security and Privacy Considerations . . . . . . . . . . . . . 30 117 11.1. Pervasive Monitoring . . . . . . . . . . . . . . . . . . 31 118 11.1.1. Large-scale Data Gathering and Correlation . . . . . 31 119 11.1.2. Changing Content . . . . . . . . . . . . . . . . . . 31 120 11.2. Protection of Discovery Mechanism . . . . . . . . . . . 32 121 11.3. Spoofing . . . . . . . . . . . . . . . . . . . . . . . . 32 122 11.3.1. Spoofed Ack Attacks . . . . . . . . . . . . . . . . 32 123 11.3.2. Sender Spoofing . . . . . . . . . . . . . . . . . . 32 124 11.3.3. Receiver Spoofing . . . . . . . . . . . . . . . . . 32 125 11.4. Replay Attacks . . . . . . . . . . . . . . . . . . . . . 33 126 11.5. Message Deletion . . . . . . . . . . . . . . . . . . . . 33 127 11.6. Denial of Service . . . . . . . . . . . . . . . . . . . 33 128 11.6.1. Unprotected Frames and Packets . . . . . . . . . . . 33 129 11.6.2. Network Performance Degradation . . . . . . . . . . 34 130 11.6.3. Unicast Repair Stampeding Herd . . . . . . . . . . . 34 131 11.7. Receiver Resource Usage . . . . . . . . . . . . . . . . 34 132 11.8. Unicast Repair Information Leakage . . . . . . . . . . . 34 133 12. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 35 134 12.1. Registration of Protocol Identification String . . . . . 35 135 12.2. Registration of Alt-Svc parameters . . . . . . . . . . . 35 136 12.2.1. Source Address . . . . . . . . . . . . . . . . . . . 35 137 12.2.2. Cipher Suite . . . . . . . . . . . . . . . . . . . . 35 138 12.2.3. Key . . . . . . . . . . . . . . . . . . . . . . . . 36 139 12.2.4. Initialization Vector . . . . . . . . . . . . . . . 36 140 12.2.5. Session Identifier . . . . . . . . . . . . . . . . . 36 141 12.2.6. Session Idle Timeout . . . . . . . . . . . . . . . . 36 142 12.2.7. Maximum Concurrent Resources . . . . . . . . . . . . 36 143 12.2.8. Peak Flow Rate . . . . . . . . . . . . . . . . . . . 36 144 12.2.9. Digest Algorithm . . . . . . . . . . . . . . . . . . 36 145 12.2.10. Signature Algorithm . . . . . . . . . . . . . . . . 36 146 13. References . . . . . . . . . . . . . . . . . . . . . . . . . 37 147 13.1. Normative References . . . . . . . . . . . . . . . . . . 37 148 13.2. Informative References . . . . . . . . . . . . . . . . . 38 149 Appendix A. Acknowledgements . . . . . . . . . . . . . . . . . . 40 150 Appendix B. Examples . . . . . . . . . . . . . . . . . . . . . . 40 151 B.1. Session Advertisement . . . . . . . . . . . . . . . . . . 40 152 B.1.1. Source-specific Multicast QUIC Session . . . . . . . 40 153 B.1.2. Source-specific Multicast QUIC Session with Transport 154 Encryption using a Symmetric Key . . . . . . . . . . 41 155 B.1.3. Source-specific Multicast QUIC Session with Transport 156 Encryption, Content Integrity and Authenticity . . . 41 157 B.2. Resource Transfer . . . . . . . . . . . . . . . . . . . . 42 158 B.2.1. Transfer without Content Integrity or Authenticity . 42 159 B.2.2. Transfer of Partial Content without Content Integrity 160 or Authenticity . . . . . . . . . . . . . . . . . . . 42 161 B.2.3. Transfer with Content Integrity and without 162 Authenticity . . . . . . . . . . . . . . . . . . . . 43 163 B.2.4. Partial Transfer with Content Integrity and without 164 Authenticity . . . . . . . . . . . . . . . . . . . . 44 165 B.2.5. Transfer with Content Integrity and Authenticity . . 44 166 B.2.6. Partial Transfer with Content Integrity and 167 Authenticity . . . . . . . . . . . . . . . . . . . . 45 168 Appendix C. Changelog . . . . . . . . . . . . . . . . . . . . . 46 169 C.1. Since draft-pardue-quic-http-mcast-00 . . . . . . . . . . 46 170 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 47 172 1. Introduction 174 The means to bulk transfer resources over multicast IP [RFC1112] 175 using HTTP semantics presents an opportunity to more efficiently 176 deliver services at scale, while leveraging the wealth of existing 177 HTTP-related standards, tools and applications. Audio-visual 178 segmented media, in particular, would benefit from this mode of 179 transmission. 181 The carriage of HTTP over multicast IP may be satisfied using 182 existing technologies, for example the Real-time Transport Protocol 183 (RTP) [RFC3550]. However, such protocols typically require the 184 translation or encapsulation of HTTP. This introduces concerns for 185 providers of services, such as defining the translation, additional 186 workload, complication of workflows, manageability issues, versioning 187 issues, and so on. 189 In contrast, this document describes a simpler and more direct 190 expression of HTTP semantics over multicast IP. HTTP over multicast 191 QUIC is a profile of the QUIC protocol [QUIC-TRANSPORT] (Section 4) 192 and the HTTP/QUIC mapping [QUIC-HTTP] (Section 5). This includes the 193 repurposing of certain QUIC packet fields and changes to some 194 protocol procedures (e.g. prohibition of the usage of certain frame 195 types) which, in turn, change the behavioural expectations of 196 endpoints. However, the profile purposely limits the scope of change 197 in order to preserve maximum compatibility with conventional QUIC. 199 This profile prohibits the transmission of QUIC packets from receiver 200 to sender via multicast IP. The use of side-channel or out-of-band 201 feedback mechanisms is not prohibited by this specification, but is 202 out of scope and these are not considered further by the present 203 document. 205 Experience indicates that a generally available multicast deployment 206 is difficult to achieve on the Internet notwithstanding the 207 improvements that IPv6 [RFC2460] makes in this area. There is 208 evidence that discretely referenced multicast "islands" can more 209 pragmatically be deployed. Discovery of such islands by receivers, 210 as they become available, is typically difficult, however. To 211 address the problem, this document describes an HTTP-based discovery 212 mechanism that uses HTTP Alternative Services [RFC7838] to advertise 213 the existence of multicast QUIC sessions (Section 3). This provides 214 the means for multicast-capable endpoints to learn about and make use 215 of them in an opportunistic and user-imperceptible manner. This 216 mechanism results in a common HTTP application layer for both the 217 discovery and delivery of services across unicast and multicast 218 networks. This provides support for users and devices accessing 219 services over a heterogeneous network. This is a departure from 220 conventional multicast discovery technologies such as SDP [RFC4566] 221 and SAP [RFC2974]. 223 The discovery mechanism also addresses some of the issues related to 224 using QUIC over a unidirectional network association by replacing 225 connection establishment aspects that depend on a bidirectional 226 transport. 228 The present document includes a number of optional features. It is 229 anticipated that further specifications will define interoperability 230 profiles suited to particular application domains. 232 1.1. Notational Conventions 234 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 235 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 236 document are to be interpreted as described in [RFC2119]. 238 This document uses the Augmented BNF defined in [RFC5234] and updated 239 by [RFC7405] along with the "#rule" extension defined in Section 7 of 241 [RFC7230]. The rules below are defined in [RFC5234], [RFC7230], and 242 [RFC7234]: 244 o quoted-string = 246 o token = 248 o uri-host = 250 1.2. Definitions 252 Definitions of terms that are used in this document: 254 o endpoint: A host capable of being a participant in a multicast 255 QUIC session. 257 o multicast QUIC session: A logical unidirectional flow of metadata 258 and data over multicast IP, framed according to this 259 specification. The lifetime of a session is independent of any 260 endpoint. 262 o participant: A sender or receiver that is taking part in a 263 multicast QUIC session. 265 o sender: A participant sending multicast traffic according to this 266 specification. 268 o receiver: A participant receiving multicast traffic according to 269 this specification. 271 o session: See multicast QUIC session. 273 o session ID: The identifier for a multicast QUIC session. 275 o session parameter: Characteristic of a multicast QUIC session. 277 2. Multicast QUIC Sessions 279 An HTTP/QUIC connection [QUIC-TRANSPORT] carried over bidirectional 280 unicast is defined as a conversation between two QUIC endpoints that 281 multiplexes several logical streams within a single encryption 282 context. This is a one-to-one relationship. Furthermore, QUIC 283 connections achieve decoupling from the underlying network (IP and 284 port) by means of a Connection ID. Use of a consistent connection 285 identifier allows QUIC connections to survive changes to the network 286 connectivity. The establishment of a QUIC connection relies upon an 287 up-front, in-band exchange (and possible negotiation) of 288 cryptographic and transport parameters (conveyed in QUIC handshake 289 messages) and HTTP-specific settings (conveyed in "SETTINGS" HTTP/2 290 frames). Such parameters may be required or optional and may be used 291 by either endpoint to control the characteristics of connection 292 usage. 294 This concept of a connection does not suit the carriage of HTTP/QUIC 295 over unidirectional network associations such as multicast IP. In 296 fact, there is no requirement for either endpoint (multicast sender 297 or receiver) to be in existence in order for the other to start or 298 join this one-sided conversation. The term "connection" is 299 misleading in this context; therefore we introduce an alternative 300 term "multicast QUIC session" or simply "session", which is defined 301 as the logical entity describing the characteristics of the 302 anticipated unidirectional flow of metadata and data. Such 303 characteristics are expressed as "session parameters", described in 304 Section 2.2. Advertisement of multicast QUIC sessions, specified in 305 Section 3, allows for the senders and receivers to discover a session 306 and to form multicast IP network associations that permit traffic 307 flow. 309 2.1. Session States 311 The lifecycle of a multicast QUIC session is decoupled from the 312 lifecycle of any particular endpoint. Multicast receivers or senders 313 that take part in a session are called participants. The state of a 314 session is influenced by the actions of participants. The loose 315 coupling of participants means that they are unlikely to have a 316 consistent shared view of the current state of a session. There is 317 no requirement for a participant to know the session state and the 318 present document does not define a method to explicitly determine it. 319 The definitions of session states provided below are intended to 320 assist higher-level operational treatment of sessions: 322 o Quiescent: the session has no participants and is ready to accept 323 them. 325 o Half-established: the session has a participant. 327 o Fully-established: the session has a sender and at least one 328 receiver participant. 330 o Finished: the session has ended, and there are no participants. 332 Permitted states transitions are shown in Figure 1 below. 334 The transmission of QUIC packets is expected to occur only during the 335 Half-Established and Fully-Established states. 337 +-----------+ +------------------+ +-------------------+ 338 | |-------->| |------->| | 339 | Quiescent | | Half-Established | | Fully-Established | 340 | |<--------| |<-------| | 341 +-----------+ +------------------+ +-------------------+ 342 | | 343 | v 344 | +----------+ 345 | | | 346 +------------------>| Finished | 347 | | 348 +----------+ 350 Figure 1: Multicast QUIC session states 352 2.1.1. Session Establishment 354 A session begins in the Quiescent state. A typical session 355 establishment sequence would see the transition from Quiescent to 356 Half-Established when a sender joins the session. The transition 357 from Half-Established to Fully-Established occurs when at least one 358 receiver joins the session. 360 It is equally valid for a receiver to join a session in the Quiescent 361 state, triggering the transition to Half-Established. In this case, 362 the transition to Fully-Established takes place only when a sender 363 joins the session. 365 2.1.2. Session Termination 367 A session enters the Finished state when all participants leave it. 368 The methods for leaving a session are either explicit shutdown 369 (Section 5.5), implicit shutdown (i.e. idle timeout, Section 3.4) or 370 migration away (described in the next section). 372 In a typical case, a session that is in the Fully-Established state 373 would be closed in two stages. In the first stage the sender sends 374 explicit shutdown messages to the multicast group and subsequently 375 stops transmitting packets. This causes the session to transition 376 from Fully-Established to Half-Established. In the second stage, 377 receivers that have received explicit shutdown messages leave the 378 multicast group. Once all receivers have left the session it 379 transitions from Half-Established to Finished. 381 The transition from Quiescent to Finished could also occur in 382 response to out-of-band actions, for example the availability of a 383 session being withdrawn without any participants having made use of 384 it. 386 2.1.3. Session Migration 388 Endpoints MAY migrate between multicast QUIC sessions (for example, 389 to make use of alternate session parameters that are preferred). 390 Session migration requires participants to leave the current session 391 and join the new session. These actions affect the state of the 392 respective sessions as explained above. 394 The discovery of multicast QUIC sessions is described in Section 3. 396 2.2. Session Parameters 398 The characteristics of multicast QUIC sessions are expressed as 399 session parameters, which cover cryptographic and transport 400 parameters, HTTP-specific settings and multicast-specific 401 configuration. 403 Session parameter exchange over IP multicast is difficult: 405 o In-band exchanges are one-way, and so the client does not have the 406 means to send session parameters. 408 o The lifecycle of any multicast sender is independent of the 409 multicast receiver. It is therefore unlikely that all receivers 410 will have joined a session in time to receive parameters sent at 411 the start of a multicast session. 413 A range of strategies exists to mitigate these points. However, each 414 has the possibility to add complexity to deployment and 415 manageability, transmission overhead, or other such concerns. This 416 document defines a solution that relies on the one-way announcement 417 of session parameters in advance of session establishment. This is 418 achieved using HTTP Alternative Services [RFC7838] and is explained 419 in Section 3. Other advertisement solutions are not prohibited but 420 are not explored in this document. 422 Session parameters MUST NOT change during the lifetime of a session. 423 This restriction also applies to HTTP-level settings (see 424 Section 5.1). 426 2.3. Session Identification 428 This document defines a 64-bit session identifier used to identify a 429 session. This "Session ID" affords independence from multicast IP, 430 creating the possibility for a session to span multiple multicast 431 groups, or to migrate a session to a different multicast group. 432 Assignment of Session ID is considered out of this document's scope. 434 The Session ID is carried in the Connection ID field of the QUIC 435 packet (see Section 4.3). 437 A multicast sender participating in a session MUST send QUIC packets 438 with a matching Session ID. A multicast receiver participating in a 439 session MUST validate that the Session ID of received QUIC packets 440 matches that advertised in the session parameters (Section 3, 441 Section 10.2) before any HTTP-level processing is done. In the case 442 of validation failure, the receiver SHOULD ignore the packet in order 443 to protect itself from denial-of-service attacks. 445 2.4. Session Security 447 *Authors' Note:* Security handshake (as described in WG documents) 448 is in flux. This section will track developments and will be 449 updated accordingly. 451 The QUIC Crypto and Transport handshake (see [QUIC-TRANSPORT], 452 [QUIC-TLS] and [QUICCrypto]) sets out methods to achieve the goals of 453 authenticated key exchange and record protection between two 454 endpoints forming a QUIC connection. The design facilitates low- 455 latency connection; 1-RTT or 0-RTT. The Crypto handshake [QUIC-TLS] 456 reserves QUIC stream 0 for TLS handshake messages. 458 This specification replaces the in-band security handshake, achieving 459 similar goals through the use of session parameters described in 460 Section 3.2. For the purpose of compatibility, the use of QUIC 461 stream 0 (see Section 4.4) is reserved. 463 Integrity and authenticity concerns are addressed in Section 6.1 and 464 Section 6.2 respectively. In order to protect themselves from attack 465 vectors, endpoints SHOULD NOT participate in sessions for which they 466 cannot establish reasonable confidence over the cipher suite or key 467 in use for that session. Participants MAY leave any session that 468 fails to successfully match anticipated security characteristics. 470 3. Session Advertisement 472 In this specification, connection negotiation is replaced with a 473 session advertisement mechanism based on HTTP Alternative Services 474 (Alt-Svc) [RFC7838]. This document specifies how the parameters of a 475 multicast QUIC session are expressed as Alt-Svc parameters. The 476 following sections provide a high-level view of these; further 477 details are provided in Section 10.2, with examples provided in 478 Appendix B.1. QUIC connection parameters not defined as, or related 479 to, Alt-Svc parameters are not used. 481 The definition of a session (including the session ID and its 482 parameters) is not the responsibility of any endpoint. Rather, 483 endpoints SHOULD use session advertisements to determine if they are 484 capable of participating in a given session. This document does not 485 specify which party is responsible for defining and/or advertising 486 multicast QUIC sessions. 488 The freshness of Alt-Svc multicast QUIC session advertisements is as 489 described in section 2.2 of [RFC7838]. 491 It is RECOMMENDED that session advertisements are carried over a 492 secure transport (such as HTTPS) which can guarantee the authenticity 493 and integrity of the Alt-Svc information. This addresses some of the 494 concerns around the protection of session establishment described in 495 Section 11.2. 497 *Authors' Note:* We invite review comments on mandating the use of 498 a secure transport for advertising sessions. 500 Senders MAY also advertise the availability of alternative sessions 501 by carrying Alt-Svc in a multicast QUIC session. 503 3.1. Version Advertisement 505 *Authors' Note:* Version negotiation (as described in WG 506 documents) is in flux. This section will track developments and 507 will be updated accordingly. 509 Conventional QUIC connection establishment begins with version 510 negotiation. In a unidirectional multicast environment, there is no 511 reasonable way to negotiate in such a manner. [QUIC-HTTP] defines an 512 Alt-Svc "quic" parameter that can be advertised to clients for use as 513 a version negotiation hint. This specification uses "quic" as a 514 session parameter for a similar purpose but with the additional 515 constraint that the parameter MUST appear exactly once: it is not 516 optional and the parameter MUST NOT be repeated. 518 This mechanism replaces the use of the Version field in the QUIC 519 packet long header (see Section 4.2). 521 A multicast sender participating in a session MUST send QUIC packets 522 and frames in the format corresponding to the advertised version. If 523 the sender does not support the advertised version it MUST NOT send 524 any data. A receiver MUST NOT join a session where the "quic" 525 parameter is absent. A receiver SHOULD NOT join a session for which 526 it does not support the advertised version, in order to avoid wasting 527 processing resources. 529 3.2. Security Context 531 *Authors' Note:* Security handshake (as described in WG documents) 532 is in flux. This section will track developments and will be 533 updated accordingly. 535 This specification replaces the in-band security handshake: 537 o Cipher suite negotiation is replaced with a "cipher suite" session 538 parameter, which is advertised as the Alt-Svc parameter "cipher- 539 suite" (Section 10.2.2). If present, this parameter MUST contain 540 only one value that corresponds to an entry in the TLS Cipher 541 Suite Registry (see http://www.iana.org/assignments/tls- 542 parameters/tls-parameters.xhtml#tls-parameters-4). If absent, the 543 multicast QUIC session is assumed to be operating with cipher 544 suite 0x00,0x00 (NULL_WITH_NULL_NULL). 546 o Key exchange is replaced with a "key" session parameter, which is 547 advertised as the Alt-Svc parameter "key" (Section 10.2.3). The 548 parameter carries a variable-length hex-encoded key for use with 549 the session cipher suite. In the absence of the "key" parameter, 550 the key may be available via an out-of-band method not described 551 in this document. 553 o Initialization Vector (IV) exchange is replaced with an "iv" 554 session parameter, which is advertised as the Alt-Svc parameter 555 "iv" (Section 10.2.4). The parameter carries a variable-length 556 hex-encoded IV for use with the session cipher suite and key. In 557 the absence of the "iv" parameter, the IV may be available via an 558 out-of-band method not described in this document. 560 In order to protect themselves, endpoints SHOULD NOT participate in 561 sessions for which they cannot establish reasonable confidence over 562 the cipher suite or key in use for that session. Endpoints SHOULD 563 leave any sessions which fail to successfully match anticipated 564 security characteristics. 566 3.3. Session Identification 568 [QUIC-TRANSPORT] specifies how the QUIC Connection ID is used, in 569 particular the client-side generation of this value. In a 570 unidirectional multicast environment, there is no meaningful way for 571 a client to generate a Connection ID and use it. This document 572 defines a "session identifier" session parameter, which is advertised 573 as the Alt-Svc parameter "session-id" (Section 10.2.5). The 574 requirements for the usage of session identifiers have already been 575 described in Section 2.3. 577 3.4. Session Idle Timeout 579 Conventional QUIC connections may be implicitly terminated following 580 a period of idleness (lack of network activity). The required QUIC 581 TransportParameter "idle_timeout" provides a means for endpoints to 582 specify the timeout period. This document defines a "session idle 583 timeout" session parameter, which is advertised as the Alt-Svc 584 parameter "session-idle-timeout" (Section 10.2.6). This session 585 parameter mimics the behaviour of "idle_timeout", providing a means 586 for multicast QUIC sessions to define their own idle timeout periods. 588 Session advertisements that omit the Alt-Svc parameter "session-idle- 589 timeout" imply that the default timeout period is in use. The 590 default value is 30 seconds. 592 Receiving participants SHOULD leave multicast QUIC sessions when the 593 session idle timeout period has elapsed (Section 4.7). Leaving 594 participants MUST use the silent close method, in which no 595 "CONNECTION_CLOSE" QUIC frame is sent. 597 3.5. Session Peak Flow Rate 599 [QUIC-TRANSPORT] specifies a credit-based stream- and connection- 600 level flow control scheme which prevents a fast sender from 601 overwhelming a slow receiver. Window size connection parameters are 602 exchanged on connection establishment using the required QUIC 603 TransportParameters "initial_max_data" and "initial_max_stream_data". 604 In a unidirectional multicast environment, such a scheme is 605 infeasible. This document defines a "peak flow rate" session 606 parameter, expressed in units of bits per second, which is advertised 607 as the Alt-Svc parameter "peak-flow-rate" (Section 10.2.8). This 608 replaces "initial_max_data" and "initial_max_stream_data" completely, 609 instead indicating the maximum bit rate of "STREAM" QUIC frame 610 payloads transmitted on all multicast groups comprising the session. 612 Session advertisements that omit the Alt-Svc parameter "peak-flow- 613 rate" imply that the flow rate is unlimited. 615 A multicast sender SHOULD NOT cause the advertised peak flow rate of 616 a session to be exceeded. A receiver MAY leave any session where the 617 advertised peak flow rate is exceeded. 619 3.6. Resource Concurrency 621 [QUIC-TRANSPORT] considers concurrency in terms of the number of 622 active incoming streams, which is varied by the receiving endpoint 623 adjusting the maximum stream ID. The initial value of maximum stream 624 ID is controlled by the required QUIC TransportParameter 625 "initial_max_stream_id". It is increased during the lifetime of a 626 QUIC connection by the "MAX_STREAM_ID" QUIC frame. In a 627 unidirectional multicast environment, there is no way for a receiver 628 to specify the limit nor increase it. Therefore the maximum stream 629 ID mechanism is not used to manage concurrency in multicast QUIC. 630 The "STREAM_ID_NEEDED" QUIC frame MAY be sent by a sending 631 participant but it will have no effect. This frame SHALL be ignored 632 by receiving participants. 634 This document specifies a "maximum concurrent resources" session 635 parameter, which is advertised as the Alt-Svc parameter "max- 636 concurrent-resources" (Section 10.2.7). This parameter replaces 637 "initial_max_stream_id". It advertises the maximum number of 638 concurrent active resources generated by a sender in a given 639 multicast QUIC session. 641 Session advertisements that omit the Alt-Svc parameter "maximum 642 concurrent resources" imply that the maximum concurrency is 643 unlimited. 645 A multicast sender participating in a session MUST NOT cause the 646 advertised "max-concurrent-resources" to be exceeded. A receiver MAY 647 leave any session where the advertised limit is exceeded, in order to 648 protect itself from denial-of-service attacks. 650 3.7. Additional TransportParameter Considerations 652 *Authors' Note:* Google QUIC Connection Options (COPTs) are no 653 longer referred to in WG documents. This section will consider 654 TransportParameters, tracking developments and issues that may 655 arise. 657 3.8. Digest Algorithm 659 A method to provide content integrity is described in Section 6.1. 660 This specifies the means to convey a value computed by a particular 661 digest algorithm. The identity of the selected algorithm is also 662 indicated. Valid digest algorithms are collected in the IANA HTTP 663 Digest Algorithm Values registry (http://www.iana.org/assignments/ 664 http-dig-alg/http-dig-alg.xhtml#http-dig-alg-1). 666 This document specifies a "digest algorithm" session parameter, which 667 is advertised as the Alt-Svc parameter "digest-algorithm" 668 (Section 10.2.9). 670 *Authors' Note:* Section 6.1 contains an author's note on the 671 potential for content integrity to become mandatory. This section 672 will be updated in line with the outcome of that decision. 674 Repetition of the "digest algorithm" parameter in a single 675 advertisement describes an algorithm set that MAY be used across the 676 session. Session advertisements that omit the Alt-Svc parameter 677 "digest-algorithm" imply that either: 679 o the session does not use the content integrity mechanism, or 681 o the algorithm set is unrestricted, i.e. a sender may vary the 682 algorithm as it so chooses. This may lead to undesirable results 683 if receivers do not support a chosen algorithm. 685 Advertising the algorithm set for a session gives receivers the 686 opportunity to selectively join sessions where the algorithms are 687 known to be supported. This may help to mitigate latency issues in 688 the receiver resulting from joining a session only to discover some 689 of its parameters are not supported. 691 A multicast sender participating in a session MUST NOT use algorithms 692 outside the signalled digest algorithm set. A receiver MAY leave any 693 session where an algorithm outside the digest algorithm set is used. 695 3.9. Signature Algorithm 697 A method to provide content authenticity is described in Section 6.2. 698 This specifies the means to convey a value computed by a particular 699 signature algorithm. The identity of the selected algorithm is also 700 indicated. Valid signature algorithms are collected in the IANA 701 Signature Algorithms registry (http://www.iana.org/assignments/ 702 signature-algorithms). 704 This document specifies a "signature algorithm" session parameter, 705 which is advertised as the Alt-Svc parameter "signature-algorithm" 706 (Section 10.2.10). 708 *Authors' Note:* Section 6.2 contains an author's note on the 709 potential for content authenticity to become mandatory. This 710 section will be updated in line with the outcome of that decision. 712 Repetition of the "signature algorithm" parameter in a single 713 advertisement describes an algorithm set that MAY be used across the 714 session. Session advertisements that omit the Alt-Svc parameter 715 "signature-algorithm" imply that either: 717 o the session does not use the content authenticity mechanism, or 719 o the algorithm set is unrestricted i.e. a sender may vary the 720 algorithm as it so chooses. This may lead to undesirable results 721 if receivers do not support a chosen algorithm. 723 Advertising the algorithm set for a session gives receivers the 724 opportunity to selectively join sessions where the algorithms are 725 known to be supported. This may help to mitigate latency issues in 726 the receiver resulting from joining a session only to discover some 727 of its parameters are not supported. 729 A multicast sender participating in a session MUST NOT use algorithms 730 outside the signalled signature algorithm set. A receiver MAY leave 731 any session where an algorithm outside the signature algorithm set is 732 used. 734 4. QUIC Profile 736 *Authors' Note:* The QUIC transport document is subject to change. 737 This section is based on our best understanding of draft-ietf- 738 quic-transport-04. The authors will track developments and will 739 update this section accordingly. 741 The profile of [QUIC-TRANSPORT] is presented in this section. In 742 order to preserve compatibility with conventional QUIC, the 743 specification works with a limited scope of change. However, the 744 nature of unidirectional multicast communications means that some 745 protocol procedures or behaviours need to be modified. 747 4.1. Packet Size 749 The means for determining an appropriate size for QUIC packets are 750 described in Section 9 of [QUIC-TRANSPORT]. Implementations of this 751 specification SHOULD bear in mind that the Path Maximum Transmission 752 Unit (PTMU) may be affected by multicast IP technologies such as 753 Automatic Multicast Tunneling (AMT) [RFC7450]. Additionally, 754 consideration should be given toward the applicability of maximum 755 transmission unit discovery methods (such as PLPMTUD [RFC4821] and 756 PMTUD [RFC1191]) to multicast IP. 758 4.2. Version Negotiation 760 Endpoints implementing this specification MUST only send QUIC packets 761 with the short header format. This header format omits a Version 762 field. 764 *Authors' Note:* The authors welcome suggestions for conveying the 765 QUIC version in every multicast QUIC packet. 767 4.3. Connection Identifier 769 The Connection ID field MUST be present in every QUIC packet, and the 770 corresponding flag in the packet header MUST be set to indicate that 771 the Connection ID field is present. 773 4.4. Stream Identifier 775 Senders MUST NOT send any QUIC frames on QUIC stream 0. Receivers 776 MUST ignore QUIC frames received on stream 0. 778 4.5. Flow Control 780 Conventional QUIC provides stream- and connection-level flow control, 781 and endpoints manage this by sending "MAX_DATA" or "MAX_STREAM_DATA" 782 QUIC frames as required. When a sender is blocked from sending flow- 783 controlled frames, it sends an informational "BLOCKED" or 784 "STREAM_BLOCKED" QUIC frame. 786 In a unidirectional environment, the sender never has a receive 787 window and the receiver cannot send in-band updates. Therefore, the 788 management of flow-control windows and transmission of blockage 789 information is not supported by this profile. The "MAX_DATA", 790 "MAX_STREAM_DATA", "BLOCKED" and "STREAM_BLOCKED" QUIC frames are 791 prohibited by this profile. Participants MUST NOT send these frame 792 types. Reception of these frame types MUST be handled as described 793 in Section 4.10. 795 4.6. Stream Termination 797 A sender MAY prematurely terminate the transmission on any unreserved 798 QUIC stream ID by setting the "FIN" bit of a "STREAM" QUIC frame, or 799 by sending a "RST_STREAM" QUIC frame (as specified in 800 [QUIC-TRANSPORT] and [QUIC-HTTP]). 802 Receiving participants MUST NOT make any attempt to send "RST_STREAM" 803 to the multicast group. 805 4.7. Session Shutdown 807 Explicit shutdown of a multicast QUIC session using QUIC methods is 808 not supported by this profile. The "GOAWAY" and "CONNECTION_CLOSE" 809 QUIC frames, and the Public Reset packet are prohibited. 810 Participants MUST NOT send these and reception MUST be handled as 811 described in Section 4.10. 813 Explicit session tear-down using HTTP semantics is allowed, as 814 described in Section 5.5. 816 Implicit shutdown by means of silent close is also supported, as 817 described in Section 3.4. 819 4.8. Session Keep-alive 821 The flow of traffic in a multicast QUIC session is driven by a 822 sender. There may be periods where the sender has no data to send 823 for a period longer than the session idle timeout. This profile 824 repurposes the "PING" QUIC frame to act as a unidirectional keep- 825 alive message that may be sent in order to inform receivers that the 826 session should remain in the Fully-established state. 828 Senders MAY send a "PING" frame at any time in order to inform 829 receivers that the session traffic flow has not fallen idle. This 830 frame MUST NOT be acknowledged. (Indeed "ACK" frames are banned by 831 Section 4.9.) 833 Receiving participants MUST NOT make any attempt to send "PING" 834 frames. 836 4.9. Loss Detection and Recovery 838 Receivers implementing this profile MUST NOT make any attempt to 839 acknowledge the reception of QUIC packets. The "ACK" QUIC frame is 840 prohibited for both senders and receivers. Reception of this frame 841 MUST be handled as described in Section 4.10. 843 Section 7 specifies alternative strategies for loss recovery. 845 4.10. Prohibited QUIC Frames and Packets 847 The following QUIC packets MUST NOT be transmitted by participants: 848 0-RTT Protected, 1-RTT Protected (key phase 0), 1-RTT Protected (key 849 phase 1), Client Cleartext, Client Initial, Public Reset, Server 850 Cleartext, Server Initial, Version Negotiation. 852 The following QUIC frames MUST NOT be transmitted by participants: 853 "ACK", "BLOCKED", "CONNECTION_CLOSE", "GOAWAY", "MAX_DATA", 854 "MAX_STREAM_DATA", "STREAM_BLOCKED". 856 The following QUIC frames MUST NOT be transmitted by receivers: 857 "RST_STREAM". 859 Reception of a prohibited QUIC frame or packet is a protocol error. 860 Receivers MUST ignore all prohibited QUIC frames and packets. 862 5. HTTP/QUIC Profile 864 *Authors' Note:* The HTTP/QUIC mapping document is subject to 865 change. This section is based on our best understanding of draft- 866 ietf-quic-http-04. The authors will track developments and will 867 update this section accordingly. 869 HTTP over multicast QUIC depends on HTTP server push, as described in 870 Section 4.4 of [QUIC-HTTP]. Section 5.2 below applies an additional 871 constraint on the use of server push. A multicast sender 872 participating in a session pushes resources as a series of "STREAM" 873 QUIC frames carrying HTTP/2 "PUSH_PROMISE", "HEADERS" and body data. 874 Examples of this are provided in Appendix B.2. Senders MUST comply 875 with the requirements of the session parameters, as described earlier 876 in Section 3. 878 The profile of HTTP/QUIC specified in this section places additional 879 constrains on the use of metadata compression (Section 5.3) and 880 prioritisation (Section 5.4). 882 5.1. HTTP Connection Settings 884 The "SETTINGS" HTTP/2 frame is prohibited by this profile. 885 Participants MUST NOT make any attempt to send this frame type. 886 Reception of this frame MUST be handled as described in Section 5.7. 888 5.2. Server Push 890 Server push is, by default, enabled for HTTP/QUIC connections. A 891 conventional HTTP/QUIC client may disable server push via a 892 "SETTINGS" HTTP/2 frame but the use of that frame is prohibited by 893 this profile (Section 5.1). This profile mandates the use of server 894 push, and specifies no means to disable it. 896 Conventionally, pushed responses are associated with an explicit 897 request from a client. This is not possible when using a 898 unidirectional transport such as multicast IP. This profile reserves 899 the HTTP/2 stream ID that would normally be used for the first client 900 request. "PUSH_PROMISE" frames MUST reference this reserved ID. 902 *Authors' Note:* The exact value of this stream ID is currently in 903 flux. This section will track developments and will be updated 904 accordingly. 906 5.3. Metadata Compression 908 The compression of HTTP header fields is considered in HPACK 909 [RFC7541], which describes two methods for the compression of HTTP 910 header fields: indexing (via static or dynamic tables) and Huffman 911 encoding. 913 A multicast QUIC session, as described in the present document, does 914 not provide the assurances (receiver participation, transport 915 reliability) required to sufficiently maintain the dynamic decoding 916 context. Therefore, this document requires that endpoints SHALL NOT 917 use dynamic indexing. It is RECOMMENDED that endpoints use static 918 indexing and/or Huffman encoding in order to benefit from the 919 remaining compression methods available. 921 *Authors' Note:* In the context of QUIC, changes to HPACK may 922 allow for better leverage of the transport. QPACK [QPACK] and 923 [QCRAM] are active proposals in this space. This section will 924 track developments and will be updated accordingly. 926 5.4. Prioritisation 928 The "PRIORITY" HTTP/2 frame is prohibited by this profile. 929 Participants MUST NOT make any attempt to send this frame type. 930 Reception of this frame MUST be handled as described in Section 5.7. 932 5.5. Session Tear-down 934 A multicast QUIC session MAY be explicitly torn down by means of the 935 "Connection: close" HTTP header described in section 6.6 of 936 [RFC7230]. A sender intending to leave the session SHOULD include 937 the "Connection: close" header in its response metadata. A sender 938 SHOULD transmit all outstanding frames related to remaining request/ 939 response exchanges before ending transmission to the multicast group. 940 A receiver SHOULD continue to receive and process frames until all 941 outstanding request/response exchanges are complete. 943 5.6. HTTP/2 Extension frames 945 HTTP/2 extension frames (e.g. "ALTSVC") are prohibited by this 946 profile. Participants MUST NOT make any attempt to send extension 947 frame types. Reception of these MUST be handled as described in 948 Section 5.7. 950 5.7. Prohibited HTTP/2 Frames 952 The following HTTP/2 frames MUST NOT be transmitted by participants: 953 "PRIORITY", "SETTINGS". 955 In addition, all HTTP/2 extension frame types MUST NOT be transmitted 956 by participants. 958 Reception of a prohibited HTTP/2 frame is a protocol error. 959 Receivers MUST ignore prohibited HTTP/2 frames. 961 6. Application-Layer Security 963 As already described in Section 3.2, the implicit cipher suite used 964 by a multicast QUIC session makes very limited provision for security 965 in the transport and session layers. This section profiles the use 966 of some additional features to provide equivalent functionality at 967 the application-layer. 969 6.1. Content Integrity 971 In many applications, it is important to ensure that an HTTP 972 representation has been received intact (i.e. has not suffered from 973 transmission loss or random bit errors) before passing the received 974 object on to the receiving application. A mechanism is therefore 975 specified here to provide end-to-end content integrity protection for 976 HTTP representations in transit. The use of this content integrity 977 mechanism is RECOMMENDED. 979 *Authors' Note:* We invite review comments on mandating the use of 980 this content integrity mechanism. 982 [RFC3230] specifies an instance digest HTTP header called "Digest". 983 A sender MAY include this header in the "HEADERS" frame of any 984 representation it transmits and a receiver MAY use this header to 985 validate the integrity of the received representation once it has 986 been reassembled. Where this validation fails, the receiver SHOULD 987 discard the representation without processing it further. 989 Note that the digest value protects a whole HTTP instance (i.e. the 990 representation of a resource at the point of transmission as opposed 991 to the body of a particular HTTP message). In cases where partial 992 representations are fragmented over one or more HTTP response 993 messages, the digest value is computed over the complete 994 representation prior to fragmentation into partial responses. 996 In cases where the complete representation is not available at the 997 start of multicast transmission, the "Digest" header MAY be conveyed 998 as a trailing header field after the body data of the representation, 999 in accordance with Section 8.1 of [RFC7540]. 1001 Any of the algorithms specified in the IANA registry of digest 1002 algorithms (http://www.iana.org/assignments/http-dig-alg/http-dig- 1003 alg.xhtml#http-dig-alg-1) MAY be used in conjunction with the 1004 "Digest" header. There is no requirement for participants to support 1005 the full set of algorithms. 1007 6.2. Content Authenticity 1009 In some applications, it is important for a receiver to reassure 1010 itself that an HTTP representation has been received from an 1011 authentic source. It is also sometimes useful for a receiver to know 1012 that the information has not been tampered with in transit by a 1013 malicious intermediate actor. A mechanism is therefore specified 1014 here to prove the authenticity of HTTP messages in transit. The use 1015 of this content authenticity mechanism is RECOMMENDED for senders 1016 implementing this specification. 1018 *Authors' Note:* We invite review comments on mandating the use of 1019 this content authenticity mechanism. 1021 [I-D.cavage-http-signatures] specifies a means of securely signing 1022 metadata associated with any HTTP message. The resulting digital 1023 signature is conveyed in the "Signature" header of the message 1024 itself. The "Signature" header also conveys a list of HTTP header 1025 fields over which the signature was computed. A receiver MAY verify 1026 the "Signature" header in order to validate the authenticity of 1027 received metadata. Where this validation fails, the receiver SHOULD 1028 discard or ignore any related metadata and/or data without processing 1029 it further. 1031 Note that the signature proves the authenticity of the metadata in a 1032 single HTTP message. A "Signature" header MAY be included separately 1033 in the "PUSH_PROMISE" frame (protecting the request metadata) and in 1034 the final (or only) "HEADERS" frame relating to a particular resource 1035 (protecting the response metadata). In order to provide an 1036 additional level of protection, however, it is RECOMMENDED that the 1037 signature be computed over the combined request metadata (from the 1038 "PUSH_PROMISE" frame) and the corresponding response metadata (from 1039 the "HEADERS" frames) of the same resource. This binds the request 1040 metadata and response metadata together, providing the receiver with 1041 additional reassurance of authenticity. In this latter case, the 1042 combined digital signature SHALL be conveyed in the final (or only) 1043 "HEADERS" frame. 1045 In cases where not all metadata is known at the start of 1046 transmission, the "Signature" header MAY be conveyed as a trailing 1047 header field after the body data of the representation, in accordance 1048 with Section 8.1 of [RFC7540]. 1050 In applications where the detection of replay attacks is a 1051 requirement, it is RECOMMENDED that the "Date" header be included in 1052 the scope of the signature. It is RECOMMENDED that receivers use the 1053 value of the "Date" header for replay detection using appropriate 1054 strategies (e.g. checking for freshness). The definition of such 1055 strategies is beyond the scope of this document. 1057 In applications where the authenticity and integrity of the 1058 transmission are both important, it is RECOMMENDED that the "Digest" 1059 header specified in Section 6.1 above is included in the scope of the 1060 signature. By signing the instance digest, the authenticity and 1061 integrity of the HTTP message body are also assured in addition to 1062 that of the metadata. 1064 Any of the algorithms specified in the IANA registry of signature 1065 algorithms (http://www.iana.org/assignments/signature-algorithms) MAY 1066 be used in conjunction with the "Signature" header. There is no 1067 requirement for participants to support the full set of algorithms. 1069 6.3. Content Confidentiality 1071 In applications where there is a requirement for the content itself 1072 to remain confidential, appropriate steps SHOULD be taken to protect 1073 the application payload, for example by encrypting it. This document 1074 does not preclude the use of application-level encryption, but does 1075 not specify a mechanism for the distribution of content decryption 1076 keys. 1078 7. Loss Recovery 1080 Because the acknowledgement of received packets to multicast groups 1081 is prohibited by this specification (Section 4.9) the detection of 1082 discarded or corrupted packets is the sole responsibility of the 1083 receiver, and such losses must be recovered by means other than the 1084 retransmission mechanism specified in [QUIC-TRANSPORT] and 1085 [QUIC-RECOVERY]. 1087 7.1. Forward Error Correction 1089 *Authors' Note:* A simple parity-based Forward Error Correction 1090 scheme was removed from the experimental QUIC wire protocol 1091 specification in version Q032. The IETF's QUIC Working Group is 1092 chartered to specify one (or more) new FEC schemes in the future. 1094 This section will track developments in this area, and will be 1095 updated accordingly. 1097 A sender MAY make use of a suitable Forward Error Correction scheme 1098 to allow a receiver to reconstruct lost packets from those that have 1099 been successfully received. 1101 7.2. Unicast Repair 1103 In the case where a lost QUIC packet cannot be recovered using 1104 Forward Error Correction, either because the number of packets lost 1105 exceeds the scheme's threshold for reconstruction, or because FEC is 1106 not in use on the multicast QUIC session, a receiver MAY instead 1107 recover the missing payload data using conventional unicast HTTP 1108 requests to an origin server. 1110 o The total size of the resource is indicated in the "content- 1111 length" response header carried in the "HEADERS" HTTP/2 frame. 1113 o The location of the missing data can be determined by examining 1114 the Offset field in the "STREAM" QUIC frame headers of 1115 successfully received QUIC packets. 1117 Using this information, a receiver MAY compose an efficient HTTP 1118 range request [RFC7233] to the origin server indicated in the URL. 1119 Several disjoint ranges MAY be combined into a single HTTP request. 1120 A receiver MAY direct its request to an alternative server using Alt- 1121 Svc information received on the multicast QUIC session, or else 1122 received as part of a previous unicast HTTP response according to the 1123 rules in [RFC7838]. 1125 8. Transmission of Partial Content 1127 Under certain circumstances, a sender may not be in full possession 1128 of a resource body when transmission begins, or may not be able to 1129 guarantee that a transmission will complete. In such cases, the 1130 sender MAY employ the syntax of an HTTP range request [RFC7233] to 1131 indicate partial content, as specified below. All receivers SHALL 1132 implement support for such HTTP range requests. 1134 If partial content is to be transmitted: 1136 o The "range" header (Section 3.1 of [RFC7233]) SHALL be present in 1137 the "PUSH_PROMISE" HTTP/2 frame. 1139 o The corresponding "HEADERS" HTTP/2 frame SHALL indicate HTTP 1140 status code 206. 1142 * The range being transmitted SHALL be indicated in a "content- 1143 range" header field and the size of the complete resource 1144 indicated in a "content-length" header field. Either or both 1145 of these headers fields MAY be transmitted in a trailing 1146 "HEADERS" frame if their values are not known at the start of 1147 transmission. 1149 9. Protocol Identifier 1151 The HTTP over multicast QUIC protocol specified in this document is 1152 identified by the application-layer protocol negotiation (ALPN) 1153 [RFC7301] identifier "hqm". The IANA registration of this protocol 1154 identifier can be found in Section 12.1. This reserves the ALPN 1155 identifier space but describes a protocol that does not use TLS. The 1156 usage of the "hqm" identifier for discoverability is described in 1157 Section 10. 1159 9.1. Draft Version Identification 1161 *RFC Editor's Note:* Please remove this section prior to 1162 publication of a final version of this document. 1164 Only implementations of the final, published RFC can identify 1165 themselves as "hqm". Until such an RFC exists, implementations MUST 1166 NOT identify themselves using this string. 1168 Implementations of draft versions of the protocol MUST add the string 1169 "-" and the corresponding draft number to the identifier. For 1170 example, draft-pardue-quic-http-mcast-00 is identified using the 1171 string "hqm-00". 1173 Non-compatible experiments that are based on these draft versions 1174 MUST append the string "-" and an experiment name to the identifier. 1175 For example, an experimental implementation based on draft-pardue- 1176 quic-http-mcast-09 which removes the requirement to ensure version 1177 matches might identify itself as "hqm-09-version-ignorant". Note 1178 that any label MUST conform to the "token" syntax defined in 1179 Section 3.2.6 of [RFC7230]. Experimenters are encouraged to 1180 coordinate their experiments. 1182 10. Discovery of Multicast QUIC Sessions 1184 The announcement and discovery of services operating over multicast 1185 IP has previously been specified by the Session Description Protocol 1186 (SDP) [RFC4566], Session Announcement Protocol [RFC2974] and Session 1187 Initiation Protocol [RFC3261]. These are typically deployed together 1188 and in conjunction with a multicast-friendly transport such as the 1189 Real-time Transport Protocol (RTP) [RFC3550]. 1191 In contrast, the present document specifies a mechanism for 1192 advertising services that is built into HTTP metadata and is 1193 consistent across unicast and multicast resource delivery modes. 1194 This means that a single application-layer can be used for service 1195 advertisement/discovery, and for bulk data transmission/reception. 1196 Specifically, the "Alt-Svc" HTTP header is specified as the means to 1197 advertise multicast services from a unicast service. A unicast HTTP 1198 response MAY be decorated with an Alt-Svc value that hints to the 1199 client about the availability of the resource via a multicast QUIC 1200 session. A client that supports such a multicast QUIC session MAY 1201 then transparently switch to it. 1203 Symmetrically, the "Alt-Svc" header can also be used to advertise the 1204 unicast service from a multicast service. A resource transmitted as 1205 part of a multicast QUIC session MAY be decorated with an Alt-Svc 1206 value that hints to the client about the availability of the resource 1207 via an alternative unicast HTTP server. A receiver MAY then use this 1208 HTTP server for unicast resource patching (Section 7.2). 1210 Where HTTP over multicast QUIC sessions are advertised using Alt-Svc, 1211 the protocol identifier SHALL be "hqm", as specified in Section 9. 1213 10.1. Source-specific Multicast Advertisement 1215 Source-specific multicast (SSM) [RFC4607] MAY be used for the 1216 delivery of multicast services. 1218 *Authors' Note:* We invite review comments on mandating the use of 1219 source-specific multicast only. 1221 This document specifies the "source-address" parameter for Alt-Svc, 1222 which is used to provide the SSM source address to endpoints. 1224 Syntax: 1226 source-address = uri-host; see RFC7230, Section 2.7 1228 For example: 1230 source-address="192.0.2.1" 1232 When a multicast QUIC session is provided using SSM, the "source- 1233 address" parameter MUST be advertised. 1235 10.2. Session Parameter Advertisement 1237 The concept of session parameters is introduced in Section 2.2. This 1238 section details how the session parameters are expressed as Alt-Svc 1239 parameters. 1241 10.2.1. Version 1243 The version of QUIC supported in a multicast QUIC session is 1244 advertised with the "quic" parameter. The requirements for endpoint 1245 usage of "quic" are specified in Section 3.1. 1247 10.2.2. Cipher Suite 1249 This document specifies the "cipher-suite" parameter for Alt-Svc, 1250 which carries the cipher suite in use by a multicast QUIC session. 1251 "cipher-suite" MUST contain one of the values contained in the TLS 1252 Cipher Suite Registry (http://www.iana.org/assignments/tls- 1253 parameters/tls-parameters.xhtml#tls-parameters-4): 1255 Syntax: 1257 cipher-suite = 4*4 HEXDIG 1259 For example, the following specifies cipher suite 0x13,0x01 1260 ("TLS_AES_128_GCM_SHA256"): 1262 cipher-suite=1301 1264 The requirements for endpoint usage of "cipher-suite" are described 1265 in Section 3.2. 1267 10.2.3. Session Key 1269 This document specifies the "key" parameter for Alt-Svc, which 1270 carries the cryptographic key in use by the multicast QUIC session. 1272 Syntax: 1274 key = *HEXDIG 1276 For example: 1278 key=4adf1eab9c2a37fd 1280 The requirements for endpoint usage of "key" are described in 1281 Section 3.2. 1283 10.2.4. Session Cipher Initialization Vector 1285 This document specifies the "iv" parameter for Alt-Svc, which carries 1286 the cipher Initialization Vector (IV) in use by the multicast QUIC 1287 session. 1289 Syntax: 1291 iv = *HEXDIG 1293 For example: 1295 iv=4dbe593acb4d1577ad6ba7dc3189834e 1297 The requirements for endpoint usage of "iv" are described in 1298 Section 3.2. 1300 10.2.5. Session Identification 1302 This document defines the "session-id" parameter for Alt-Svc, which 1303 carries the multicast QUIC session identifier. 1305 Syntax: 1307 session-id = 1*16HEXDIG ; 64-bit value 1309 For example, the following specifies session 101 (0x65 hexadecimal): 1311 session-id=65 1313 The requirements for endpoint usage of "session-id" are described in 1314 Section 2.3. 1316 10.2.6. Session Idle Timeout Period 1318 This document specifies the "session-idle-timeout" parameter for Alt- 1319 Svc, which carries the idle timeout period of a multicast QUIC 1320 session. 1322 Syntax: 1324 session-idle-timeout = *DIGIT ; number of seconds between 0 and 600 1326 For example, the following specifies a one-minute session idle 1327 timeout period: 1329 session-idle-timeout=60 1330 The requirements for endpoint usage of "session-idle-timeout" are 1331 described in Section 3.4. 1333 10.2.7. Resource Concurrency 1335 This document specifies the "max-concurrent-resources" parameter for 1336 Alt-Svc, which expresses the maximum number of concurrent active 1337 resources from the sender in a multicast QUIC session. 1339 Syntax: 1341 max-concurrent-resources = *DIGIT ; unsigned 32-bit integer 1343 For example, the following specifies that no more than 12 (decimal) 1344 resources will be concurrently active in the session: 1346 max-concurrent-resources=12 1348 The requirements for endpoint usage of "max-concurrent-resources" are 1349 described in Section 3.6. 1351 10.2.8. Session Peak Flow Rate 1353 This document specifies the "peak-flow-rate" parameter for Alt-Svc, 1354 which expresses the expected maximum aggregate transfer rate of data 1355 from all sources of the multicast QUIC session. 1357 Syntax: 1359 peak-flow-rate = *DIGIT ; bits per second 1361 For example, the following specifies a peak flow rate of 550 kbits/s 1362 in the session: 1364 peak-flow-rate=550000 1366 The requirements for endpoint usage of "peak-flow-rate" are described 1367 in Section 3.5. 1369 10.2.9. Digest Algorithm 1371 This document specifies the "digest-algorithm" parameter for Alt-Svc, 1372 which carries the digest algorithm in use by a multicast QUIC 1373 session. "digest-algorithm" MUST contain one of the values defined in 1374 the HTTP Digest Algorithm Values registry 1375 (https://www.iana.org/assignments/http-dig-alg/http-dig- 1376 alg.xhtml#http-dig-alg-1). 1378 Syntax: 1380 digest-algorithm = token 1382 For example, the following specifies a digest algorithm of SHA-256: 1384 digest-algorithm=SHA-256 1386 The requirements for endpoint usage of "digest-algorithm" are 1387 described in Section 3.8. 1389 10.2.10. Signature Algorithm 1391 This document specifies the "signature-algorithm" parameter for Alt- 1392 Svc, which carries the signature algorithm in use by a multicast QUIC 1393 session. "signature-algorithm" MUST contain one of the values defined 1394 in the Signature Algorithms registry 1395 (http://www.iana.org/assignments/signature-algorithms). 1397 Syntax: 1399 signature-algorithm = token 1401 For example, the following specifies a signature algorithm of SHA- 1402 256: 1404 signature-algorithm=rsa-sha256 1406 The requirements for endpoint usage of "signature-algorithm" are 1407 described in Section 3.9. 1409 11. Security and Privacy Considerations 1411 This document specifies a profile of QUIC and HTTP/QUIC that changes 1412 the security model. In order to address this, application-level 1413 security methods are described in Section 6. This document does not 1414 preclude the use of secure multicast approaches that may provide 1415 additional security assurances required for certain use cases. 1417 The use of side-channel or out-of-band technologies (potentially 1418 bidirectional interactions) to support multicast QUIC sessions are 1419 considered out of this document's scope. Services using such 1420 technologies should apply their security considerations accordingly. 1422 11.1. Pervasive Monitoring 1424 Certain multicast deployment architectures may require the use of a 1425 session decryption key shared by all participants. Furthermore, the 1426 discovery mechanism described in this document provides a means for a 1427 receiver to obtain a session decryption key without joining the 1428 session. The act of removing packet protection in order to inspect 1429 or modify application contents may, in certain deployments, be 1430 trivial. The exploration of restricting key learning or session 1431 joining to authorised participants goes beyond the scope of this 1432 document. 1434 Because in-band multicast interactions are unidirectional, the impact 1435 of Pervasive Monitoring [RFC7258] on in-band traffic flows is 1436 inherently reduced. Actors can only inspect or modify sender- 1437 initiated traffic. Additional measures for content confidentiality 1438 may mitigate the impact further. This is discussed in Section 6.3. 1440 Further Pervasive Monitoring concerns are addressed in the following 1441 sections. 1443 11.1.1. Large-scale Data Gathering and Correlation 1445 Multicast QUIC sessions decouple sending and receiving participants. 1446 Session participation is subject to operations that allow an endpoint 1447 to join or leave a multicast group, typically IGMP [RFC3376] or MLD 1448 [RFC3810]. The propagation intent of these messages travelling 1449 deeper through a network hierarchy generally leads to the 1450 anonymisation of data if implemented as specified. It may be 1451 possible to gather user-identifiable messages close to the network 1452 edge, for example a router logging such messages. However, this 1453 would require wide-ranging access across Internet Service Provider 1454 networks. Therefore, while such attacks are feasible, it can be 1455 asserted that gathering and correlating user-identifiable traffic is 1456 difficult to perform covertly and at scale. 1458 11.1.2. Changing Content 1460 Sessions that use a symmetric key for packet protection are subject 1461 to the possibility of a malicious actor modifying traffic at some 1462 point in the network between a legitimate sender and one (or more) 1463 receivers. Receiver-side validation, as specified in Section 6 of 1464 the present document, and also in [QUIC-TRANSPORT], allows for the 1465 detection of such modification. Two approaches help mitigate the 1466 impact of modification; the first is application-level methods that 1467 protect data (Section 6.1) and metadata (Section 6.2); the second is 1468 reduction of the QUIC packet attack surface by means of removal of 1469 many frame types (Section 4.10 and Section 5.7). 1471 11.2. Protection of Discovery Mechanism 1473 Multicast QUIC session advertisements SHOULD be conveyed over a 1474 secure transport that guarantees authenticity and integrity in order 1475 to mitigate attacks related to a malicious service advertisement, for 1476 example a "man in the middle" directing endpoints to a service that 1477 may lead to other attacks or exploitations. 1479 *Authors' Note:* We invite review comments on mandating the use of 1480 a secure transport for advertising sessions. 1482 Endpoints that make use of multicast QUIC session advertisements 1483 SHOULD have reasonable assurance that the alternative service is 1484 under control of, and valid for, the whole origin, as described in 1485 Section 2.1 of [RFC7838]. Section 6.2 discusses measures that may be 1486 used to fulfil this requirement. 1488 11.3. Spoofing 1490 11.3.1. Spoofed Ack Attacks 1492 The Spoofed "ACK" attack described in Section 13.1 of 1493 [QUIC-TRANSPORT] is out of scope because use of the "ACK" frame is 1494 prohibited (Section 4.9) by the present document. 1496 11.3.2. Sender Spoofing 1498 A malicious actor may be able to stage a spoof attack by sending fake 1499 QUIC packets to a multicast QUIC session. This could affect the 1500 operation or behaviour of receivers. In a multicast scenario, this 1501 form of attack has the potential to scale massively. 1503 The feasibility of spoofing a multicast sender is governed by the 1504 characteristics of the multicast deployment and network 1505 infrastructure. The use of source-specific multicast [RFC4607] may 1506 reduce the feasibility. The use of content authenticity 1507 (Section 6.2) may mitigate concerns for the application-level 1508 messages. However, there remains the possibility for transport-level 1509 messages to be spoofed. Multicast applications should consider 1510 further mitigations to address this concern. 1512 11.3.3. Receiver Spoofing 1514 Client source address concerns discussed in Section 7.5 of 1515 [QUIC-TRANSPORT] are out of scope because the connection 1516 establishment is replaced with session establishment in the present 1517 document. Further, the impact that spoofed receivers would have on 1518 the sender is minimal. The impact of malicious participants on the 1519 network is discussed in Section 11.6.2. 1521 11.4. Replay Attacks 1523 Conventional QUIC strategies for protecting against replay attacks 1524 apply similarly here. 1526 Certain multicast QUIC sessions may use a shared key for transport- 1527 level encryption, which would allow an attacker to record, decrypt, 1528 repackage and replay QUIC packets. Section 6.2 discusses how the 1529 application-level contents may be protected from replay (by signing 1530 the "Date" HTTP header), which provides some mitigation to the 1531 success rate or effects of replay attacks. 1533 11.5. Message Deletion 1535 Since HTTP over multicast QUIC is designed to tolerate unreliable 1536 delivery, the impacts of message deletion attacks are presumed to be 1537 small. Deletion of packets carrying HTTP headers will cause a 1538 receiver to ignore subsequent packets carrying body data. 1539 Furthermore, the use of multicast QUIC sessions is opportunistic; 1540 disruption in service (for example, deleting packets and causing a 1541 receiver to fail in construction of a content object) is mitigated by 1542 falling back to a unicast service. Considerations for how this may 1543 affect the performance of the unicast service are given in 1544 Section 11.6.3. 1546 11.6. Denial of Service 1548 11.6.1. Unprotected Frames and Packets 1550 The handling of unprotected QUIC packets is discussed in section 1551 9.1.4 of [QUIC-TLS]. The profile described in the present document 1552 provides the means for a multicast sender to protect QUIC packets 1553 with a shared key, which is not a strong protection. The weak 1554 protection of QUIC packets could present a denial-of-service risk. 1555 To mitigate the impact of handling such QUIC packets, certain frames 1556 and packets are prohibited as described in (Section 4.10 and 1557 Section 5.7). 1559 The frame types that are allowed by this profile do not present a 1560 risk of denial of service. Concerns over authenticity and integrity 1561 are addressed by the application-layer protection mechanisms 1562 described in Section 6. 1564 11.6.2. Network Performance Degradation 1566 The possibility for malfunctioning or malicious participants to 1567 degrade the network is a broad issue and considered out of scope for 1568 this document. Guidelines and concerns discussed in UDP Best 1569 Practices [RFC8085] and other sources apply equally here. This 1570 specification does not preclude the use of network performance 1571 degradation mitigation solutions such as network circuit breakers. 1573 11.6.3. Unicast Repair Stampeding Herd 1575 Deployments that support the unicast repair mechanism described in 1576 Section 7.2 should be aware that a triggering of this behaviour 1577 (either deliberate, planned or unplanned) in a large population of 1578 multicast receivers may cause a stampeding herd of client requests to 1579 the unicast repair service. Service operators SHOULD mitigate the 1580 impact of stampeding herd on their deployment. 1582 11.7. Receiver Resource Usage 1584 The application of receiver-side validation, as defined in the 1585 present document and in [QUIC-TRANSPORT], adds some protection 1586 against allocating resource to the processing of bad data. 1588 11.8. Unicast Repair Information Leakage 1590 The unicast repair mechanism may lead to the leakage of user 1591 behaviour data. An attacker could gain insight into any receiver 1592 participating in a multicast QUIC session, for example by monitoring 1593 the TCP port of the unicast alternative. This alone is no worse than 1594 current abilities to monitor unicast interactions, for example 1595 observing the SNI field contained in a TLS ClientHello. The complete 1596 protection of unicast interactions is beyond the scope of this 1597 document. However, knowledge that a user (or group of users) has 1598 participated in a session is sensitive and may be obtained by 1599 correlation between with observable multicast and unicast traffic. 1601 To give an example, a malicious "man in the middle" could purposely 1602 cause all receivers to perform a unicast repair (by disrupting the 1603 QUIC traffic flow in some way). The disruption is untargeted and may 1604 be simple to orchestrate, but the correlation of user activity data, 1605 especially across a distributed repair service (e.g. a CDN), requires 1606 resources that may reduce the attractiveness of such an attack. 1608 The ability for an attacker to disrupt multicast QUIC sessions is 1609 mitigated by this profile (mainly the prohibition of frames and 1610 packets). Application-layer security measures described in Section 6 1611 reduce the feasibility further. 1613 Multicast receivers concerned about this form of leakage can 1614 eliminate this risk completely by disabling support for unicast 1615 repair, at the potential cost of reduced service quality. 1617 12. IANA Considerations 1619 12.1. Registration of Protocol Identification String 1621 This document creates a new registration for the identification of 1622 the HTTP over multicast QUIC protocol in the "Application-Layer 1623 Protocol Negotiation (ALPN) Protocol IDs" registry established by 1624 [RFC7301]. 1626 The "hqm" string identifies HTTP semantics expressed as HTTP mapped 1627 to a QUIC layer and carried over IP multicast: 1629 Protocol: Bulk data transport using HTTP over multicast QUIC 1631 Identification Sequence: 0x68 0x71 0x6D ("hqm") 1633 Specification: This document, Section 9 1635 This entry reserves an identifier that is not allowed to appear in 1636 TLS Application-Layer Protocol Negotiation. 1638 12.2. Registration of Alt-Svc parameters 1640 This document creates seven registrations for the identification of 1641 parameters for the "Hypertext Transfer Protocol (HTTP) Alt-Svc 1642 Parameter Registry" established by [RFC7838] 1643 (http://www.iana.org/assignments/tls-extensiontype-values/tls- 1644 extensiontype-values.xhtml#alpn-protocol-ids). 1646 12.2.1. Source Address 1648 Parameter name: source-address 1650 Specification: This document, Section 10.1 1652 12.2.2. Cipher Suite 1654 Parameter name: cipher-suite 1656 Specification: This document, Section 10.2.2 1658 12.2.3. Key 1660 Parameter name: key 1662 Specification: This document, Section 10.2.3 1664 12.2.4. Initialization Vector 1666 Parameter name: iv 1668 Specification: This document, Section 10.2.4 1670 12.2.5. Session Identifier 1672 Parameter name: session-id 1674 Specification: This document, Section 10.2.5 1676 12.2.6. Session Idle Timeout 1678 Parameter name: session-idle-timeout 1680 Specification: This document, Section 10.2.6 1682 12.2.7. Maximum Concurrent Resources 1684 Parameter name: max-concurrent-resources 1686 Specification: This document, Section 10.2.7 1688 12.2.8. Peak Flow Rate 1690 Parameter name: peak-flow-rate 1692 Specification: This document, Section 10.2.8 1694 12.2.9. Digest Algorithm 1696 Parameter name: digest-algorithm 1698 Specification: This document, Section 10.2.9 1700 12.2.10. Signature Algorithm 1702 Parameter name: signature-algorithm 1704 Specification: This document, Section 10.2.10 1706 13. References 1708 13.1. Normative References 1710 [I-D.cavage-http-signatures] 1711 Cavage, M. and M. Sporny, "Signing HTTP Messages", draft- 1712 cavage-http-signatures-07 (work in progress), July 2017. 1714 [QUIC-HTTP] 1715 Bishop, M., Ed., "Hypertext Transfer Protocol (HTTP) over 1716 QUIC", draft-ietf-quic-http-04 (work in progress). 1718 [QUIC-RECOVERY] 1719 Iyengar, J., Ed. and I. Swett, Ed., "QUIC Loss Detection 1720 and Congestion Control", draft-ietf-quic-recovery-04 (work 1721 in progress). 1723 [QUIC-TLS] 1724 Thomson, M., Ed. and S. Turner, Ed, Ed., "Using Transport 1725 Layer Security (TLS) to Secure QUIC", draft-ietf-quic- 1726 tls-04 (work in progress). 1728 [QUIC-TRANSPORT] 1729 Iyengar, J., Ed. and M. Thomson, Ed., "QUIC: A UDP-Based 1730 Multiplexed and Secure Transport", draft-ietf-quic- 1731 transport-04 (work in progress). 1733 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 1734 Requirement Levels", BCP 14, RFC 2119, 1735 DOI 10.17487/RFC2119, March 1997, 1736 . 1738 [RFC3230] Mogul, J. and A. Van Hoff, "Instance Digests in HTTP", 1739 RFC 3230, DOI 10.17487/RFC3230, January 2002, 1740 . 1742 [RFC4607] Holbrook, H. and B. Cain, "Source-Specific Multicast for 1743 IP", RFC 4607, DOI 10.17487/RFC4607, August 2006, 1744 . 1746 [RFC5234] Crocker, D., Ed. and P. Overell, "Augmented BNF for Syntax 1747 Specifications: ABNF", STD 68, RFC 5234, 1748 DOI 10.17487/RFC5234, January 2008, 1749 . 1751 [RFC7230] Fielding, R., Ed. and J. Reschke, Ed., "Hypertext Transfer 1752 Protocol (HTTP/1.1): Message Syntax and Routing", 1753 RFC 7230, DOI 10.17487/RFC7230, June 2014, 1754 . 1756 [RFC7233] Fielding, R., Ed., Lafon, Y., Ed., and J. Reschke, Ed., 1757 "Hypertext Transfer Protocol (HTTP/1.1): Range Requests", 1758 RFC 7233, DOI 10.17487/RFC7233, June 2014, 1759 . 1761 [RFC7234] Fielding, R., Ed., Nottingham, M., Ed., and J. Reschke, 1762 Ed., "Hypertext Transfer Protocol (HTTP/1.1): Caching", 1763 RFC 7234, DOI 10.17487/RFC7234, June 2014, 1764 . 1766 [RFC7301] Friedl, S., Popov, A., Langley, A., and E. Stephan, 1767 "Transport Layer Security (TLS) Application-Layer Protocol 1768 Negotiation Extension", RFC 7301, DOI 10.17487/RFC7301, 1769 July 2014, . 1771 [RFC7405] Kyzivat, P., "Case-Sensitive String Support in ABNF", 1772 RFC 7405, DOI 10.17487/RFC7405, December 2014, 1773 . 1775 [RFC7540] Belshe, M., Peon, R., and M. Thomson, Ed., "Hypertext 1776 Transfer Protocol Version 2 (HTTP/2)", RFC 7540, 1777 DOI 10.17487/RFC7540, May 2015, 1778 . 1780 [RFC7838] Nottingham, M., McManus, P., and J. Reschke, "HTTP 1781 Alternative Services", RFC 7838, DOI 10.17487/RFC7838, 1782 April 2016, . 1784 13.2. Informative References 1786 [QCRAM] Krasic, C., Ed., "Header Compression for HTTP over QUIC", 1787 draft-krasic-quic-qcram-02 (work in progress). 1789 [QPACK] Bishop, M., Ed., "Header Compression for HTTP/QUIC", 1790 draft-bishop-quic-http-and-qpack-02 (work in progress). 1792 [QUICCrypto] 1793 Langley, A. and W. Chang, "QUIC Crypto", May 2016, 1794 . 1796 [RFC1112] Deering, S., "Host extensions for IP multicasting", STD 5, 1797 RFC 1112, DOI 10.17487/RFC1112, August 1989, 1798 . 1800 [RFC1191] Mogul, J. and S. Deering, "Path MTU discovery", RFC 1191, 1801 DOI 10.17487/RFC1191, November 1990, 1802 . 1804 [RFC2460] Deering, S. and R. Hinden, "Internet Protocol, Version 6 1805 (IPv6) Specification", RFC 2460, DOI 10.17487/RFC2460, 1806 December 1998, . 1808 [RFC2974] Handley, M., Perkins, C., and E. Whelan, "Session 1809 Announcement Protocol", RFC 2974, DOI 10.17487/RFC2974, 1810 October 2000, . 1812 [RFC3261] Rosenberg, J., Schulzrinne, H., Camarillo, G., Johnston, 1813 A., Peterson, J., Sparks, R., Handley, M., and E. 1814 Schooler, "SIP: Session Initiation Protocol", RFC 3261, 1815 DOI 10.17487/RFC3261, June 2002, 1816 . 1818 [RFC3376] Cain, B., Deering, S., Kouvelas, I., Fenner, B., and A. 1819 Thyagarajan, "Internet Group Management Protocol, Version 1820 3", RFC 3376, DOI 10.17487/RFC3376, October 2002, 1821 . 1823 [RFC3550] Schulzrinne, H., Casner, S., Frederick, R., and V. 1824 Jacobson, "RTP: A Transport Protocol for Real-Time 1825 Applications", STD 64, RFC 3550, DOI 10.17487/RFC3550, 1826 July 2003, . 1828 [RFC3810] Vida, R., Ed. and L. Costa, Ed., "Multicast Listener 1829 Discovery Version 2 (MLDv2) for IPv6", RFC 3810, 1830 DOI 10.17487/RFC3810, June 2004, 1831 . 1833 [RFC4566] Handley, M., Jacobson, V., and C. Perkins, "SDP: Session 1834 Description Protocol", RFC 4566, DOI 10.17487/RFC4566, 1835 July 2006, . 1837 [RFC4821] Mathis, M. and J. Heffner, "Packetization Layer Path MTU 1838 Discovery", RFC 4821, DOI 10.17487/RFC4821, March 2007, 1839 . 1841 [RFC5737] Arkko, J., Cotton, M., and L. Vegoda, "IPv4 Address Blocks 1842 Reserved for Documentation", RFC 5737, 1843 DOI 10.17487/RFC5737, January 2010, 1844 . 1846 [RFC6676] Venaas, S., Parekh, R., Van de Velde, G., Chown, T., and 1847 M. Eubanks, "Multicast Addresses for Documentation", 1848 RFC 6676, DOI 10.17487/RFC6676, August 2012, 1849 . 1851 [RFC7258] Farrell, S. and H. Tschofenig, "Pervasive Monitoring Is an 1852 Attack", BCP 188, RFC 7258, DOI 10.17487/RFC7258, May 1853 2014, . 1855 [RFC7450] Bumgardner, G., "Automatic Multicast Tunneling", RFC 7450, 1856 DOI 10.17487/RFC7450, February 2015, 1857 . 1859 [RFC7541] Peon, R. and H. Ruellan, "HPACK: Header Compression for 1860 HTTP/2", RFC 7541, DOI 10.17487/RFC7541, May 2015, 1861 . 1863 [RFC8085] Eggert, L., Fairhurst, G., and G. Shepherd, "UDP Usage 1864 Guidelines", BCP 145, RFC 8085, DOI 10.17487/RFC8085, 1865 March 2017, . 1867 Appendix A. Acknowledgements 1869 The authors would like to thank the following for their contributions 1870 to the design described in the present document: Brandon Butterworth, 1871 Sam Hurst, Chris Poole, Craig Taylor and David Waring. 1873 We are also grateful to Thomas Swindells and Magnus Westerlund for 1874 their helpful review comments. 1876 Appendix B. Examples 1878 This appendix contains examples of multicast QUIC session 1879 advertisement and resource transfer (with and without application- 1880 layer content security). 1882 B.1. Session Advertisement 1884 This section shows several different examples of an HTTP service 1885 advertising a multicast QUIC session. Examples are given in IPv4 1886 form, using reserved address ranges as specified in [RFC5737] and 1887 [RFC6676]. 1889 B.1.1. Source-specific Multicast QUIC Session 1891 Advertisement of a multicast QUIC session operating on the source- 1892 specific multicast group address 232.0.0.1 on port 2000 with the 1893 source address 192.0.2.1. The session ID is 16 (0x10) and the idle 1894 timeout is one minute. At most 10 resources may be concurrently 1895 active in the session and the flow rate should not exceed 10 kbits/s. 1896 The multicast transport is unencrypted. 1898 HTTP Alternative Service header field: 1900 Alt-Svc: 1901 hqm="232.0.0.1:2000"; source-address="192.0.2.1"; quic=1; 1902 session-id=10; session-idle-timeout=60; 1903 max-concurrent-resources=10; peak-flow-rate=10000 1905 B.1.2. Source-specific Multicast QUIC Session with Transport Encryption 1906 using a Symmetric Key 1908 Advertisement of a multicast QUIC session operating on the IPv6 1909 globally-scoped source-specific multicast group address ff3e::1234 on 1910 port 2000 with the source address 2001:db8::1. The session ID is 16 1911 (0x10) and the idle timeout is one minute. At most 10 resources may 1912 be concurrently active in the session and the flow rate should not 1913 exceed 10 kbits/s. The multicast transport is encrypted using the 1914 AEAD cipher suite 0x13,0x01 ("TLS_AES_128_GCM_SHA256") with the 1915 shared session key and IV provided. 1917 HTTP Alternative Service header field: 1919 Alt-Svc: 1920 hqm="[ff3e::1234]:2000"; source-address="2001:db8::1"; quic=1; 1921 session-id=10; session-idle-timeout=60; 1922 max-concurrent-resources=10; peak-flow-rate=10000; 1923 cipher-suite=1301; key=4adf1eab9c2a37fd; iv=4dbe593acb4d1577ad6ba7dc3189834e 1925 B.1.3. Source-specific Multicast QUIC Session with Transport 1926 Encryption, Content Integrity and Authenticity 1928 Advertisement of a multicast QUIC session operating on the IPv6 1929 globally-scoped source-specific multicast group address ff3e::1234 on 1930 port 2000 with the source address 2001:db8::1. The session ID is 16 1931 (0x10) and the idle timeout is one minute. At most 10 resources may 1932 be concurrently active in the session and the flow rate should not 1933 exceed 10 kbits/s. The multicast transport is encrypted using the 1934 AEAD cipher suite 0x13,0x01 ("TLS_AES_128_GCM_SHA256") with the 1935 shared session key and IV provided. Content integrity is in use with 1936 the digest algorithm set restricted to SHA-256. Content authenticity 1937 is in use with the signature algorithm set restricted to rsa-sha256. 1939 HTTP Alternative Service header field: 1941 Alt-Svc: 1942 hqm="[ff3e::1234]:2000"; source-address="2001:db8::1"; quic=1; 1943 session-id=10; session-idle-timeout=60; 1944 max-concurrent-resources=10; peak-flow-rate=10000; 1945 cipher-suite=1301; key=4adf1eab9c2a37fd; iv=4dbe593acb4d1577ad6ba7dc3189834e 1946 digest-algorithm=SHA-256; signature-algorithm=rsa-sha256 1948 B.2. Resource Transfer 1950 This section shows several different examples of the HTTP message 1951 patterns for a single resource. 1953 Examples that show "PUSH_PROMISE" or "HEADERS" HTTP/2 frames describe 1954 the contents of enclosed header block fragments. 1956 B.2.1. Transfer without Content Integrity or Authenticity 1958 "PUSH_PROMISE" HTTP/2 frame: 1960 :method: GET 1961 :scheme: https 1962 :path: /files/example.txt 1963 :authority: example.org 1965 "HEADERS" HTTP/2 frame; 1967 :status: 200 1968 content-length: 100 1969 content-type: text/plain 1970 date: Fri, 20 Jan 2017 10:00:00 GMT 1972 QUIC "STREAM" frame containing 100 bytes of response body data: 1974 ... 1976 B.2.2. Transfer of Partial Content without Content Integrity or 1977 Authenticity 1979 In this example, partial content is transferred as described in 1980 Section 8. The "Range" request header is used to indicate the 1981 sender's intention to transfer all 100 bytes of the representation, 1982 but the "Content-Range" trailing response header indicates that only 1983 the first 50 bytes were actually transferred. 1985 "PUSH_PROMISE" HTTP/2 frame: 1987 :method: GET 1988 :scheme: https 1989 :path: /files/example.txt 1990 :authority: example.org 1991 range: bytes=0-* 1993 Leading "HEADERS" HTTP/2 frame: 1995 :status: 206 1996 content-length: 100 1997 content-type: text/plain 1998 date: Fri, 20 Jan 2017 10:00:00 GMT 2000 "STREAM" QUIC frame containing 50 bytes of response body data: 2002 ... 2004 Trailing "HEADERS" HTTP/2 frame indicating the range of bytes sent: 2006 content-range: bytes 0-49/100 2008 B.2.3. Transfer with Content Integrity and without Authenticity 2010 In this example, content integrity is assured by the inclusion of the 2011 "Digest" response header, as described in Section 6.1. 2013 "PUSH_PROMISE" HTTP/2 frame: 2015 :method: GET 2016 :scheme: https 2017 :path: /files/example.txt 2018 :authority: example.org 2020 "HEADERS" HTTP/2 frame including the "Digest" header: 2022 :status: 200 2023 content-length: 100 2024 content-type: text/plain 2025 date: Fri, 20 Jan 2017 10:00:00 GMT 2026 digest: SHA-256=DieQ9zfRaDdyAilTVCvmBePuxMm+B6cNocP+QCrNSqo= 2028 "STREAM" QUIC frame containing 100 bytes of response body data: 2030 ... 2032 B.2.4. Partial Transfer with Content Integrity and without Authenticity 2034 In this example, partial content is transferred as described in 2035 Section 8. The "Range" request header is used to indicate the 2036 sender's intention to transfer all 100 bytes of the representation, 2037 but the "Content-Range" trailing response header indicates that only 2038 the first 50 bytes were actually transferred. Content integrity is 2039 assured by the inclusion of the "Digest" response header, as 2040 described in Section 6.1. 2042 "PUSH_PROMISE" HTTP/2 frame: 2044 :method: GET 2045 :scheme: https 2046 :path: /files/example.txt 2047 :authority: example.org 2048 range: bytes=0-* 2050 Leading "HEADERS" HTTP/2 frame including the "Digest" header: 2052 :status: 206 2053 content-length: 100 2054 content-type: text/plain 2055 date: Fri, 20 Jan 2017 10:00:00 GMT 2056 digest: SHA-256=DieQ9zfRaDdyAilTVCvmBePuxMm+B6cNocP+QCrNSqo= 2058 "STREAM" QUIC frame containing 50 bytes of response body data: 2060 ... 2062 Trailing "HEADERS" HTTP/2 frame indicating the range of bytes sent: 2064 content-range: bytes 0-49/100 2066 B.2.5. Transfer with Content Integrity and Authenticity 2068 In this example, content integrity is assured by the inclusion of the 2069 "Digest" response header, as described in Section 6.1. Content 2070 authenticity is assured separately for the request and the response 2071 messages by the "Signature" header which protects the header fields 2072 described in further detail below. The "Signature" header parameter 2073 "keyId" contains the URL of a file containing the public key related 2074 to the multicast sender's private key used to create the digital 2075 signature. 2077 "PUSH_PROMISE" HTTP/2 frame including a "Signature" header protecting 2078 the ":method" and ":path" (the request target), as well as the 2079 ":scheme" and ":authority" of the pseudo-request: 2081 :method: GET 2082 :scheme: https 2083 :path: /files/example.txt 2084 :authority: example.org 2085 signature: keyId="https://example.org/mcast-sender.example.org.pem", 2086 algorithm=rsa-sha256, 2087 headers="(request-target) :scheme :authority", 2088 signature="MGQCMFTaFptaM2FhgzJq2i9AaChuFDHjp6GiXVtRnI8BsA" 2090 "HEADERS" HTTP/2 frame including a "Signature" header protecting the 2091 ":method", ":path", ":scheme" and ":authority" of the pseudo-request 2092 above, plus the "Date" and "Digest" of the response: 2094 :status: 200 2095 content-length: 100 2096 content-type: text/plain 2097 date: Fri, 20 Jan 2017 10:00:00 GMT 2098 digest: SHA-256=DieQ9zfRaDdyAilTVCvmBePuxMm+B6cNocP+QCrNSqo= 2099 signature: keyId="https://example.org/mcast-sender.example.org.pem", 2100 algorithm=rsa-sha256, 2101 headers="(request-target) :scheme :authority date digest", 2102 signature="MGUCMBgx6cuwTzg0W29zNUra8xfMsEcb3rFA3Y" 2104 "STREAM" QUIC frame containing response body data: 2106 ... 2108 B.2.6. Partial Transfer with Content Integrity and Authenticity 2110 In this example, partial content is transferred and the "Range" 2111 header (as described in Section 8) is used to indicate that 50 bytes 2112 out of 100 bytes were transferred. Content integrity is provided by 2113 the inclusion of the "Digest" header, as described in Section 6.1. 2114 Authenticity is provided by the "Signature" header which protects the 2115 header fields described in further detail. The "Signature" header 2116 parameter "keyId" contains the URL of a file containing the public 2117 key related to the multicast sender's private key used to create the 2118 digital signature. 2120 "PUSH_PROMISE" HTTP/2 frame: 2122 :method: GET 2123 :scheme: https 2124 :path: /files/example.txt 2125 :authority: example.org 2126 range: bytes=0-* 2127 signature: keyId="https://example.org/mcast-sender.example.org.pem", 2128 algorithm=rsa-sha256, 2129 headers="(request-target) :scheme :authority range", 2130 signature="MGQCMFTaFptaM2FhgzJq2i9AaChuFDHjp6GiXVtRnI8BsA" 2132 Leading "HEADERS" HTTP/2 frame: 2134 :status: 206 2135 content-length: 100 2136 content-type: text/plain 2137 date: Fri, 20 Jan 2017 10:00:00 GMT 2138 digest: SHA-256=DieQ9zfRaDdyAilTVCvmBePuxMm+B6cNocP+QCrNSqo= 2140 "STREAM" QUIC frame containing response body data: 2142 ... 2144 Trailing "HEADERS" HTTP/2 frame protecting the ":method", ":path", 2145 ":scheme" and ":authority" of the pseudo-request above, plus the 2146 "Date", "Digest" and "Content-Range" of the response: 2148 content-range: bytes 0-49/100 2149 signature: keyId="https://example.org/mcast-sender.example.org.pem", 2150 algorithm=rsa-sha256, 2151 headers="(request-target) :scheme :authority 2152 date digest content-range", 2153 signature="MGUCMBgx6cuwTzg0W29zNUra8xfMsEcb3rFA3Y" 2155 Appendix C. Changelog 2157 *RFC Editor's Note:* Please remove this section prior to 2158 publication of a final version of this document. 2160 C.1. Since draft-pardue-quic-http-mcast-00 2162 o Update references to QUIC I-Ds. 2164 o Relax session leaving requirements language. 2166 o Clarify handling of omitted session parameter advertisements. 2168 o Rename "Idle" state to "Quiescent". 2170 o Add digest algorithm session parameter. 2172 o Add signature algorithm session parameter. 2174 o Add Initialization Vector session parameter. 2176 o Replace COPT tag-value-pairs with TransportParameter values. 2178 o Add example of an advertisement for a session with content 2179 authenticity and integrity. 2181 Authors' Addresses 2183 Lucas Pardue 2184 BBC Research & Development 2186 Email: lucas.pardue@bbc.co.uk 2188 Richard Bradbury 2189 BBC Research & Development 2191 Email: richard.bradbury@bbc.co.uk