Blockcast

omar@blockcast.net

wit moq multicast MoQ AMT SSM TreeDN This document specifies multicast delivery mechanisms and catalog-based endpoint discovery for Media over QUIC (MoQ). It defines how MoQ sessions integrate with IP multicast (SSM, ASM), Automatic Multicast Tunneling (AMT), and TreeDN for scalable live streaming. The specification includes a multicast catalog extension for endpoint discovery and multi-path delivery across TV, mobile, and browser platforms. All multicast delivery uses MMTP packets, the same packet format used on MoQ QUIC streams and datagrams. A manifest-based content-authentication profile protects multicast delivery.

Introduction Unicast delivery, including Media over QUIC (MoQ) , replicates a stream per receiver; IP multicast replicates it in the network. This document specifies how MoQ integrates with IP multicast to combine the scalability of multicast with the reliability and signaling of QUIC:

1. Delivery paths: Platform-specific multicast reception for TV, mobile, and browser clients
2. Catalog extension: A container-agnostic multicast endpoint discovery mechanism for MoQ catalogs
3. MMTP wire format: All multicast delivery uses MMTP packets -- the same packet format used on MoQ QUIC streams and datagrams (Section 5).
4. Multi-path delivery: Combining MoQ unicast and multicast for seamless failover and FEC symbol deduplication

MoQ relays MAY operate as TreeDN nodes for hierarchical distribution.

Multicast as Supplement to MoQ Unicast Multicast delivery as defined in this document is a supplement to MoQ/QUIC unicast. Subscribers MUST establish a MoQ session first to receive the catalog, negotiate parameters, and receive initial media. Multicast MAY then be used as an optimized delivery path for ongoing media data. This ensures that codec configuration is available before multicast reception begins. Exception: MMTP-packaged streams delivered via ATSC 3.0 broadcast or native SSM MAY operate as unidirectional data streams without a MoQ session. MMTP carries per-packet routing (packet_id), timing (timestamp), sequencing (Packet Sequence Number), and FEC framing (FEC Type, FEC payload IDs) natively, and its signaling messages identify the Assets in band: every Asset sent to a multicast endpoint is named by a PA message on its sending entity's packet_id 0 signaling sub-flow, whose MP table locates the Asset by source address, group address, port and packet_id (Section 5). A receiver without the catalog takes the FEC configuration from the AL-FEC message ( Section 8.3) when the flow carries one. A receiver that holds the catalog takes both from the catalog, which remains authoritative for it (Section 4.1; Section 5.2). ATSC 3.0 and ARIB STD-B60 receivers consume MMTP over SSM as their native delivery path.

Terminology The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in BCP 14 when, and only when, they appear in all capitals, as shown here. SSM: Source-Specific Multicast AMT: Automatic Multicast Tunneling DRIAD: DNS Reverse IP AMT Discovery TreeDN: Tree-based Content Delivery Network MMTP: MMT Protocol -- the packet layer of MPEG Media Transport ( Clause 9; Section 3). MMT sending entity: The entity that packetizes media into MMTP packets and sends them on one or more multicast endpoints. It is the scope over which Section 4.1 assigns each packetId value to exactly one MMTP packet sub-flow, and it serves exactly one MoQ namespace (Section 4.1).

Delivery Paths MoQ content can reach receivers via multiple delivery paths depending on platform capabilities:

Client Type	Multicast Path
Native (TV, mobile)	SSM direct via OS multicast API
Native (no multicast)	AMT tunneling over UDP
Browser with UDP socket access (e.g., )	SSM/AMT
Browser (standard)	MoQ/WebTransport (unicast)

Both native SSM and AMT tunneling require UDP socket access. MoQ/WebTransport is the universal fallback and requires no special platform capabilities. Broadcast receivers (ATSC 3.0, ARIB STD-B60) consume MMTP streams natively over RF tuner hardware. MoQ integration occurs at the gateway/head-end level via TreeDN and AMT / DRIAD . Multiple transports MAY be available for a given stream. When more than one delivery path is available, receivers SHOULD prefer, in order: tuner-based broadcast reception (where tuner hardware exists), native SSM, AMT tunneling, and finally MoQ/QUIC unicast. Local policy MAY override this order. Within tuner-based reception, receivers SHOULD prefer Single Frequency Network (SFN) diversity reception, where deployed, over single-transmitter reception.

Multicast Catalog Extension For tracks available via multicast, the MoQ catalog includes a top-level multicast field containing an endpoints array for endpoint discovery. The catalog is the MSF catalog track, named catalog ( Section 5; Section 12).

Multicast Endpoint Format The multicast field is a root-level extension member of the MSF catalog; the catalog envelope for this suite is described in Section 12. Section 5 permits producers to add fields and requires parsers to ignore fields they do not understand: parsers that do not support multicast MUST ignore it. The multicast field contains an endpoints array listing one or more multicast groups. A single-endpoint deployment uses a one-element array: Multi-group deployments (e.g., per-quality ABR tiers or separate audio/video groups) use multiple elements: The multicast object contains the following members: endpoints (array of objects, REQUIRED): One or more multicast endpoint objects as defined below. The array MUST NOT be empty. networkSource (array of objects, OPTIONAL): Network delivery configuration applying to all endpoints; see Section 4.2. auth (object, OPTIONAL): Content authentication configuration for the bc-provenance profile; see Section 7.2. Endpoint field definitions: sourceAddress (string, OPTIONAL): SSM source IP address per . Its presence selects SSM and its absence Any-Source Multicast (ASM). protocol (string, OPTIONAL): "ssm" or "asm", restating that mode. An endpoint where it disagrees with sourceAddress is ignored (see below). groupAddress (string, REQUIRED): Multicast group address.

• SSM range: 232.0.0.0/8 (IPv4), ff3x::/32 (IPv6)
• ASM range: 224.0.0.0/4 (IPv4), ff0x::/16 (IPv6)

port (integer, REQUIRED): UDP port number. tracks (array, REQUIRED): Tracks available on this endpoint. Each element is an object with the following fields:

• name (string, REQUIRED): Track name corresponding to the track identifier used in the MoQ catalog.
• packetId (integer, REQUIRED): MMTP packet_id used for packet-level track routing on multicast. Maps directly to the Packet ID field in the MMTP header (Section 3.1 of ). The value is an integer in the range 1..65535. Each value MUST denote exactly one MMTP packet sub-flow across all endpoints of the MMT sending entity (Section 2) for the lifetime of the delivery session, not merely within one (sourceAddress, groupAddress, port) tuple; two distinct sub-flows MUST NOT share a value ( Clause 9.2.3). A sub-flow is one sequence of packets with one packet_sequence_number space. An endpoint that carries another endpoint's sub-flow packet for packet therefore carries it under the same value, and every other sub-flow takes a value of its own. The rungs of a ladder never share a value. A catalog track denotes one sub-flow: every endpoint that lists a track carries that track's one sub-flow, under one value. Media that the sending entity packetizes separately for several endpoints, such as audio packetized once per rung, MUST be published as a separate track for each packetization, with its own name, value, fec object and repair tracks, because the copies differ in the bytes that FEC protects ( Section 7.3). packet_id 0 is reserved for the sending entity's MMTP signaling sub-flow ( Section 3.1; Section 5), which arrives on the same tuples as the media; a publisher MUST NOT advertise it for a track.

bandwidth (integer, RECOMMENDED): Aggregate bandwidth of this endpoint in bits per second, defined as the sum of the UDP payload bitrates of all tracks carried on the endpoint, including repair tracks, plus the MMTP signaling sub-flow on packet_id 0 (Section 5) where the endpoint carries it; IP/UDP header overhead is excluded. Publishers SHOULD include bandwidth to enable capacity-aware join decisions. Subscribers SHOULD check available network capacity before joining high-bandwidth groups. networkSource (array of objects, OPTIONAL): Network delivery configuration for this endpoint; see Section 4.2. Each (sourceAddress, groupAddress, port) multicast tuple MUST be associated with at most one MoQ namespace. Publishers requiring multiple independent streams MUST use distinct multicast groups or ports. An MMT sending entity (Section 2) serves exactly one MoQ namespace, which is one MMT Package (Section 5); a publisher that serves several namespaces acts as several sending entities, each with its own endpoints, its own packetId assignment and its own packet_id 0 signaling sub-flow. Receivers MUST ignore endpoints whose fields are mutually inconsistent -- for example, a protocol of "ssm" with sourceAddress omitted, a sourceAddress present with protocol of "asm", or a groupAddress outside the multicast address space. Receivers MUST likewise ignore an endpoint that lists a track packetId outside the range 1..65535, including 0, the MMTP signaling flow. Subscribers receiving a catalog with multicast endpoints MAY auto-connect to the multicast group when multicast APIs are available and multicast delivery is preferred (UDP socket access, native or AMT). Multicast joins create IGMP/MLD state on intermediate routers; subscribers SHOULD only join when multicast provides a concrete benefit over unicast. Joining an SSM endpoint requires source-specific group membership signaling: receivers MUST use IGMPv3 (IPv4) or MLDv2 (IPv6) to convey (S,G) joins. Earlier protocol versions (IGMPv2/MLDv1) cannot express source-specific joins; if the receiver's network segment operates at an earlier version (for example, due to an IGMPv2 querier or snooping switch on the segment), SSM joins fail silently. Receivers SHOULD detect the absence of multicast data following a join and fall back to MoQ/QUIC unicast (Section 6). During multicast join (which may take 1-3 seconds for IGMP/MLD), subscribers SHOULD continue receiving via MoQ/QUIC. Once multicast data arrives, subscribers switch to the multicast path. If multicast reception fails or degrades, subscribers fall back to MoQ/QUIC unicast per Section 6. Receivers SHOULD implement hysteresis to prevent flapping between multicast and unicast paths. Switch away from multicast after sustained loss or consecutive FEC block failures; switch back only after multicast reception is stable for a sufficient period. Specific thresholds are implementation-defined and SHOULD be tunable.

Network Source Types The networkSource field is an array of network-source objects describing how subscribers can reach the multicast stream when native IP multicast routing is not available. It MAY appear at the multicast level (applying to all endpoints) or on individual endpoints; a single source is expressed as a one-element array. Each network-source object contains: type (string, REQUIRED): Delivery technology identifier. Defined types:

AMT (Automatic Multicast Tunneling) relay (string, OPTIONAL): AMT relay address (IP or hostname). port (integer, OPTIONAL): UDP port on which the AMT relay accepts requests. When absent, the IANA-assigned AMT port (2268, ) is used. discovery (string, OPTIONAL): AMT relay discovery method.

• "driad": DNS Reverse IP AMT Discovery per . Subscribers query the source IP's reverse DNS for AMT relay records. This is the RECOMMENDED discovery method.
• "manual": Relay address is provided in the relay field.

Subscribers SHOULD attempt relay discovery in this order:

1. Use relay directly if provided
2. Use DRIAD discovery on the SSM source IP if discovery is "driad" or omitted
3. Fall back to MoQ/QUIC unicast

Note: DRIAD requires TYPE260 reverse DNS records on the source IP. DRIAD relay addresses are typically anycast -- subscribers connect to the topologically nearest relay without additional configuration. Publishers without reverse DNS control SHOULD provide the relay field directly.

ATSC 3.0 (Broadcast Television) frequency (integer, REQUIRED): RF center frequency in kHz. plpId (integer, OPTIONAL): Physical Layer Pipe ID. Defaults to 0 (base PLP). serviceId (integer, OPTIONAL): Service ID within the broadcast multiplex. slsUri (string, OPTIONAL): URI for Service Layer Signaling (SLS) bootstrap. Enables receivers joining via IP (not RF) to acquire the full ATSC 3.0 SLS including S-TSID with FEC parameters. Receivers with ATSC 3.0 tuner hardware can receive the stream directly over RF. MoQ subscribers without tuner hardware ignore this networkSource type.

Multiple Network Sources When a stream is available via multiple delivery technologies, the networkSource array lists one element per technology: Subscribers select the highest-priority available source per the transport hierarchy defined in Section 3.

Multicast Packet Format All multicast delivery uses MMTP packets. Each UDP datagram carries one MMTP packet -- the same packet format used on MoQ QUIC streams and datagrams. MMTP provides track routing (packet_id), send timestamps, sequencing (packet_sequence_number), FEC framing (FEC Type and the Source/Repair FEC Payload IDs) and random access signaling (RAP flag) in its packet header, and fragmentation (FI) in the MPU-mode payload header ( Sections 3.1 and 4.2). For a MoQ receiver, FEC configuration, including the RaptorQ OTI, comes from the catalog ( Sections 4.2 and 5.2); a receiver without the catalog relies on the in-band signaling below. Frame-sized LOC or CMAF objects exceed a UDP datagram; the MMTP MPU-mode payload format fragments media into MTU-sized packets ( Clause 9.3.2; Section 5.2), so multicast carriage uses MMTP regardless of a track's unicast packaging. No additional multicast framing, encapsulation, or header format is needed. The MMTP packet format is defined in Clause 9.2, as profiled in Section 3.1. This design means the same MMTP packet can be delivered via four transports without modification:

Transport	Encapsulation
Reliable QUIC stream	MMTP packet as MoQ stream object
QUIC datagram	MMTP packet as MoQ datagram object
Multicast QUIC	MMTP packet as multicast QUIC DATAGRAM object
Multicast UDP	MMTP packet as UDP datagram

Receivers on multicast demultiplex packets using the MMTP packet_id field, which maps to the packetId assigned in the multicast catalog endpoint (Section 4.1). A receiver MUST NOT deliver to any media or repair decoder a packet whose packet_id is not advertised for a track, for the (sourceAddress, groupAddress, port) tuple on which the packet arrived, by an endpoint that the receiver has not ignored under Section 4.1. Packets of the MMTP signaling flow (packet_id 0) are handled per Section 3.1. FEC source and repair packets are distinguished by the MMTP FEC Type field ( Section 3.1). A publisher MUST identify in band the Assets of every MMTP packet flow that it sends to a multicast endpoint, whether a receiver obtains the flow over native SSM or ASM or through an AMT relay (Section 4.2.1). It does so with one MMTP signaling sub-flow per MMT sending entity (Section 2): a single sequence of packets on packet_id 0, with one packet_sequence_number space, that every endpoint listing a track other than a fec-repair track carries packet for packet, as Section 4.1 requires of any sub-flow carried on several endpoints ( Clause 9.2.3). All endpoints of the sending entity carry one Package. The sub-flow carries a PA message (message_id 0x0000; Clause 10.3.2, Table 21), in the signaling message mode of Section 3.1, with the tables that Clause 10.3.1 requires of a PA message, among them a PA table (Clause 10.3.7, Table 26) and the complete MP table of the Package (table_id 0x20, Clause 10.3.9, Table 29), never a subset. The MP table MUST describe as an Asset each track, other than a fec-repair track ( Section 5.1), that any endpoint of the sending entity lists, and MUST locate it at each endpoint that carries it, and at no other, by an MMT_general_location_info of location_type 0x01 (IPv4) or 0x02 (IPv6) that gives the endpoint's group address and port, the track's packetId, and, as ipv4_src_addr or ipv6_src_addr, the address from which the sending entity transmits that endpoint's flow, which is the source address of its IP packets ( Clause 10.6.1). On an SSM endpoint that address equals the endpoint's sourceAddress (Section 4.1); an ASM endpoint, whose catalog entry has no sourceAddress, still carries the sending entity's own address there. A receiver matches a location by destination address, destination port, packet_id and source address: on an SSM endpoint the source address is the endpoint's sourceAddress, and on an ASM endpoint it is the source address of the received packets, which tells this sending entity's flow apart from any other sender on the group. A receiver behind an AMT relay compares against the encapsulated IP header, which keeps the original source address ( Section 5.1.6). Because the sending entity knows its own source address for every endpoint, the PA message is identical on every endpoint, and its one version sequence applies everywhere, so a newer version overrides an older one on all endpoints alike ( Clauses 10.2.3 and 10.3.9.3). Repair flows are not Assets, and the MP table does not list them; their in-band signaling is the AL-FEC message of Section 8.3, which travels on the same sub-flow. The publisher MUST send a PA message on the sub-flow ahead of the MPU metadata (FT=0) data unit of every MPU of every track that it sends to an endpoint, later than the FT=0 data unit of the previous MPU of the same track, and ahead of any other signaling message sent for that MPU, such as the AL-FEC message, so that a receiver joining any endpoint at an MPU boundary holds the mapping before that MPU's media and other signaling; Clause 10.3.2.1 requires a receiver to process a PA message before any other signaling message. A receiver joined to several endpoints receives each packet of the sub-flow once per endpoint, as identical copies with the same packet_sequence_number; it acts on one copy of each packet, whether a PA message or an AL-FEC message, and ignores the rest. An endpoint that lists only fec-repair tracks (a repair-only endpoint, Section 6.3.6) carries no Asset and need not carry the sub-flow. A receiver that holds the catalog routes a repair-only endpoint's packetId values from the catalog ( Section 6.3.6). A receiver without the catalog cannot discover a repair-only endpoint, because the MP table locates only Assets and the AL-FEC message names a repair flow by packetId without a location, so repair carried on a repair-only endpoint reaches only catalog-holding receivers. For a receiver that holds the catalog, the endpoint's packetId values remain authoritative: it routes packets by them as above, needs no PA message, and handles packet_id 0 per Section 3.1. A PA message is never carried as a MoQ object ( Section 4.2). The Multicast QUIC row corresponds to , which adds QUIC's per-packet AEAD and integrity. The mapping of MMTP packets onto its DATAGRAM frames, and the use of on that channel, are specified in Section 11.3.

Multi-Path Delivery The same media content (source and repair) can be transmitted over both MoQ unicast (QUIC/WebTransport) and multicast (UDP/SSM/AMT) paths simultaneously. Because the same MMTP packets are used on all transports, receivers can combine symbols from any path for FEC recovery . When symbols arrive from multiple paths simultaneously, receivers:

1. MUST deduplicate symbols within one FEC instance ( Section 6.4.1) -- a source track's base instance together with all of its repair layers, or its keyframe overlay -- using SS_ID as the unique key of a source symbol and (SS_Start, RS_ID) as that of a repair symbol ( Section 8.3)
2. MAY combine source and repair symbols received on different paths in either direction: source symbols via multicast with repair symbols via MoQ/QUIC, or source symbols via reliable MoQ/QUIC with repair symbols via lossy multicast -- skipping FEC decoding when all source symbols arrive reliably

Multicast-to-unicast failover: if multicast reception fails, subscribers fall back to MoQ/QUIC unicast by subscribing with the Largest Object filter (to resume at the live edge) or the Next Group Start filter (to resume at the next group boundary) per . No coordinate mapping between multicast SS_IDs and MoQ Group IDs is needed -- the relay provides the current position. Failover replaces the multicast path; it is distinct from per-block unicast repair (Section 6.2), which leaves the multicast subscription in place.

Packaging Negotiation Packaging is advertised per track in the catalog, and a subscriber subscribes by name to the tracks whose packaging it supports. The altGroup catalog field ( Section 5.2.12, profiled in Section 4.4) groups alternatives of the same content in different packaging formats.

Per-Block Unicast Repair A multicast or AMT receiver repairs every FEC block in-band from the repair symbols it receives on its multicast paths. For a block that in-band FEC leaves unrecovered at its FEC deadline, a receiver that holds a MoQ session (Section 1.1) applies the receiver repair policy of Section 11.4, which repairs a keyframe-bearing block by a standalone FETCH of the block's repair-track group. That group's ID is the block's SS_Start, from the Repair FEC Payload ID of a multicast repair packet of the block, extended to 62 bits with the wrap epoch of Section 7.5. A receiver that takes its repair from multicast has usually received no repair-track Group ID over MoQ, so before its first FETCH it establishes that epoch from the Largest Location that a TRACK_STATUS request for the repair track reports ( Section 9.13): the Group of the LARGEST_OBJECT parameter in the REQUEST_OK (TRACK_STATUS_OK) that answers the request, as Section 7.5 specifies, unless it has received such a Group ID or has observed the FEC instance from its first block. For lost source packets whose block it has not delimited, because it holds no repair packet of that block, the receiver instead fetches the Group range that Section 7.5 derives from a lost SS_ID. No other coordinate mapping is needed, and the returned symbols are deduplicated per item 1 of Section 6. A receiver without a MoQ session cannot request unicast repair; it relies on in-band FEC and, where published, the keyframe overlay ( Section 6.4). A FETCH for a repair-track group that the relay no longer retains fails or returns none of the group's objects, and the receiver then treats the block as unrecoverable. How long a relay retains repair-track groups is relay policy.

Security Considerations

Multicast Security SSM inherently limits traffic to authorized sources via (S,G) filtering. Receivers MAY detect replayed packets by tracking the MMTP Packet Sequence Number per packet_id within one (source address, groupAddress, port) tuple and discarding duplicates and packets outside a bounded reordering window. The source address is that of the received packets, the same address Section 5 matches: it equals sourceAddress on an SSM endpoint and is read from each packet on an ASM endpoint, so two sending entities that share an ASM group and each use the same packet_id are tracked separately. For AMT, trust is delegated to the relay per .

Content Authentication Multicast UDP delivery lacks the integrity protection that QUIC provides on unicast paths. This section defines "bc-provenance", a manifest-provenance authentication profile. The publisher computes, per MoQ group per protected track, an ordered digest structure over the group's objects; signs its root with a dedicated broadcast Ed25519 key ; and publishes the signed manifest on a dedicated MoQ track. Receivers verify each object -- received or FEC-recovered -- against the group root before admitting it to reassembly and decode. Verification cost is one signature verification per group; all digests use BLAKE3 . Per-packet signatures suit only low-rate signaling flows; media tracks use this profile.

Manifest Track The publisher publishes one manifest object per media group, group-aligned: the manifest object authenticating group N of the media track is published in group N of the manifest track. The manifest track is a plain sibling track named by the catalog -- it carries no role suffix and is not part of any switching set. The catalog carries the pointer to the manifest track and the profile parameters (Section 7.2.5); it never carries the digests themselves.

Manifest Content A manifest is an ordered sequence of per-object entries, each binding:

• object_id: the explicit source-symbol identity assigned at encode time. object_id values MUST be unique within the group but need not be contiguous or start at zero.
• digest: the object's leaf digest -- a keyed BLAKE3-256 over its authenticated bytes (Section 7.2.4), domain-separated with authScope and computed exactly as in Section 7.2.9.
• length: the length of the authenticated bytes in octets.

The entry sequence is followed by a group-close record binding (group_id, object_count), and by the signature. The on-wire encoding of the manifest object, of the leaf digest, and of the value the signature covers is specified in Section 7.2.9 (Canonical Encoding). With compaction "merkle", the per-object entries are the leaves of a binary Merkle tree and the signature covers the tree root; a receiver verifies an object by hashing its authenticated bytes and checking an O(log n) inclusion path against the root. With compaction "none", suitable for small groups, the signature covers the flat digest list directly.

Signature Context Binding The signature MUST NOT cover the bare root. It covers the signed message of Section 7.2.9, which binds the root (or, with compaction "none", the flat digest list) to its context: the broadcast namespace, track name, group_id, object-id range, key epoch, manifest format version, and the track's catalog-advertised codec, timing, and FEC-geometry parameters. Binding the full context prevents a valid (manifest, objects) pair from being replayed onto another track or broadcast signed by the same key. Freshness: receivers MUST reject manifests whose group_id falls outside the live-edge window unless operating in an explicitly-configured DVR or replay mode.

Authenticated Bytes The authenticated bytes of an object are the bytes of the MMTP packet that its MoQ object payload carries, excluding the trailing 4-byte Source FEC Payload ID that the payload carries when the packet's FEC Type is 1 ( Section 8.5). That trailer is the only range excluded. It is excluded because it is not part of the protected packet: it is appended after FEC encoding, so a packet recovered by FEC decoding carries none ( Section 7.3). The authenticated bytes are therefore identical across MoQ unicast, multicast UDP, and ROUTE, and for a packet recovered by FEC decoding. This gives cross-path verifiability: the same digest validates a symbol regardless of which path delivered it, so a symbol received on any path, or recovered by FEC decoding, verifies against the same manifest entry. It also means that a verified digest authenticates the packet but not its FEC block assignment, which the excluded trailer carries ( Section 8.5).

Catalog Signaling The authentication configuration is declared in the catalog as part of the multicast configuration: ", "keyId": "v1", "previousKey": "", "compaction": "merkle", "enforcement": "shadow", "tracks": [ { "mediaTrack": "video/base", "manifestTrack": "video/manifest", "authScope": "<32-byte value, base64url unpadded>", "sourceSymbolFormat": "full-mmtp-packet" } ] } ]]> scheme, hash, sig (strings, REQUIRED): The authentication profile, digest algorithm, and signature algorithm. This document defines only "bc-provenance" with "blake3" (BLAKE3-256 ) and "ed25519" (). publicKey (string, REQUIRED): The 32-byte Ed25519 broadcast public key, base64url-encoded without padding. keyId (string, REQUIRED): Key epoch identifier. The key epoch is part of the signature context binding (Section 7.2.3). previousKey (string, OPTIONAL): The prior epoch's public key, retained during rotation. Together with keyId this permits a one-epoch overlap: receivers MAY accept manifests signed under the prior epoch while the catalog advertises both keys. compaction (string, OPTIONAL, default "merkle"): Digest compaction, "merkle" or "none", as defined in Section 7.2.2. enforcement (string, OPTIONAL, default "shadow"): Publisher hint. "shadow" asks receivers to verify and report; "required" indicates that receivers SHOULD drop unverified objects. Receivers ultimately choose their enforcement mode (Section 7.2.6). tracks (array of objects, REQUIRED): One entry per protected media track. The array MUST NOT be empty.

• mediaTrack (string, REQUIRED): Name of the protected media track as it appears in the catalog.
• manifestTrack (string, REQUIRED): Name of the manifest track carrying the signed manifests for mediaTrack. manifestTrack values MUST NOT collide across entries.
• authScope (string, REQUIRED): A fresh, unpredictable 32-byte value, base64url-encoded without padding, generated per (session, track) and mixed into the digest computation as a domain-separation input. authScope values MUST NOT collide across entries.
• sourceSymbolFormat (string, REQUIRED): The byte format digests are computed over. Only "full-mmtp-packet" -- the authenticated bytes of Section 7.2.4 -- is defined by this document.

Receiver Enforcement Receivers operate in one of three enforcement modes: "off" (no verification), "shadow" (verify every object and report failures without dropping), or "enforce". In enforce mode a receiver MUST drop objects that fail verification before admission to reassembly or decode, and MUST discard FEC-recovered blocks whose recovered objects fail verification. Injected or corrupted symbols therefore fail the digest check and are dropped before they can poison FEC decode. A receiver in enforce mode SHOULD apply a hold-down to sources whose objects repeatedly fail verification. A receiver MUST be able to pin "authentication required" for a broadcast independently of the catalog. Without such a pin, an attacker able to rewrite the catalog could remove the auth member entirely and downgrade the receiver to unauthenticated reception.

Threat Model This profile protects against off-path and on-segment UDP injection, and against corrupted or attacker-injected FEC symbols. It does not protect against a malicious MoQ relay that rewrites the catalog itself, nor against key substitution at the signaling layer, until an out-of-band key binding exists. For broadcast-only receivers with no return channel, the broadcast public key (or a certificate chaining to one) MUST be provisioned or pinned out of band; a key learned solely in-band on a one-way channel provides no authentication.

ROUTE and Broadcast Carriage Hybrid receivers -- receivers that also hold the MoQ catalog -- verify symbols from any carrier against the same catalog-advertised manifests; no carrier-specific authentication is needed. For broadcast-only receivers, manifest objects are carried in the ROUTE signaling carousel, and each source block additionally carries the signed group digest in an ALC/LCT EXT_AUTH header extension per .

Canonical Encoding This section specifies the exact octet encoding of the leaf digest, the tree root, the signed message, and the manifest object, so that independent implementations produce byte-identical inputs to BLAKE3 and Ed25519. All multi-octet integers are unsigned and in network byte order (big-endian). The notation is:

• u8, u16, u32, u64: unsigned integers of that width.
• lp16(x): a u16 octet count followed by the x octets; lp32(x) is the same with a u32 count. A string is encoded as its UTF-8 octets.
• A digest is 32 octets (BLAKE3-256); the signature is 64 octets (Ed25519 ).
• BLAKE3(m) is BLAKE3 in unkeyed mode; BLAKE3(k; m) is BLAKE3 keyed with the 32-octet key k ().

A conforming sender and receiver MUST produce identical octet strings for the leaf digest, the root, and the signed message. A receiver MUST verify the Ed25519 signature over the reconstructed signed message and MUST reject the manifest on any mismatch. Leaf digest. The digest bound in each manifest entry, and hashed as a Merkle leaf, is: The 32-octet authScope (Section 7.2.5) is the BLAKE3 key, giving per-(session, track) domain separation. Merkle Tree Hash (compaction "merkle"). The root is the Merkle Tree Hash of the leaf digests in ascending object_id order, using the tree structure of Section 2.1 with this profile's keyed node hash: An inclusion proof is the list of sibling digests on the path from a leaf to the root, verified by recomputing the interior-node hashes. With compaction "none" the value used in place of the root is the flat concatenation digest_0 || digest_1 || ... || digest_(m-1) of the m leaf digests in ascending object_id order (32 * m octets). Signed message. The signature (Section 7.2.3) is computed over the following octet string, which the receiver reconstructs from the manifest object and the catalog: object_id_min and object_id_max are the smallest and largest object_id in the manifest. params_hash binds the track's codec, timing, and FEC geometry as a hash over a fixed-order encoding of those catalog fields, so they are bound without depending on a canonical JSON form: An absent interleaveDepthMs is encoded as u32(0), so it and an explicit zero yield the same params_hash. The two are equivalent for this binding: both mean that the catalog signals no elapsed-time FEC deadline ( Section 5.1). Manifest object. The object carried on the manifest track (Section 7.2.1) is: The group_id and object_count fields are the group-close record of Section 7.2.2. A receiver reconstructs the signed message from these fields plus the broadcast_namespace, track_name, keyId, and catalog parameters bound by the profile, recomputes the root (or flat list) from the entry digests, and verifies the signature against the publicKey. A worked test vector is in Appendix A.

Catalog as Attack Surface The multicast catalog extension directs receivers to join multicast groups and to dial network sources. A hostile or compromised catalog is therefore an attack vector:

• Join amplification: Catalog-directed joins create IGMP/MLD and multicast routing state on intermediate routers (Section 4.1). A catalog listing many endpoints, or rapidly changing endpoints, can exhaust router state or subscribe receivers to unwanted high-bandwidth traffic. Receivers MUST validate that each groupAddress falls within the multicast address ranges given in Section 4.1 before joining, and SHOULD bound the number of concurrent joins performed on behalf of a single catalog.
• Attacker-chosen dial-out: The relay field of an AMT network source is an address the receiver dials over UDP. A hostile catalog can direct traffic at arbitrary targets (traffic reflection) or at internal infrastructure (address-space probing). Receivers and relays MUST treat catalog-supplied endpoint and relay addresses as untrusted input and validate them against local policy (such as an allowlist of permitted relays or networks) before dialing, and SHOULD reject loopback, link-local, and otherwise non-routable relay addresses unless explicitly configured.

IANA Considerations This document has no IANA actions. The multicast catalog extension (Section 4) is defined by this document and does not require IANA registration.

References Normative References ISO/IEC Blockcast Blockcast Informative References Akamai Technologies, Inc. TU Berlin Akamai Technologies, Inc. W3C Community Group Draft Report

Test Vector: bc-provenance (BCPV1) This appendix is informative. It gives a worked bc-provenance example (Section 7.2.9) with compaction "merkle". All values are hexadecimal; the Ed25519 secret seed is included only so the vector is reproducible. Inputs: Leaf digests (Section 7.2.9), keyed BLAKE3 under authScope: Merkle Tree Hash of (digest_0, digest_1, digest_2): n=3, k=2, so root = node(node(digest_0, digest_1), digest_2): signed_message (126 octets) and the Ed25519 signature over it: The full manifest object (198 octets) carried on the manifest track: