idnits 2.17.1 draft-jholland-quic-multicast-00.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- No issues found here. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year -- The document date (13 May 2022) is 713 days in the past. Is this intentional? -- Found something which looks like a code comment -- if you have code sections in the document, please surround them with '' and '' lines. Checking references for intended status: Experimental ---------------------------------------------------------------------------- == Outdated reference: A later version (-07) exists of draft-ietf-quic-multipath-00 == Outdated reference: A later version (-06) exists of draft-krose-multicast-security-02 Summary: 0 errors (**), 0 flaws (~~), 3 warnings (==), 2 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 QUIC Working Group J. Holland 3 Internet-Draft Akamai Technologies, Inc. 4 Intended status: Experimental L. Pardue 5 Expires: 14 November 2022 6 M. Franke 7 TU Berlin 8 13 May 2022 10 Multicast Extension for QUIC 11 draft-jholland-quic-multicast-00 13 Abstract 15 This document defines a multicast extension to QUIC to enable the 16 efficient use of mullticast-capable networks to send identical data 17 streams to many clients at once, coordinated through individual 18 unicast QUIC connections. 20 Status of This Memo 22 This Internet-Draft is submitted in full conformance with the 23 provisions of BCP 78 and BCP 79. 25 Internet-Drafts are working documents of the Internet Engineering 26 Task Force (IETF). Note that other groups may also distribute 27 working documents as Internet-Drafts. The list of current Internet- 28 Drafts is at https://datatracker.ietf.org/drafts/current/. 30 Internet-Drafts are draft documents valid for a maximum of six months 31 and may be updated, replaced, or obsoleted by other documents at any 32 time. It is inappropriate to use Internet-Drafts as reference 33 material or to cite them other than as "work in progress." 35 This Internet-Draft will expire on 14 November 2022. 37 Copyright Notice 39 Copyright (c) 2022 IETF Trust and the persons identified as the 40 document authors. All rights reserved. 42 This document is subject to BCP 78 and the IETF Trust's Legal 43 Provisions Relating to IETF Documents (https://trustee.ietf.org/ 44 license-info) in effect on the date of publication of this document. 45 Please review these documents carefully, as they describe your rights 46 and restrictions with respect to this document. Code Components 47 extracted from this document must include Revised BSD License text as 48 described in Section 4.e of the Trust Legal Provisions and are 49 provided without warranty as described in the Revised BSD License. 51 Table of Contents 53 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3 54 2. Multicast Channel . . . . . . . . . . . . . . . . . . . . . . 3 55 3. Transport Parameter . . . . . . . . . . . . . . . . . . . . . 5 56 4. Extension Overview . . . . . . . . . . . . . . . . . . . . . 6 57 4.1. Channel Management . . . . . . . . . . . . . . . . . . . 6 58 4.2. Client Response . . . . . . . . . . . . . . . . . . . . . 7 59 4.3. Data Carried in Channels . . . . . . . . . . . . . . . . 7 60 4.4. Stream Processing . . . . . . . . . . . . . . . . . . . . 8 61 5. Flow Control . . . . . . . . . . . . . . . . . . . . . . . . 8 62 6. Congestion Control . . . . . . . . . . . . . . . . . . . . . 9 63 7. Data Integrity . . . . . . . . . . . . . . . . . . . . . . . 9 64 7.1. Packet Hashes . . . . . . . . . . . . . . . . . . . . . . 9 65 8. Packet Scheduling . . . . . . . . . . . . . . . . . . . . . . 9 66 9. Stateless Reset . . . . . . . . . . . . . . . . . . . . . . . 10 67 10. Implementation and Operational Considerations . . . . . . . . 10 68 11. New Frames . . . . . . . . . . . . . . . . . . . . . . . . . 10 69 11.1. MC_CHANNEL_ANNOUNCE . . . . . . . . . . . . . . . . . . 10 70 11.2. MC_CHANNEL_PROPERTIES . . . . . . . . . . . . . . . . . 12 71 11.3. MC_CHANNEL_JOIN . . . . . . . . . . . . . . . . . . . . 15 72 11.4. MC_CHANNEL_LEAVE . . . . . . . . . . . . . . . . . . . . 16 73 11.5. MC_CHANNEL_INTEGRITY . . . . . . . . . . . . . . . . . . 16 74 11.6. MC_CHANNEL_STREAM_BOUNDARY_OFFSET . . . . . . . . . . . 17 75 11.7. MC_CHANNEL_ACK . . . . . . . . . . . . . . . . . . . . . 17 76 11.8. MC_PATH_RESPONSE . . . . . . . . . . . . . . . . . . . . 18 77 11.9. MC_CLIENT_LIMITS . . . . . . . . . . . . . . . . . . . . 18 78 11.10. MC_CHANNEL_RETIRE . . . . . . . . . . . . . . . . . . . 19 79 11.11. MC_CLIENT_CHANNEL_STATE . . . . . . . . . . . . . . . . 19 80 12. Frames Carried in Channel Packets . . . . . . . . . . . . . . 21 81 13. Error Codes . . . . . . . . . . . . . . . . . . . . . . . . . 23 82 14. Security Considerations . . . . . . . . . . . . . . . . . . . 23 83 15. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 23 84 16. References . . . . . . . . . . . . . . . . . . . . . . . . . 23 85 16.1. Normative References . . . . . . . . . . . . . . . . . . 23 86 16.2. Informative References . . . . . . . . . . . . . . . . . 24 87 Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . . . 24 88 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 24 90 1. Introduction 92 This document specifies an extension to QUIC version 1 [RFC9000] to 93 enable the use of multicast IP transport of identical data packets 94 for use in many individual QUIC connections. 96 The multicast data can only be consumed in conjunction with a unicast 97 QUIC connection. When support for multicast is negotiated, the 98 server can optionally advertise existence of one or more multicast 99 channels that contain unidirectional data streams from server to 100 client, and the client can optionally join the multicast channel and 101 verify from integrity data the server provides that correct data is 102 being received, then acknowledge the data from the multicast 103 channel(s) over the unicast connection. 105 Enabling this can provide large scalability benefits for popular 106 traffic over multicast-capable networks. 108 This document does not define any multicast transport except server 109 to client and only includes semantics for source-specific multicast. 110 ## Conventions and Definitions 112 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 113 "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and 114 "OPTIONAL" in this document are to be interpreted as described in 115 BCP 14 [RFC2119] [RFC8174] when, and only when, they appear in all 116 capitals, as shown here. 118 Commonly used terms in this document are described below. 120 (S,G): A tuple of IP addresses identifying a source-specific 121 multicast channel, as described in [RFC4607]. 123 2. Multicast Channel 125 A QUIC multicast channel (or just channel) is a one-way network path 126 that a server can use as an alternate path to send QUIC connection 127 data to a client. 129 Multicast channels are designed to leverage multicast IP and to be 130 shared by many different connections simultaneously for 131 unidirectional server-initiated data. One or more servers can use 132 the same QUIC multicast channel to send the same data to many 133 clients, as a supplement to the individual QUIC connections between 134 those servers and clients. 136 Each QUIC multicast channel has exactly one associated (S,G) that is 137 used for the delivery of the multicast packets on the IP layer. 138 Channels do not support any-source multicast semantics. This however 139 does not impose a requirement on how the underlying network stack has 140 to handle the forwarding and delivery of multicast packets. 142 QUIC connections are defined in Section 5 of [RFC9000] and are not 143 changed in this document; each connection is a shared state between a 144 client and a server. 146 Channels carry only 1-RTT packets. Packets associated with a channel 147 contain a Channel ID in place of a Destination Connection ID. (A 148 Channel ID cannot be zero length.) This adds a layer of indirection 149 to the process described in Section 5.2 of [RFC9000]} for matching 150 packets to connections upon receipt. Incoming packets received on 151 the network path associated with a channel use the Channel ID to 152 associate the packet with a joined channel. 154 A client with a matching joined channel always has at least one 155 connection associated with the channel. If a client has no matching 156 joined channel, the packet is discarded. 158 Since the network path for a channel is unidirectional, packets 159 associated with a channel are acknowledged with MP_CHANNEL_ACK frames 160 Section 11.7 instead of with ACK frames. Each channel has an 161 independent packet number space. 163 The use of any particular channel is OPTIONAL for both the server and 164 the client. It is recommended that applications designed to leverage 165 the multicast capabilities of this extension also provide graceeful 166 degradation for endpoints that do not or cannot make use of the 167 multicast functionality. 169 The server has access to all data transmitted on any multicast 170 channel it uses, and could optionally send this data with unicast 171 instead. 173 No special handling of the data is required in a client application 174 that has enabled multicast. A datagram or any particular bytes from 175 a server-initiated unidirectional stream can be delivered over the 176 unicast connection or a multicast channel transparently to the 177 client. 179 Client applications should have a mechanism that disables the use of 180 multicast on connections with enhanced privacy requirements for the 181 privacy-related reasons covered in 182 [I-D.draft-krose-multicast-security]. 184 3. Transport Parameter 186 Support for multicast extesnsions in a client is advertised by means 187 of a QUIC transport parameter: 189 * name: multicast_client_params (TBD - experiments use 0xff3e800) 191 If a multicast_client_params transport parameter is not included, 192 servers MUST NOT send any frames defined in this document. (Given 193 that a server never sends any MC_CHANNEL_JOIN frames, the clients 194 also will never send any frames in this document so only the client- 195 to-server advertisement is necessary.) 197 The multicast_client_params parameter has the structure shown below 198 in Figure 1. 200 multicast_client_params { 201 Capabilities Field (i), 202 Max Aggregate Rate (i), 203 Max Channel IDs (i), 204 Hash Algorithms Supported (i), 205 AEAD Algorithms Supported (i), 206 Hash Algorithms List (16 * Hash Algorithms Supported), 207 AEAD Algorithms List (16 * AEAD Algorithms Supported) 208 } 210 Figure 1: multicast_client_params Format 212 Capabilities Flags is a bit field structured as follows: 214 * 0x1 is set if IPv4 channels are permitted 216 * 0x2 is set if IPv6 channels are permitted 218 A server MUST NOT send MC_CHANNEL_PROPERTIES with addresses using an 219 IP Family that is not supported according to the Capabilities in the 220 multicast_client_params, unless and until a later MC_CLIENT_LIMITS 221 frame adds permission for a different address family. 223 The Capabilities Field, Max Aggregate Rate, and Max Channel IDs are 224 the same as in MC_CLIENT_LIMITS frames (Section 11.9) and provide the 225 initial client values. 227 The AEAD Algorithms List field is in order of preference (most 228 preferred occuring first) using values from the registry below. It 229 lists the algorithms the client is willing to use to decrypt data in 230 multicast channels, and the server MUST NOT send a MC_CHANNEL_JOIN to 231 this client for any channels using unsupported algorithms: 233 * https://www.iana.org/assignments/aead-parameters/aead- 234 parameters.xhtml (https://www.iana.org/assignments/aead- 235 parameters/aead-parameters.xhtml) 237 The Hash Algorithms List field is in order of preference (most 238 preferred occurring first) using values from the registry below. It 239 lists the algorithms the client is willing to use to check integrity 240 of data in multicast channels, and the server MUST NOT send a 241 MC_CHANNEL_JOIN to this client for any channels using unsupported 242 algorithms: 244 * https://www.iana.org/assignments/named-information/named- 245 information.xhtml#hash-alg (https://www.iana.org/assignments/ 246 named-information/named-information.xhtml#hash-alg) 248 4. Extension Overview 250 A client has the option of refusal and the power to impose upper 251 bound maxima on several resources (see Section 5), but otherwise its 252 join status for all multicast channels is entirely managed by the 253 server. 255 * A client MUST NOT join a channel without receiving instructions 256 from a server to do so 258 * A client MUST leave joined channels when instructed by the server 259 to do so 261 * A client MAY leave channels or refuse to join channels, regardless 262 of instructions from the server 264 4.1. Channel Management 266 The client tells its server about some restrictions on resources that 267 it is capable of processing with the initial values in the 268 multicast_client_params transport parameter (Section 3) and later can 269 update these limits with MC_CLIENT_LIMITS Section 11.9 frames. 270 Servers ensure the set of channels the client is currently requested 271 to join remains within these advertised client limits as covered in 272 Section 5. 274 The server asks the client to join channels with MC_CHANNEL_JOIN 275 (Section 11.3) frames and to leave channels with MC_CHANNEL_LEAVE 276 (Section 11.4) frames. 278 The server uses MC_CHANNEL_PROPERTIES (Section 11.2) frames before 279 any join or leave frames for the channel to describe the channel 280 properties to the client, including values the client can use to 281 ensure the server's requests remain within the limits it has sent to 282 the server, as well as the keys necessary to decode packets in the 283 channel. 285 When the server has asked the client to join a channel, it also sends 286 MC_CHANNEL_INTEGRITY frames (Section 11.5) to enable the client to 287 verify packet integrity before processing the packet. A client MUST 288 NOT decode packets for a channel for which it has not received an 289 applicable set of MC_CHANNEL_PROPERTIES (Section 11.2) frames 290 containing the full set of data required, or for which it has not 291 received a matching packet hash in an MC_CHANNEL_INTEGRITY 292 (Section 11.5) frame. 294 The server ensures that in aggregate, all channels that the client 295 has currently been asked to join and that the client has not left or 296 declined to join fit within the limits indicated by the initial 297 values in the transport parameter or last MC_CLIENT_LIMITS 298 (Section 11.9) frame the server received. 300 4.2. Client Response 302 The client sends back information about how it has responded to the 303 server's requests to join and leave channels in 304 MC_CLIENT_CHANNEL_STATE (Section 11.11) frames. 305 MC_CLIENT_CHANNEL_STATE frames are only sent for channels after the 306 server has requested the client to join the channel, and are 307 thereafter sent any time the state changes. 309 Clients that receive and decode data on a multicast channel send 310 acknowledgements for the data on a unicast connection using 311 MC_CHANNEL_ACK (Section 11.7) frames. Channels also will 312 periodically contain PATH_CHALLENGE ([RFC9000] Section 19.17) frames, 313 which cause clients to send MC_PATH_RESPONSE (Section 11.8) frames on 314 the unicast connection in addition to their MC_CHANNEL_ACK frames. 316 4.3. Data Carried in Channels 318 Data transmitted in a multicast channel is encrypted with symmetric 319 keys so that on-path observers without access to these keys cannot 320 decode the data. However, since potentially many receivers receive 321 identical packets and identical keys for the multicast channel and 322 some receivers might be malicious, the packets are also protected by 323 MC_CHANNEL_INTEGRITY (Section 11.5) frames transmitted over a 324 separate integrity-protected path. 326 A client MUST NOT decode packets on a multicast channel for which it 327 has not received a matching hash in an MC_CHANNEL_INTEGRITY frame 328 over a different integrity-protected communication path. The 329 different path can be either the unicast connection or another 330 multicast channel with packets that were verified with an earlier 331 MC_CHANNEL_INTEGRITY frame. 333 4.4. Stream Processing 335 Stream IDs in channels are restricted to unidirectional server 336 initiated streams, or those with the least significant 2 bits of the 337 stream ID equal to 3 (see [RFC9000] Section 2.1). 339 Since a server has access to all data in channels it uses, a server 340 can always avoid stream ID collisions with the stream IDs carried in 341 channels, and can usually (depending on the timing) avoid allowing 342 channels to exceed the client's max_streams_uni by requesting that 343 clients leave channels before their limits would be exceeded. 345 However, since clients can join later than a channel began, clients 346 supporting the multicast extensions to QUIC should be prepared to 347 handle stream IDs that do not begin at early values, since by the 348 time a client joins a channel in progress the stream id count might 349 have been increasing for a long time. Clients should therefore begin 350 with a high initial_max_streams_uni or send an early MAX_STREAMS type 351 0x13 value (see Section 19.11 of [RFC9000]) with a high limit. 353 MC_CHANNEL_PROPERTIES can provide a recommended value for 354 max_streams_uni to allow for uninterrupted transport using the 355 multicast channel. 357 Servers also can send MC_CHANNEL_STREAM_BOUNDARY_OFFSET 358 (Section 11.6) frames to indicate an application-layer boundary in a 359 stream carried inside a channel. These frames enable new clients 360 joining a channel to start receiving application data from the 361 indicated stream as though the stream data at that offset had an 362 offset of 0. 364 5. Flow Control 366 The values used for unicast flow control cannot be used to limit the 367 transmission rate of a multicast channel because a single client with 368 a low MAX_STREAM_DATA or MAX_DATA value that did not acknowledge 369 receipt could block many other receivers if the servers had to ensure 370 that channels responded to each client's limits. 372 Instead, clients advertise resource limits that the server is 373 responsible for staying within via MC_CLIENT_LIMITS (Section 11.9) 374 frames and their initial values from the transport parameter 375 (Section 3). The server advertises the expected maxima of the values 376 that can contribute toward client resource limits within a channel in 377 MC_CHANNEL_PROPERTIES (Section 11.2) frames. 379 If the server asks the client to join a channel that would exceed the 380 client's limits with an up-to-date Client Limit Sequence Number, the 381 client should send back a MC_CHANNEL_STATE_CHANGE with "Declined 382 Join" and reason "Property Violation". If the server asks the client 383 to join a channel that would exceed the client's limits with an out- 384 of-date Client Limit Sequence Number or a Channel Property Sequence 385 Number that the client has not yet seen, the client should instead 386 send back a "Declined Join" with "Desynchronized Limit Violation". 387 If the actual contents sent in the channel exceed the advertised 388 limits from the MC_CHANNEL_PROPERTY, clients SHOULD leave the stream 389 with a PROTOCOL_ERROR/Limit Violated state change. 391 6. Congestion Control 393 The server maintains a full view of the traffic received by the 394 client via the ACK frames coupled with the MC_CHANNEL_ACK 395 (Section 11.7) frames. 397 Under sustained persistent loss, the server SHOULD instruct the 398 client such that the aggregate rate of joined channels remains under 399 the data rate successfully received by the client in the recent past. 401 7. Data Integrity 403 TODO: import the [I-D.draft-krose-multicast-security] explanation for 404 why extra integrity protection is necessary (many client have the 405 shared key, so AEAD doesn't provide authentication against other 406 valid clients on its own). 408 7.1. Packet Hashes 410 TODO: explanation and example for how to calculate the packet hash. 411 Note that the hash is on the unencrypted packet because it checks 412 against a specific packet number, which is protected by AEAD. (This 413 approach also may help make better use of crypto hardware offload.) 415 8. Packet Scheduling 416 9. Stateless Reset 418 As clients can unilaterally stop the delivery of multicast packets by 419 leaving the relevant (S,G), channels do not need stateless reset 420 tokens. Clients therefore do not share the stateless reset tokens of 421 channels with the server. Instead, if an endpoint receives packets 422 addressed to an (S,G) that it can not associate with any existing 423 channel, it MAY take the necessary steps to prevent the reception of 424 further such packets, without the need to signal to the server that 425 it should stop sending. 427 If a server or client somehow still detect a stateless reset for a 428 channel, they MUST ignore it. 430 10. Implementation and Operational Considerations 432 11. New Frames 434 11.1. MC_CHANNEL_ANNOUNCE 436 Once a server learns that a client supports multicast through its 437 transport parameters, it can send one or multiple MC_CHANNEL_ANNOUNCE 438 frames (type=TBD-11..TBD-22) to share information about available 439 channels with the client. The MC_CHANNEL_ANNOUNCE frame contains the 440 static properties of a channel that do not change during its 441 lifetime. 443 MC_CHANNEL_ANNOUNCE frames are formatted as shown in Figure 2. 445 MC_CHANNEL_ANNOUNCE Frame { 446 Type (i) = TBD-11..TBD-12 (experiments use 0xff3e811/0xff3e812), 447 ID Length (8), 448 Channel ID (8..160), 449 Source IP (32..128), 450 Group IP (32..128), 451 UDP Port (16), 452 Header AEAD Algorithm (16), 453 Header Key Length (i), 454 Header Key (..), 455 } 457 Figure 2: MC_CHANNEL_ANNOUNCE Frame Format 459 Frames of type TBD-10 are used for IPv4 and both Source and Group 460 address are 32 bits long. Frames of type TBD-11 are used for IPv6 461 and both Source and Group address are 128 bits long. 463 MC_CHANNEL_ANNOUNCE frames contain the following fields: 465 * ID Length: The length in bytes of the Channel ID field. 467 * Channel ID: The channel ID of the channel that is getting 468 announced. 470 * IP Family: Unset indicates IPv4, Set indicates IPv6 for both 471 Source IP and Group IP. 473 * Source IP: The IP Address of the source of the (S,G) for the 474 channel. Either a 32-bit IPv4 address or a 128-bit IPv6 address, 475 as indicated by IP Family. 477 * Group IP: The IP Address of the group of the (S,G) for the 478 channel. Either a 32-bit IPv4 address or a 128-bit IPv6 address, 479 as indicated by IP Family. 481 * UDP Port: The 16-bit UDP Port of traffic for the channel. 483 * Header AEAD Algorithm: A value from 484 https://www.iana.org/assignments/aead-parameters/aead- 485 parameters.xhtml (https://www.iana.org/assignments/aead- 486 parameters/aead-parameters.xhtml), used to protect the header 487 fields in the channel packets. The value MUST match a value 488 provided in the "AEAD Algorithms List" of the transport parameter 489 (see Section 3). 491 * Header Key Length: Provides the length of the Key field. It MUST 492 match a valid key length for the Header AEAD Algorithm. 494 * Header Key: A key for use with the Header AEAD Algorithm for 495 protecting the header fields of 1-RTT packets in the channel as 496 described in [RFC9001]. 498 - *Author's Note:* I assume it's not better to use a TLS 499 CipherSuite because there is no KDF stage for deriving these 500 keys (they are a strict server-to-client advertisement), so the 501 Hash part would be unused? (https://www.iana.org/assignments/ 502 tls-parameters/tls-parameters.xhtml#tls-parameters-4 503 (https://www.iana.org/assignments/tls-parameters/tls- 504 parameters.xhtml#tls-parameters-4)) 506 A client MUST NOT use the channel ID included in the 507 MC_CHANNEL_ANNOUNCE frame as a connection ID for the unicast 508 connection. If it is already in use, the client should retire it as 509 soon as possible. As the server knows which connection IDs are in 510 use by the client, it MUST wait with the sending of a MC_CHANNEL_JOIN 511 frame until the channel ID associated with it has been retired by the 512 client. 514 As the properties in MC_CHANNEL_ANNOUNCE frames are immutable during 515 the lifetime of a channel, a server SHOULD NOT send a 516 MC_CHANNEL_ANNOUNCE frame for the same channel more than once to each 517 client. 519 A server SHOULD send an MC_CHANNEL_ANNOUNCE frame for a channel 520 before sending a MC_CHANNEL_PROPERTIES or MC_CHANNEL_JOIN frame for 521 it. 523 11.2. MC_CHANNEL_PROPERTIES 525 An MC_CHANNEL_PROPERTIES frame (type=TBD-01) is sent from server to 526 client, either with the unicast connection or in an existing joined 527 multicast channel. The MC_CHANNEL_PROPERTIES frame consists of the 528 properties of a channel that are mutable and might change during the 529 course of its lifetime. 531 A server can send an update to a prior MC_CHANNEL_PROPERTIES frame 532 with a new sequence number increased by one. 534 It is RECOMMENDED that servers set an Until Packet Number and send 535 regular updates to the MC_CHANNEL_PROPERTIES before the packet 536 numbers in the channel exceed that value. 538 MC_CHANNEL_PROPERTIES frames are formatted as shown in Figure 3. 540 MC_CHANNEL_PROPERTIES Frame { 541 Type (i) = TBD-01 (experiments use 0xff3e801), 542 ID Length (8), 543 Channel ID (8..160), 544 Properties Sequence Number (i), 545 From Packet Number (i), 546 Until Packet Number (i), 547 AEAD Algorithm (16), 548 Key Length (i), 549 Key (..), 550 Integrity Hash Algorithm (16), 551 Max Rate (i), 552 Max Idle Time (i), 553 Max Streams (i), 554 ACK Bundle Size (i), 555 } 557 Figure 3: MC_CHANNEL_PROPERTIES Frame Format 559 MC_CHANNEL_PROPERTIES frames contain the following fields: 561 * ID Length: The length in bytes of the Channel ID field. 563 * Channel ID: The channel ID for the channel associated with this 564 frame. 566 * Properties Sequence Number: Increases by 1 each time the 567 properties for the channel are changed by the server. The client 568 tracks the sequence number of the MC_CHANNEL_PROPERTIES frame that 569 set its current value, and only updates the value and the packet 570 number range on which it's applicable if the Properties Sequence 571 Number is higher. 573 * From Packet Number, Until Packet Number: The values in this 574 MC_CHANNEL_PROPERTIES frame apply only to packets starting at From 575 Packet Number and continuing for all packets up to and including 576 Until Packet Number. If Until Packet Number is omitted it 577 indicates the current property values for this channel have no 578 expiration at (equivalent to the maximum value for packet numbers, 579 or 2^62-1). If a packet number is received outside of any prior 580 (From,Until) range, it has no applicable channel properties and 581 MUST be dropped. 583 * AEAD Algorithm: A value from https://www.iana.org/assignments/ 584 aead-parameters/aead-parameters.xhtml 585 (https://www.iana.org/assignments/aead-parameters/aead- 586 parameters.xhtml). The value MUST match a value provided in the 587 "AEAD Algorithms List" of the transport parameter (see Section 3). 589 * Key Length: Provides the length of the Key field. It MUST match a 590 valid key length for the AEAD Algorithm. 592 * Key: Used to protect the packet contents of 1-RTT packets for the 593 channel as described in [RFC9001], with length given by Key 594 Length. To maintain forward secrecy and prevent malicious clients 595 from decrypting packets long after they have left or were removed 596 from the unicast connection, servers SHOULD periodically send key 597 updates using only unicast. 599 * Integrity Hash Algorithm: The hash algorithm used in integrity 600 frames. 602 - *Author's Note:* Several candidate iana registries, not sure 603 which one to use? Some have only text for some possibly useful 604 values. For now we use the first of these: 606 o https://www.iana.org/assignments/named-information/named- 607 information.xhtml#hash-alg 608 (https://www.iana.org/assignments/named-information/named- 609 information.xhtml#hash-alg) 611 o https://www.iana.org/assignments/tls-parameters/tls- 612 parameters.xhtml#tls-parameters-18 613 (https://www.iana.org/assignments/tls-parameters/tls- 614 parameters.xhtml#tls-parameters-18) 616 o (text-only): https://www.iana.org/assignments/hash-function- 617 text-names/hash-function-text-names.xhtml 618 (https://www.iana.org/assignments/hash-function-text-names/ 619 hash-function-text-names.xhtml) 621 * Max Rate: The maximum rate in Kibps of the payload data for this 622 channel.Channel data MUST NOT exceed this rate over any 5s window, 623 if it does clients SHOULD leave the channel with reason Max Rate 624 Exceeded. 626 * Max Idle Time: The maximum expected idle time of the channel. If 627 this amount of time passes in a joined channel without data 628 received, clients SHOULD leave the channel with reason Max Idle 629 Time Exceeded. 631 * Max Streams: The maximum stream ID that might appear in the 632 channel. If a client joined to this channel can raise its Max 633 Streams limit up to or above this value it SHOULD do so, otherwise 634 it SHOULD leave or decline join for the channel with Max Streams 635 Exceeded. 637 * ACK Bundle Size:nThe minimum number of ACKs a client should send 638 in a single QUIC packet. If the max_ack_delay would force a 639 client to send a packet that only consists of MC_CHANNEL_ACK 640 frames, it SHOULD instead wait with sending until at least the 641 specified number of acknowledgements have been collected. 642 However, the Client MUST send any pending acknowledgements at 643 least once per Max Idle Time to prevent the Server from perceiving 644 the channel as interrupted. 646 From Packet Number and Until Packet Number are used to indicate the 647 packet number (Section 17.1 of [RFC9000]) the 1-RTT packets received) 648 over which these values are applicable. 650 A From Packet Number without an Until Packet Number has an 651 unspecified termination. 653 If new property values appear and are different from prior values, 654 the From Packet Number implicitly sets the Until Packet Number of the 655 prior property value equal to one below the new From Packet Number 656 for all the changed properties. 658 The properties of a channel MAY change during its lifetime. As such, 659 a server SHOULD NOT send properties for channels except those the 660 client has joined or will be imminently asked to join. 662 11.3. MC_CHANNEL_JOIN 664 An MC_CHANNEL_JOIN frame (type TBD-02) is sent from server to client 665 and requests that a client join the given transport addresses and 666 ports and process packets with the given Channel ID according to the 667 corresponding MC_CHANNEL_PROPERTIES. 669 A client cannot join a multicast channel without first receiving a 670 MC_CHANNEL_ANNOUNCE and MC_CHANNEL_PROPERTIES frame which together 671 set all the values for a channel. 673 If a client receives a MC_CHANNEL_JOIN for a channel for which it has 674 not received both, it MUST respond with a MC_CLIENT_CHANNEL_STATE 675 with State "Declined Join" and reason "Missing Properties". The 676 server MAY send another MC_CHANNEL_JOIN after retransmitting the 677 MC_CHANNEL_PROPERTIES and receiving an acknowledgement indicating 678 receipt of the MC_CHANNEL_ANNOUNCE. 680 MC_CHANNEL_JOIN frames are formatted as shown in Figure 4. 682 MC_CHANNEL_JOIN Frame { 683 Type (i) = TBD-02 (experiments use 0xff3e802), 684 MC_CLIENT_LIMIT Sequence Number (i), 685 MC_CLIENT_CHANNEL_STATE Sequence Number (i), 686 MC_CHANNEL_PROPERTIES Sequence Number (i), 687 ID Length (8), 688 Channel ID (8..160) 689 } 691 Figure 4: MC_CHANNEL_JOIN Frame Format 693 The sequence numbers are the most recently processed sequence number 694 by the server from the respective frame type. They are present to 695 allow the client to distinguish between a broken server that has 696 performed an illegal action and an instruction that's based on 697 updates that are out of sync (either one or more missing updates to 698 MC_CHANNEL_PROPERTIES not yet received by the client or one or more 699 missing updates to MC_CLIENT_LIMITS or MC_CLIENT_CHANNEL_STATE not 700 yet received by the server). 702 A client MAY perform the join if it has the sequence number of the 703 corresponding channel properties and the client's limits will not be 704 exceeded, even if the client sequence numbers are not up-to-date. If 705 the client does not join, it MUST send a MC_CLIENT_CHANNEL_STATE with 706 "Declined Join" and a reason. 708 11.4. MC_CHANNEL_LEAVE 710 An MC_CHANNEL_LEAVE frame (type=TBD-03) is sent from server to client 711 in either the unicast connection or a channel. 713 MC_CHANNEL_LEAVE frames are formatted as shown in Figure 5. 715 MC_CHANNEL_LEAVE Frame { 716 Type (i) = TBD-03 (experiments use 0xff3e803), 717 MC_CLIENT_CHANNEL_STATE Sequence Number (i), 718 ID Length (8), 719 Channel ID (8..160), 720 After Packet Number (i) 721 } 723 Figure 5: MC_CHANNEL_LEAVE Frame Format 725 If After Packet Number is nonzero, wait until receiving that packet 726 or a higher valued number before leaving. 728 11.5. MC_CHANNEL_INTEGRITY 730 MC_CHANNEL_INTEGRITY frames are sent from server to client and are 731 used to convey packet hashes for validating the integrity of packets 732 received over the multicast channel as described in Section 7.1. 734 MC_CHANNEL_INTEGRITY frames are formatted as shown in Figure 6. 736 MC_CHANNEL_INTEGRITY Frame { 737 Type (i) = TBD-04..TBD-05 (experiments use 0xff3e804/0xff3e805), 738 ID Length (8), 739 Channel ID (8..160), 740 Packet Number Start (i), 741 [Length (i)], 742 Packet Hashes (..) 743 } 745 Figure 6: MC_CHANNEL_INTEGRITY Frame Format 747 For type TBD-05, Length is present and is a count of packet hashes. 748 For TBD-04, Length is not present and the packet hashes extend to the 749 end of the packet. 751 The first hash in the Packet Hashes list is a hash of a 1-RTT packet 752 with the Channel ID equal to the Channel ID in the 753 MC_CHANNEL_INTEGRITY frame and packet number equal to the Packet 754 Number Start field. Subsequent hashes refer to the packets for the 755 channel with packet numbers increasing by 1. 757 Packet hashes MUST have length with an integer multiple of the length 758 indicated by the Hash Algorithm from the Channel Properties. 760 See Section 7.1 for a description of the packet hash calculation. 762 11.6. MC_CHANNEL_STREAM_BOUNDARY_OFFSET 764 MC_CHANNEL_STREAM_BOUNDARY_OFFSET frames are formatted as shown in 765 Figure 7. 767 MC_CHANNEL_STREAM_BOUNDARY_OFFSET Frame { 768 Type (i) = TBD-06 (experiments use 0xff3e806), 769 ID Length (8), 770 Channel ID (8..160), 771 Stream ID (i), 772 Stream Offset (i) 773 } 775 Figure 7: MC_CHANNEL_STREAM_BOUNDARY_OFFSET Frame Format 777 Clients must discard data before Stream Offset, and should start 778 accepting stream data at Stream Offset as though it's a new stream 779 with offset 0. 781 A server must ensure that data beginning at the given stream offsets 782 could equivalently begin a new stream, and are safe for clients to 783 start processing in order to use this. (Well-suited for boundaries 784 of http server push objects, for example, which otherwise would need 785 to start a new stream per object in order to be usable by late 786 joiners.) 788 11.7. MC_CHANNEL_ACK 790 Client->Server on unicast connection. 792 (TODO: Is it possible to reuse the multiple packet number space 793 version of ACK_MP from Section 12.2 of 794 [I-D.draft-ietf-quic-multipath], defining channel id as the packet 795 number space? at 2022-04-12 they're identical.) 797 MC_CHANNEL_ACK frames are formatted as shown in Figure 8. 799 MC_CHANNEL_ACK Frame { 800 Type (i) = TBD-07 (experiments use 0xff3e807), 801 ID Length (8), 802 Channel ID (8..160), 803 Largest Acknowledged (i), 804 ACK Delay (i), 805 ACK Range Count (i), 806 First ACK Range (i), 807 ACK Range (..) ..., 808 [ECN Counts (..)], 809 } 811 Figure 8: MC_CHANNEL_ACK Frame Format 813 11.8. MC_PATH_RESPONSE 815 MC_PATH_RESPONSE frames are sent from client to server in a unicast 816 connection in response to an PATH_CHALLENGE received in a channel. 817 Like PATH_RESPONSE but includes a channel id. 819 MC_PATH_RESPONSE frames are formatted as shown in Figure 9. 821 MC_PATH_RESPONSE Frame { 822 Type (i) = TBD-08 (experiments use 0xffe38008), 823 ID Length (8), 824 Channel ID (8..160), 825 Data (64) 826 } 828 Figure 9: MC_PATH_RESPONSE Frame Format 830 11.9. MC_CLIENT_LIMITS 832 MC_CLIENT_LIMITS frames are formatted as shown in Figure 10. 834 MC_CLIENT_LIMITS Frame { 835 Type (i) = TBD-09 (experiments use 0xff3e809), 836 Client Limits Sequence Number (i), 837 Capabilities Flags(i), 838 Max Aggregate Rate (i), 839 Max Channel IDs (i), 840 Max Joined Count (i), 841 } 843 Figure 10: MC_CLIENT_LIMITS Frame Format 845 The sequence number is implicitly 0 before the first MC_CLIENT_LIMITS 846 frame from the client, and increases by 1 each new frame that's sent. 847 Newer frames override older ones. 849 Capabilities Flags is a bit field structured as follows: 851 * 0x1 is set if IPv4 channels are permitted 853 * 0x2 is set if IPv6 channels are permitted 855 For example, a Capabilities Flags value of 3 (0x11) indicates that 856 both IPv4 and IPv6 channels are permitted. 858 Max Aggregate Rate allowed across all joined channels is in Kibps. 860 Max Channel IDs is the count of channel IDs that can be reserved and 861 have properties. Retired Channel IDs don't count against this value. 863 Max Joined Count is the count of channels that are allowed to be 864 joined concurrently. 866 11.10. MC_CHANNEL_RETIRE 868 MC_CHANNEL_RETIRE frames are formatted as shown in Figure 11. 870 MC_CHANNEL_RETIRE Frame { 871 Type (i) = TBD-0a (experiments use 0xff3e80a), 872 ID Length (8), 873 Channel ID (8..160) 874 } 876 Figure 11: MC_CHANNEL_RETIRE Frame Format 878 Retires a channel by id. (We can't use RETIRE_CONNECTION_ID because 879 we don't have a coherent sequence number.) 881 11.11. MC_CLIENT_CHANNEL_STATE 883 MC_CLIENT_CHANNEL_STATE frames are formatted as shown in Figure 12. 885 MC_CLIENT_CHANNEL_STATE Frame { 886 Type (i) = TBD-0b (experiments use 0xff3e80b), 887 Client Channel State Sequence Number (i), 888 ID Length (8), 889 Channel ID (8..160), 890 State (i), 891 Reason (0..i) 892 } 893 Figure 12: MC_CLIENT_CHANNEL_STATE Frame Format 895 State has these defined values: 897 * 0x1: Left 899 * 0x2: Declined Join 901 * 0x3: Joined 903 If State is Joined, the Reason field is absent. 905 If State is Left or Declined Join, the Reason field is set to one of: 907 * 0x0: Unspecified Other 909 * 0x1: Left as requested by server 911 * 0x2: Administrative Block 913 * 0x3: Protocol Error 915 * 0x4: Property Violation 917 * 0x5: Unsynchronized Properties 919 * 0x6: ID Collision 921 * 0x10: Held Down 923 * 0x11: Max Idle Time Exceeded 925 * 0x12: Max Rate Exceeded 927 * 0x13: High Loss 929 * 0x14: Spurious Traffic 931 * 0x1000000-0x3fffffff: Application-specific Reason 933 A client might receive multicast packets that it can not associate 934 with any channel ID. If these are addressed to an (S,G) that is used 935 for reception in one or more known channels, it MAY leave these 936 channels with reason "Spurious traffic". 938 (TODO: Or should we try to reuse PATH_ABANDON and/or PATH_STATUS? I 939 don't think they're sufficient, but maybe?): - 940 [I-D.draft-ietf-quic-multipath] - 941 https://datatracker.ietf.org/doc/html/draft-liu-multipath-quic- 942 04#section-9.1 (https://datatracker.ietf.org/doc/html/draft-liu- 943 multipath-quic-04#section-9.1) 945 The things server needs to know for state changes _could_ maybe be 946 inferred from ack responses but explicit seems better, allowing for a 947 more proactive response under strain? 949 12. Frames Carried in Channel Packets 951 MC Channels will contain normal QUIC 1-rtt data packets (see 952 Section 17.3.1 of [RFC9000]) except using the Channel ID instead of a 953 Connection ID. The packets are protected with the keys from 954 MC_CHANNEL_PROPERTIES for the corresponding channel. 956 Data packet hashes will also be sent in MC_CHANNEL_INTEGRITY frames, 957 as keys cannot be trusted for integrity due to giving them to too 958 many receivers, as in [I-D.draft-krose-multicast-security]. 960 The 1-rtt packets in multicast channels will have a restricted set of 961 frames. Since the channel is strictly 1-way server to client, the 962 general principle is that broadcastable shared server->client data 963 frames can be sent, but frames that make sense only for 964 individualized connections cannot. 966 Permitted: 968 * PADDING Frames ([RFC9000] Section 19.1) 970 * PING Frames ([RFC9000] Section 19.2) 972 * RESET_STREAM Frames ([RFC9000] Section 19.4) 974 * STREAM Frames ([RFC9000] Section 19.8) 976 * DATAGRAM Frames (both types) ([RFC9221] Section 4) 978 * PATH_CHALLENGE Frames ([RFC9000] Section 19.17) 980 * MC_CHANNEL_PROPERTIES 982 * MC_CHANNEL_LEAVE (however, join must come over unicast?) 984 * MC_CHANNEL_INTEGRITY (not for this channel, only for another) 986 * MC_STREAM_BOUNDARY_OFFSET 988 * MC_CHANNEL_RETIRE 989 Not permitted: 991 * 19.3. ACK Frames 993 * 19.6. CRYPTO Frames (crypto handshake does not happen on mc 994 channels) 996 * 19.7. NEW_TOKEN Frames 998 * Flow control is different: 1000 - 19.5. STOP_SENDING Frames 1002 - 19.9. MAX_DATA Frames (flow control for mc channels is by 1003 rate) 1005 - 19.10. MAX_STREAM_DATA Frames 1007 - 19.11. MAX_STREAMS Frames 1009 - 19.12. DATA_BLOCKED Frames 1011 - 19.13. STREAM_DATA_BLOCKED Frames 1013 - 19.14. STREAMS_BLOCKED Frames 1015 * Channel ID Migration can't use the "prior to" concept, not 1016 0-starting 1018 - 19.15. NEW_CONNECTION_ID Frames 1020 - 19.16. RETIRE_CONNECTION_ID Frames 1022 * 19.18. PATH_RESPONSE Frames 1024 * 19.19. CONNECTION_CLOSE Frames 1026 * 19.20. HANDSHAKE_DONE Frames 1028 * MC_PATH_RESPONSE 1030 * MC_CLIENT_LIMITS 1032 * MC_CLIENT_CHANNEL_STATE 1034 * MC_CHANNEL_ACK 1036 13. Error Codes 1038 14. Security Considerations 1040 Mostly incorporate [I-D.draft-krose-multicast-security]. Anything 1041 else? 1043 e.g. if a different legitimate quic connection says someone else's 1044 quic multicast stream is theirs, that's maybe a problem worth 1045 protecting against. Maybe we need a periodic asymmetric challenge? 1046 I'm thinking send a public key on the multicast channel and in the 1047 unicast channels send an individualized MAC signed with the private 1048 key and verify it with the public key, so that in addition to 1049 validating that the unicast server knows the contents of the 1050 multicast packets via the hashes it supplies, the multicast stream 1051 provides a way for the client to validate that the unicast stream is 1052 authorized to use it for data transport via proof they know the 1053 private key corresponding to the public key that arrived on the 1054 multicast channel. (Note this doesn't prevent unauthorized receipt 1055 of multicast data packts, but does prevent a quic server from lying 1056 when claiming a multicast data channel belongs to it, preventing 1057 legit receivers from consuming it.) 1059 (alternatively, can the multicast channel just periodically say what 1060 domain name is expected for the quic connection and get the same 1061 crypto guarantee of a proper sender via the domain's cert, which was 1062 already checked on the unicast channel?) 1064 15. IANA Considerations 1066 TODO: lots 1068 16. References 1070 16.1. Normative References 1072 [I-D.draft-ietf-quic-multipath] 1073 Liu, Y., Ma, Y., Coninck, Q. D., Bonaventure, O., Huitema, 1074 C., and M. Kuehlewind, "Multipath Extension for QUIC", 1075 Work in Progress, Internet-Draft, draft-ietf-quic- 1076 multipath-00, 2 February 2022, 1077 . 1080 [I-D.draft-krose-multicast-security] 1081 Rose, K. and J. Holland, "Security and Privacy 1082 Considerations for Multicast Transports", Work in 1083 Progress, Internet-Draft, draft-krose-multicast-security- 1084 02, 31 January 2022, . 1087 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 1088 Requirement Levels", BCP 14, RFC 2119, 1089 DOI 10.17487/RFC2119, March 1997, 1090 . 1092 [RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC 1093 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, 1094 May 2017, . 1096 [RFC9000] Iyengar, J., Ed. and M. Thomson, Ed., "QUIC: A UDP-Based 1097 Multiplexed and Secure Transport", RFC 9000, 1098 DOI 10.17487/RFC9000, May 2021, 1099 . 1101 [RFC9001] Thomson, M., Ed. and S. Turner, Ed., "Using TLS to Secure 1102 QUIC", RFC 9001, DOI 10.17487/RFC9001, May 2021, 1103 . 1105 [RFC9221] Pauly, T., Kinnear, E., and D. Schinazi, "An Unreliable 1106 Datagram Extension to QUIC", RFC 9221, 1107 DOI 10.17487/RFC9221, March 2022, 1108 . 1110 16.2. Informative References 1112 [RFC4607] Holbrook, H. and B. Cain, "Source-Specific Multicast for 1113 IP", RFC 4607, DOI 10.17487/RFC4607, August 2006, 1114 . 1116 Acknowledgments 1118 TODO acknowledge. 1120 Authors' Addresses 1122 Jake Holland 1123 Akamai Technologies, Inc. 1124 Email: jakeholland.net@gmail.com 1126 Lucas Pardue 1127 Email: lucaspardue.24.7@gmail.com 1129 Max Franke 1130 TU Berlin 1131 Email: mfranke@inet.tu-berlin.de