Multicast Delivery and Endpoint Discovery for Media over QUIC

4.2.1. AMT (Automatic Multicast Tunneling)

{
  "networkSource": [{
    "type": "amt",
    "relay": "amt.example.com",
    "discovery": "dns"
  }]
}

relay (string, OPTIONAL): AMT relay service name. With dns, it MUST be a hostname whose A and AAAA answers are candidate addresses. With manual, it MUST be the literal address of the explicitly configured relay. It MUST be omitted with driad, because DRIAD supplies the relay candidates. A literal address does not provide DNS locality steering.¶

port (integer, OPTIONAL): UDP port on which the relay named by the relay field accepts requests. When absent, the AMT port (2268, [RFC7450] Section 7.2) is used. A value other than 2268 departs from [RFC7450] Sections 5.1.1 and 5.1.3 and works only with gateways and relays configured for it. The field never applies to a relay found by DRIAD, whose AMTRELAY record carries no port ([RFC8777] Section 4.2).¶

discovery (string, OPTIONAL): AMT relay discovery method.¶

• "dns": Resolve the relay service hostname to A and AAAA candidates and validate each candidate with the AMT protocol (Section 3.1). This is the RECOMMENDED method when a relay service hostname is available.¶
• "driad": DNS Reverse IP AMT Discovery per [RFC8777]. Subscribers query the source IP's reverse DNS for AMT relay records; relay MUST be omitted. Each discovered relay is still a candidate and MUST be validated with the AMT protocol before selection.¶
• "manual": Relay address is provided in the relay field. This is intended for explicitly configured static deployments.¶

For dns, subscribers MUST resolve the hostname at each connection and reconnect attempt, bound both the number and duration of AMT validation attempts, and race a bounded batch for the returned A and AAAA candidates. The receiver MUST wait for either first (S,G) data or the configured finite post-Membership-Query/Update wait. It MUST select only a candidate that completes the AMT control-plane exchange; for a sparse or idle source, selection after the wait expires records control-plane health without claiming data-plane proof. DNS answer order is not a health signal.¶

When cancelling a losing AMT attempt that has reached the Query/Update state, the receiver MUST send a Membership Update carrying the IGMP/MLD leave (withdrawal) for the requested (S,G) [RFC7450] Section 5.1.5, then close that candidate's socket. An attempt that has not reached that state is cancelled by closing its socket; a failed cancellation is bounded and MUST NOT keep the candidate attempt alive.¶

Subscribers SHOULD look for a relay in this order, which keeps the preference of [RFC8777] Section 3.1.2 for a relay in the subscriber's own network:¶

1. Look for a relay in the subscriber's own network, with DNS-based Service Discovery (DNS-SD) [RFC6763] for _amt._udp and then through the AMT anycast addresses of [RFC7450] Section 7.¶
2. Use receiver-owned DNS candidate discovery when discovery is "dns", or when discovery is omitted and relay is a hostname.¶
3. Use DRIAD discovery on the SSM source IP when discovery is "driad", or when both discovery and relay are omitted and the source IP has DRIAD records.¶
4. Use a literal relay directly when discovery is "manual", or when discovery is omitted and relay is a literal under an explicitly permitted static-deployment policy.¶
5. Fall back to MoQ/QUIC unicast.¶

The discovery and relay fields select at most one of steps 2 to 4 for an endpoint. A relay named by the relay field or found by DRIAD is one that the sender knows, and is not necessarily near the subscriber ([RFC8777] Section 3.1.1). A local relay keeps more of the path on native multicast. Every relay found in steps 1 to 4 is a candidate that the subscriber validates with the AMT protocol before selection (Section 3.1). DRIAD requires AMTRELAY (TYPE260) reverse DNS records on the source IP. Publishers without reverse DNS control SHOULD provide a stable relay service hostname.¶

4.2.2. ATSC 3.0 (Broadcast Television)

{
  "networkSource": [{
    "type": "atsc3",
    "frequency": 533000,
    "plpId": 0,
    "serviceId": 1,
    "slsUri": "https://example.com/atsc3/sls/service1.xml"
  }]
}

frequency (integer, REQUIRED): RF center frequency in kHz.¶

plpId (integer, OPTIONAL): Physical Layer Pipe ID ([ATSC-A322]). Defaults to 0.¶

serviceId (integer, OPTIONAL): Service ID within the broadcast multiplex ([ATSC-A331]).¶

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 of an MMTP service, its MP table included ([ATSC-A331] Section 7.2).¶

Receivers with ATSC 3.0 tuner hardware can receive the stream directly over RF. MoQ subscribers without tuner hardware ignore this networkSource type.¶

4.2.3. Multiple Network Sources

When a stream is available via multiple delivery technologies, the networkSource array lists one element per technology:¶

{
  "networkSource": [
    { "type": "amt", "discovery": "driad" },
    { "type": "atsc3", "frequency": 533000, "plpId": 0 }
  ]
}

Subscribers select the highest-priority available source per the transport hierarchy defined in Section 3.¶

7.2.1. Protected Flows and Sequence Numbers

The protected unit is a flow: every datagram the sending entity emits to one endpoint (S, G, port) of Section 4.1 whose auth member is present (Section 7.2.6). That is the datagrams of every track the endpoint lists, repair tracks included, and the MMTP signaling sub-flow on packet_id 0 (Section 5) where the endpoint carries it. A track carried on several endpoints is in a separate flow on each. A packet of a listed track that another path delivers to a consumer protected under the flow, one that has admitted a datagram of it, is a datagram of the flow as well (step 2 of Section 7.2.7). A flow has one manifestPort, which no other flow of the same (S, G) shares (Section 7.2.6); its sequence counter (below) and its mseq counter (Section 7.2.3) are kept per (kid, epoch).¶

sequence is a 64-bit counter the sender assigns per (flow, kid, epoch): it starts at any value and increases by one for every datagram the flow emits, in emission order, repair symbols and signaling datagrams included. It is carried only in manifest records, never in data datagrams, and is unrelated to MoQ group_id and object_id. Digest i of a record covers sequence = first_seq + i, so one window is a contiguous run of the flow. A window MAY span a MoQ group boundary. A datagram the sender emits twice (a carousel) has two sequences and two digests.¶

7.2.2. Digest

Every datagram the sender emits in a protected flow has a digest:¶

D = H(pseudoheader || payload)

payload is the entire UDP payload as transmitted, including the trailing Source FEC Payload ID when the packet's FEC Type is 1 ([MOQ-FEC] Section 8.5), so a verified digest also authenticates the FEC block assignment of a received packet. A packet the decoder recovers carries no Source FEC Payload ID and none is re-appended for delivery ([MOQ-FEC] Section 7.3); when its admission needs a digest, the receiver appends the base SS_ID its position in the base block implies, for the hash only (Section 7.2.7).¶

pseudoheader is the AMBI pseudoheader of [I-D.ietf-mboned-ambi] Section 3.4.2, restated here by value since that draft has expired:¶

pseudoheader =
    S                     # 4 octets (IPv4) or 16 octets (IPv6)
 || G                     # 4 or 16 octets, same family as S
 || 0x00                  # zeroes
 || 0x11                  # protocol, UDP
 || u16(payload_length)   # length of payload in octets
 || u16(src_port)
 || u16(dst_port)
 || u32(streamId)

Addresses are in native width, never IPv4-mapped. S is the address from which the sending entity transmits the flow (Section 5): the endpoint's sourceAddress on an SSM endpoint and its auth.senderAddress on an ASM endpoint (Section 7.2.6). src_port and dst_port are both the endpoint's port: the sender MUST emit every datagram of the flow from UDP source port port. streamId is the endpoint's auth.streamId. Every input is catalog-declared, and a receiver without the catalog holds the same values from its out-of-band provisioning (Section 7.2.7), so for a datagram of the flow delivered over a unicast MoQ path or an MMTP broadcast the receiver forms the same pseudoheader and one digest verifies the same bytes on every path (Section 7.2.9; step 2 of Section 7.2.7).¶

7.2.3. Manifest Record

A manifest record is one UDP datagram on manifestPort of the same (S, G) as the protected flow. Every field except the signature is at a fixed offset, and the signature is the last 64 octets.¶

Length is 132 + 32 x count octets. The cap of 37 digests is an MTU choice: the 1316-octet maximum is 1344 octets on the wire with IPv4 and UDP headers and 1364 with IPv6, which leaves room for AMT encapsulation [RFC7450] on a 1500-octet path.¶

flags: bit 0, epoch end (Section 7.2.7); bits 1 to 7 reserved, MUST be zero on send and ignored on receipt.¶

sent is the sender's clock when the record is signed, truncated to whole seconds since 1970-01-01T00:00:00Z with leap seconds excluded, from a clock synchronized to UTC within 1 s; the twin of a record (Section 7.2.5) carries the original's value. It is a count of seconds, not the 16.16 NTP short format, so it wraps in 2106 rather than every 18.2 hours. A sender whose clock is further off than the tolerance of Section 7.2.7 makes its flow unverifiable to receivers that check freshness.¶

All records of one flow carry the same hash_alg for the life of a stream generation (streamId, Section 7.2.6); a change of algorithm is a new generation. epoch never decreases under one kid: a sending entity MUST NOT reuse an epoch under a kid, across generations or restarts, and a generation that would start below the kid's last epoch starts under a new kid (Section 7.2.6).¶

7.2.4. Signature Context Binding

The signature is computed over:¶

signed_message =
    "mcast-manifest-v2" || 0x00     # 18-octet prefix
 || u32(streamId)
 || S                               # 4 or 16 octets
 || G                               # 4 or 16 octets
 || u16(manifestPort)
 || record[0 .. len - 64)

with S, G, streamId and manifestPort as declared for the endpoint (Section 7.2.2, Section 7.2.6). The prefix binds the flow's network identity; a receiver needs no catalog state to check it beyond those four values, which a MoQ receiver takes from the catalog and a broadcast-only receiver from its provisioning (Section 7.2.7). The MoQ context is bound inside the record by ctx:¶

ctx = H("BCPV2-ctx"
        || u16(f) || f * lp16(field)        # namespace, in order
        || u16(n) || n * u16(packetId)      # ascending
        || params_hash)

params_hash = H("BCPV2-params"
    || lp16(codec) || u32(timescale) || u32(groupDurationTicks)
    || lp16(fecAlgorithm) || u32(sourceSymbols) || u32(repairSymbols)
    || u32(symbolSize) || u32(interleaveDepthMs))

both with the record's hash_alg. The field values are the f Track Namespace Fields, in order, of the one MoQ namespace the sending entity serves (Section 4.1): the Track Namespace of the catalog track ([I-D.ietf-moq-transport]), which every track listed on an endpoint shares (Section 4.1; [I-D.ietf-moq-msf] Section 5.2.2); each field is the octets MOQT carries for it. The packetId values are those of the endpoint's tracks (Section 4.1), n of them in ascending order. params_hash is taken from the catalog entry of the endpoint's lowest-packetId media track or, for an endpoint that lists only fec-repair tracks, from the catalog entry of the source track that its lowest-packetId repair track repairs: the track its depends names or, on layer 0, the track whose fec.repairTrack names it ([MOQ-FEC] Section 5.1.1). codec is that entry's MSF field; timescale is its timescale and groupDurationTicks its group duration in timescale ticks, both as [MOQ-MMT] Section 4.4.2 resolves them; fecAlgorithm is the algorithm member of its fec object and the other four are its same-named members ([MOQ-FEC] Section 5.1). An absent interleaveDepthMs is encoded as u32(0); an entry with no fec object is encoded as lp16("none") followed by four u32(0); an entry for which [MOQ-MMT] Section 4.4.2 resolves no timescale or no group duration, as it need not for a track that is not mmtp-packaged (Section 5), is encoded as u32(0) for that value. A flow carried without a MoQ catalog sets ctx to 32 zero octets. A MoQ receiver recomputes ctx from the catalog and MUST reject a record whose ctx differs (Section 7.2.7); a receiver without the catalog carries ctx blind. A valid (record, datagrams) pair therefore cannot be replayed onto another endpoint, stream generation, broadcast, key or epoch; sent (Section 7.2.3) bounds replay within an epoch to the clock tolerance of Section 7.2.7.¶

7.2.5. Emission and Cadence

A sender closes a window after 37 datagrams or after manifestTimerMs since the window opened, whichever comes first; the timer governs only while the flow emits at most 37 datagrams per manifestTimerMs (1850 per second at the default, about 21 Mbit/s of 1400-octet datagrams), and the count cap governs above that. A sender MAY raise manifestTimerMs to at most maxAuthDelayMs / 4 on low-rate flows.¶

The signed record MUST be transmitted immediately before the first datagram it covers (only the twin of an earlier window MAY come between them), so the sender holds at most one window of data. A twin, a byte-identical copy of the record, MUST be transmitted after the last datagram the record covers, no later than maxAuthDelayMs / 2 after the record and before the signed record of window mseq + 64, so that at most 63 later records precede it and it arrives above the replay floor of Section 7.2.7, which only the records arriving on manifestPort raise, however fast the flow closes windows; RECOMMENDED is to transmit it immediately after the signed record of window mseq + 2 and before the first datagram that record covers, or on its own at the maxAuthDelayMs / 2 deadline when window mseq + 2 has not opened by then. The two copies then bracket the window's datagrams: a contiguous loss burst that removes both copies has removed every datagram between them, and a datagram that survives such a burst has a usable copy on one side of it, whatever the flow's rate and timer; only two separate losses can leave an arriving datagram without a copy, and then at most 37 datagrams expire from the hold queues (Section 7.2.8). Every twin of an epoch MUST be transmitted before the first record of a later epoch, since a receiver drops the records of an earlier epoch once its grace period ends (Section 7.2.7); every twin of the epoch not yet transmitted when its last datagram has been sent, the twin of the record whose flags bit 0 is set included, follows that datagram at once. A receiver handles either copy by step 1 of Section 7.2.7 and drops the second with one lookup and one hash.¶

At 37 digests per window, a record and its twin cost about 71 octets per 1400-octet datagram (5.1%); data datagrams are untouched. Manifest records MUST NOT be FEC-protected; the twin is their loss remedy.¶

A publisher MAY mirror the same record octets as objects on a MoQ manifest track (one record per object; a record goes in manifest-track group N, N being the Group ID of the latest packet, emitted at or before the window's first datagram, of the track whose catalog entry supplies params_hash (Section 7.2.4), or of that track's first group of the stream generation where none precedes) for unicast subscribers. A packet of a track the endpoint lists that reaches a consumer protected under the flow is a datagram of the flow on a MoQ unicast path too (step 2 of Section 7.2.7), and the mirror is its only source of records while the multicast path delivers none, during the join of Section 4.1 and after the failover of Section 6. Without a manifestTrack a track's unicast fallback is a MoQ subscription outside this profile, protected by the MoQ session alone, so a publisher that wants the fallback verified against its records MUST name one. Records read from the manifest track charge a verification budget of their own, not the flow's manifestPort budget (Section 7.2.7); a receiver that reads the manifest track while joined to the multicast path sees each record first on the shorter path and drops the later copy as already verified, matching its digests only where it raises the mirror's lead (step 1 of Section 7.2.7), so where the mirror leads manifestPort it widens, by the mirror's lead and under the bound below, the pending expiry of a mirrored record's entries and the time for which it keeps a digest it admits recorded as admitted: a relay copy admitted first would otherwise leave the multicast copy, arriving up to the lead later, to be held and to expire as loss (steps 1 and 2 of Section 7.2.7). The lead of a record is unknown when its entries are inserted, so the receiver keeps the lead as a per-flow value: the largest interval it has measured in the stream generation from the arrival of a record on the mirror to the arrival of the first copy on manifestPort, which the lookup drops (a later copy on that path, the twin or one replayed within the retention, measures nothing; step 1 keeps the time and path of arrival, and a digest of the record's bytes, with each verified (kid, epoch, mseq) for this), each interval rounded up to a multiple of manifestTimerMs before it is compared with the lead (so the lead rises at most 5000 / manifestTimerMs times in a stream generation, 250 at the default, however a relay paces the mirror; step 1), and the bound below until it has measured one; a copy that raises the lead, byte-identical to the verified record, re-admits or re-inserts, under the raised lead and ahead of the datagrams they cover, the digests of that record and of every record verified on the manifest track within the raised lead before now whose first copy has not yet arrived, for the pairs that have admitted nothing and are not pending, widens the pending entries of those records by the raised lead, and records again as admitted, under the raised lead, the digests of the pairs that have, so that a mirror whose lead grows past the one measured, within the bound below, costs the datagrams of those records nothing, a late copy of a datagram a pair has admitted is dropped rather than held, and a copy replayed within the retention re-admits nothing (step 1). A receiver that reads no manifest track applies no lead, nor does one that will not join the multicast path; one that may yet join applies the bound until it has measured a lead, since the multicast copies of the datagrams its relay delivers before the join arrive after it. The timers of Section 7.2.7 are wall-clock bounds; a relay-buffered QUIC path can deliver records later than maxAuthDelayMs, or the datagrams of a window later than the record that covers them, the manifest track and the media tracks being separate streams, and a unicast receiver SHOULD widen its hold, and the freshness tolerance of step 1 of Section 7.2.7 for the records it reads from the manifest track, accordingly, by at most 5 s, the widening W, a receiver that applies no lead widening the pending expiry of a mirrored record's entries by W as well (step 1), since no lead covers the datagrams its relay delivers after the records that cover them: the widening is also its exposure at join to windows that old served by its relay (Section 7.2.8), a record on manifestPort keeps the unwidened tolerance and pending expiry as the multicast path's hold queue keeps the unwidened expiry, and a receiver that needs more is replaying (Section 7.2.7). The bound caps the lead as well: a relay that leads the multicast path by more than the bound plus maxAuthDelayMs outruns the admitted digests the lead widens, and by more than that plus 2 x manifestTimerMs the pending entries as well, and the copy on manifestPort of a record it mirrors that far ahead, which the receiver keeps verified for as long as the freshness check of step 1 would pass it, or for as long after that as its mseq stays above the manifest track's replay floor (Section 7.2.7), is dropped by the lookup of step 1 while so kept and by that check after, and, the lead standing at the bound, admits nothing either way, so the multicast copies of the datagrams of those records are held and expire from the multicast path's hold queue, loss for the failover (Section 7.2.8); the lead being the multicast path's lag behind the mirror, such a path fails over on its own latency on a receiver that checks freshness. One that skips the check (the Clock paragraph of Section 7.2.7) keeps the record verified 7 s + maxAuthDelayMs after its arrival on the manifest track, or for as long after that as its mseq stays above the manifest track's replay floor (the state list of that section), so under a relay leading by more than the longer of the two the copy on manifestPort misses the lookup, meets no freshness check and is verified anew there, from that path's budget, admitting the datagrams of its window as any record on manifestPort does: such a receiver fails over on a lead between the bound plus maxAuthDelayMs and that retention and, under a larger one, verifies every record on both paths instead; on a flow whose 64 windows outlast 7 s + maxAuthDelayMs, the floor keeps the record verified until its copy arrives under any lead shorter than 64 windows, the lookup drops the copy, and such a receiver fails over as one that checks freshness does. Under a lead beyond that retention such a receiver still loses windows at each epoch change, and so may fail over there: those of the previous epoch's records whose copies reach manifestPort past that epoch's deadline (step 1 of Section 7.2.7), and those of most of its 64 latest records, whose copies the lookup drops because that epoch's replay floor, raised by no later record, keeps them verified.¶

7.2.6. Catalog Signaling

The auth member of the multicast object (Section 4.1) declares the profile and its keys; the auth member of an endpoint object marks that endpoint's flow as protected and carries the flow's parameters:¶

{
  "multicast": {
    "auth": {
      "scheme": "bc-provenance",
      "version": 2,
      "sig": "ed25519",
      "keys": [
        { "kid": 1,
          "publicKey": "<32-byte Ed25519 key, base64url unpadded>",
          "firstEpoch": 1 }
      ],
      "minEpoch": 17
    },
    "endpoints": [{
      "sourceAddress": "198.51.100.7",
      "groupAddress": "232.10.20.30",
      "port": 5004,
      "bandwidth": 100000000,
      "tracks": [
        { "name": "video",        "packetId": 1 },
        { "name": "video/repair", "packetId": 2 }
      ],
      "auth": {
        "manifestPort": 5005,
        "streamId": 2864434397,
        "maxAuthDelayMs": 200,
        "manifestTimerMs": 20,
        "manifestTrack": "video/manifest"
      }
    }]
  }
}

Members of multicast.auth:¶

scheme, version (REQUIRED): "bc-provenance", 2.¶

sig (string, REQUIRED): "ed25519" [RFC8032].¶

keys (array, REQUIRED): one to four {kid, publicKey, firstEpoch} objects. kid is an unsigned 32-bit integer carried in the clear in every record; publicKey is the 32-octet Ed25519 public key, base64url-encoded without padding; firstEpoch is the first epoch the key signs. A key signs the epochs from its firstEpoch up to, but not including, the next larger firstEpoch in the array, and the key with the largest firstEpoch signs every later epoch. kid values MUST be unique within a broadcast and firstEpoch values MUST be distinct within the array. A receiver that takes its keys from a catalog whose keys repeats a kid or a firstEpoch holds no key set for the broadcast: it admits nothing and treats every endpoint of the multicast object as one that yields no data (Section 4.1), as it does on a flow whose records carry an algorithm it does not implement (Section 7.2.7); a receiver that pins keys is unaffected, since its key set comes from the pin. A receiver drops, before verification, a record whose epoch is outside its kid's range (Section 7.2.7), so a retired key cannot carry a receiver past its successor's firstEpoch.¶

minEpoch (integer, REQUIRED): the lowest epoch a receiver accepts at join (step 1 of Section 7.2.7); after its first verified record the current epoch is the floor, with the previous epoch admitted on manifestPort until that path's grace period ends, or while that path has started none, and never past the bound of Section 7.2.5 plus maxAuthDelayMs + 2 x manifestTimerMs after the current epoch became current, and on the manifest track within the earlier-started of the two paths' periods (step 1). The publisher MUST write the current epoch at every epoch change, sender restart included, so a joiner with a current catalog cannot be fed an earlier epoch.¶

Members of an endpoint's auth; a protected endpoint MUST also declare bandwidth, which bounds the receiver's hold queues:¶

• manifestPort (integer, REQUIRED): destination port of the record datagrams, twins included, on the endpoint's (S, G); MUST differ from the port of every endpoint of the same (S, G) in the catalog, this endpoint included, and from the manifestPort of every other such endpoint, so that no port of an (S, G) carries both data and records, or the records of two flows. (S, G, manifestPort) is a multicast tuple under the one-namespace rule of Section 4.1. A receiver MUST ignore (Section 4.1) a protected endpoint whose ports violate this. Two ASM endpoints whose senderAddress differ MAY share groupAddress and ports; the source check of Section 7.2.7 separates them.¶
• streamId (integer, REQUIRED): 32-bit value chosen per channel generation, bound into every digest and signature.¶
• senderAddress (string, REQUIRED on an ASM endpoint, MUST NOT appear on an SSM endpoint): the address from which the sending entity transmits this endpoint's flow, S of Section 7.2.2; on an SSM endpoint S is sourceAddress.¶
• maxAuthDelayMs (integer, OPTIONAL, default 200, range 50 to 1000): how long a receiver holds a datagram whose digest has not arrived.¶
• manifestTimerMs (integer, OPTIONAL, default 20, at least 1): the window timer of Section 7.2.5.¶
• manifestTrack (string, OPTIONAL): the MoQ track mirroring the records (Section 7.2.5).¶

When the multicast object carries auth, every endpoint of the multicast object MUST carry auth; a receiver MUST ignore (Section 4.1) an endpoint that lacks it, so every multicast datagram it consumes from the sending entity is in a protected flow and reaches a decoder only through Section 7.2.7. An endpoint that carries auth when the multicast object does not is ignored likewise, since it names no key.¶

7.2.7. Receiver Enforcement and State

A receiver that implements this profile enforces it: a datagram of a protected flow is admitted only after its digest matches an entry of a verified record, and there is no verify-and-report mode. A receiver MUST be able to pin "authentication required" for a broadcast independently of the catalog. A receiver without the catalog (a broadcast-only receiver, or native SSM reception without a MoQ session) MUST be provisioned out of band with the keys, firstEpoch included, and minEpoch and, per protected flow, the streamId, S, G, port, manifestPort and bandwidth the catalog would declare (Section 7.2.6), and any non-default maxAuthDelayMs and manifestTimerMs: the record carries none of them, and a broadcast carries the flow on those addresses and ports or not at all (Section 7.2.9); keys are never taken from a carrier's signaling. A receiver that pins keys takes the key set, firstEpoch included, from the pin rather than from the catalog, and MUST keep with the pin, across sessions, the highest epoch it has verified under each pinned kid; in step 1 below it drops, at join, a record whose epoch is below that value for its kid, so a catalog that carries a lower minEpoch cannot reopen an epoch a verified record has closed. The pin stores no value read from a catalog: every receiver takes minEpoch from the catalog it fetched, or provisions it with the keys, and it bounds that session only. A receiver with no pin is protected at its first join against an earlier epoch only as far as that catalog is. A receiver that implements no algorithm a flow's records carry verifies nothing on that flow: it admits nothing and treats the endpoint as one that yields no data (Section 4.1).¶

On an ASM endpoint a receiver MUST discard, before any parsing or hashing, a datagram on port or manifestPort whose IP source address is not senderAddress; behind an AMT relay the address is that of the encapsulated header (Section 5). On an SSM endpoint reached natively the network enforces the source and a receiver SHOULD still discard a datagram whose source address is not sourceAddress; a receiver reached through an AMT gateway MUST discard it, since nothing upstream of its gateway filters the encapsulated source address and [RFC7450] does not authenticate Multicast Data messages. A datagram that passes belongs to the flow (S, G, port) or (S, G, manifestPort) with S as in Section 7.2.2.¶

State per flow: the current epoch with the kid that set it, the time at which that epoch became current, per path (manifestPort and the manifest track) the grace period that ends maxAuthDelayMs + 2 x manifestTimerMs after the first record of the current epoch verified on that path or dropped there by the already-verified lookup of step 1 as its byte-identical copy, and, until the period on manifestPort ends or the previous epoch's deadline passes, the previous epoch, the deadline being the bound of Section 7.2.5 plus maxAuthDelayMs + 2 x manifestTimerMs after the current epoch became current (step 1; a record on manifestPort meets its own path's period and the deadline, one read from the manifest track the earlier-started of the two periods, which ends before the deadline); the flow's hash_alg, fixed by its first verified record; per (kid, epoch) the verified mseq values above the replay floor of the path they arrived on, and those verified on the manifest track for as long as the freshness check of step 1 would pass a copy of them on manifestPort, their sent within 7 s + maxAuthDelayMs behind the receiver's clock, or that long after their arrival on the manifest track where the receiver skips that check, whatever the floor (so that the lookup of step 1 still meets, and measures the lead from, a manifestPort copy arriving after 64 or more further records were verified on the mirror, and drops as already verified every copy that check would pass: one arriving more than the bound of Section 7.2.5 plus maxAuthDelayMs + 2 x manifestTimerMs after the mirror's copy, the lead standing at the bound, then admits nothing, and the datagrams it covers expire, as that section says, rather than being verified anew on manifestPort; where the lead stands below the bound, the first such copy raises it to the bound and handles the record's pairs again as step 1 says; a receiver that skips the check verifies anew a copy arriving after the retention and below the manifest track's replay floor, save a copy of the previous epoch arriving past that epoch's deadline, which step 1 drops, dropping by the lookup one that arrives above the floor, as that section also says), each with the time and path of its arrival, its sent, which that retention reads, the hash_alg digest of the record's bytes, per pair of the record, whether a datagram has been admitted against it and, for a record verified on the manifest track whose first copy on manifestPort has not yet arrived, the record's pairs, which a raise of the lead re-handles (steps 1 and 2), per path the highest_mseq that the records arriving on it have raised (step 1) and, once a verified record has flags bit 0 set, the mseq that closed it; the verification budgets of step 1, one for manifestPort and one for the manifest track, each with a count of the records it dropped; the mirror's lead (Section 7.2.5), a multiple of manifestTimerMs or the bound, and whether the stream generation has measured one, the bound of that section applying until it has and zero on a receiver that reads no manifest track or will not join the multicast path; a pending table of (digest, sequence, expiry) entries, each naming the record and the pair that inserted it, an entry whose expiry the mirror's lead or W widened keeping its insertion time as well (step 1); the digests recorded as admitted, each until the expiry set when it was recorded, the time of recording plus maxAuthDelayMs plus the mirror's lead then in force, a copy on manifestPort that raises the lead recording again the digests of the marked pairs it handles (steps 1 and 2); for each open block of a protected consumer, the number of decodes, at most two, taken with the help of symbols of unlisted tracks (step 2) that have left it unrecovered, block state under the bound of [MOQ-FEC] Section 9 released with the block (step 2); on a receiver that can request unicast repair, for each open block that has an FEC deadline, the admission time of the first packet, source or repair, admitted into it, or of the packet that stands for it under step 2 (the source packet of highest SS_ID admitted at or below its lower bounding packet, or the packet admitted above it where the instance has admitted none below), and for each base instance the admission time of the source packet of highest SS_ID it has admitted in the stream generation, kept under the serial number arithmetic of [MOQ-FEC] Section 7.5 (step 2); two hold queues of (digest, datagram, expiry) entries in arrival order, digest being absent from an entry until the first record of the flow is verified (step 2): one for the datagrams a MoQ unicast path delivers and the packets the base instance recovers with the help of a symbol that path delivered (step 2), and one for the rest. State per receiver, shared by its flows: the time of the last catalog re-fetch that an unknown kid triggered (key rotation, below), and the per-kid epoch floor kept with a key pin. The per-flow state belongs to the stream generation (Section 7.2.3): when the streamId the catalog, or a receiver's provisioning, declares for the endpoint changes, the receiver discards every per-flow item above but the two verification budgets and their counts and the hold queues (the current and previous epoch, hash_alg, the per-(kid, epoch) mseq state, the mirror's lead, the pending table with the entries kept for unicast repair, the admitted digests, the per-block decode counts and the per-block and per-instance admission times), clears the digest of every held datagram, and processes the next record as the first of the flow under the join-time floors of step 1.¶

A receiver applies the following, in this order, with no variable-length interpretation before a cryptographic check:¶

1. Record datagram (on manifestPort, magic "MHM2"). Require 164 <= len <= 1316 and (len - 132) mod 32 == 0. Read the fixed-offset integers magic, kid, epoch, mseq, count, hash_alg and sent and the 32 octets of ctx. Drop before any cryptography if: magic differs; kid is not in the key set, or epoch is outside its range (Section 7.2.6); (kid, epoch, mseq) is already verified (this drops the second copy of a record with one lookup and one hash, a copy of the previous epoch arriving after its grace period included; a dropped copy whose bytes hash, under the flow's hash_alg, to the digest kept with the verified entry is the record itself and counts as its arrival on this path: it raises the highest_mseq of the path and starts the path's grace period as a verified record would, below, and, where the verified copy arrived on the manifest track and this one is the record's first copy on manifestPort (its pairs, kept until then, are released at this arrival; a later copy there, the twin or one an injector replays within the retention, counts as a further arrival on the path and measures nothing), the interval between the two arrivals, rounded up to a multiple of manifestTimerMs and capped at the bound of Section 7.2.5, becomes the mirror's lead if it is the first measured in the stream generation and raises it if it exceeds it, a copy that raises it also handling this record and every record verified on the manifest track within the raised lead before now whose first copy on manifestPort has not yet arrived (the verified entry keeps their pairs for this, this record's own bytes carrying its pairs), each pair of such a record as below for a record on manifestPort, under the raised lead: a pair marked as having admitted a datagram has its digest recorded as admitted until now + maxAuthDelayMs plus the raised lead; one whose digest is pending has its entry's expiry set to the insertion time plus maxAuthDelayMs + 2 x manifestTimerMs plus the raised lead; one whose digest is neither admitted nor pending admits a held datagram or inserts a pending entry with expiry now + maxAuthDelayMs + 2 x manifestTimerMs plus the raised lead, now being its insertion time; and, once every such record is processed, each datagram held in either hold queue whose digest is now recorded as admitted is dropped (step 2), so that the datagrams of every record the mirror delivered under a lead the receiver had not yet measured, within the bound of Section 7.2.5, those of the records mirrored while the raising copy was in flight included, are still admitted when they arrive, a late copy of one a pair has admitted is dropped rather than held, and a copy replayed within the retention re-admits nothing a pair has admitted (Section 7.2.8); a dropped copy whose bytes do not match counts as nothing); epoch is below the current epoch and is not the previous epoch within the grace period this record meets and before the previous epoch's deadline, the bound of Section 7.2.5 plus maxAuthDelayMs + 2 x manifestTimerMs after the current epoch became current (below; a path on which no record of the current epoch has yet been verified, or dropped by the lookup above as its byte-identical copy, has started no grace period, so the previous epoch stays admitted on manifestPort until the deadline passes or, once such a record starts that path's period, until that period ends, if sooner, and on the manifest track until the earlier-started of the two paths' periods ends), or, when no record has yet been verified, is below minEpoch or below the pinned floor for its kid; mseq <= highest_mseq(kid, epoch) - 64, the highest_mseq this record meets (below; replay floor, none before a record of that (kid, epoch) has raised a highest_mseq this record meets, no upper bound); mseq is above the mseq that closed the epoch, once a verified record has closed it; sent is more than 7 s + maxAuthDelayMs behind, or more than 6 s ahead of, the receiver's UTC clock (freshness: the sender's 1 s bound and the receiver's 5 s bound, plus, behind, the truncation of sent to whole seconds and the delivery of the twin; a receiver that widens its hold per Section 7.2.5 widens the behind tolerance by the same amount for a record read from the manifest track, and not for one on manifestPort); count != (len - 132) / 32; hash_alg is not in the receiver's accepted set, or differs from the flow's hash_alg once one is fixed; or, on a receiver that holds the catalog, ctx differs from the value recomputed from it (a receiver without the catalog carries ctx blind, Section 7.2.4). The replay floor and the grace period a record meets are its path's: a record on manifestPort meets the highest_mseq and the grace period that the records arriving on manifestPort, verified or dropped by the lookup above as the record itself, have raised or started; a record read from the manifest track meets the higher of the two paths' highest_mseq values and the earlier-started of their grace periods. The mirror's lead so moves no floor and no grace period a multicast copy meets: a record a relay withholds from the mirror, or one the mirror loses, is tested against the multicast path's own cadence however far the mirror leads, and, while the mirror leads by no more than the bound of Section 7.2.5, the previous epoch's deadline drops on manifestPort only a record of that epoch reordered more than maxAuthDelayMs + 2 x manifestTimerMs behind the new epoch's first record (Section 7.2.8), and a mirror that lags the multicast path by the floor brings nothing a receiver still holds. Charge the per-flow verification budget, a token bucket of depth 64 refilled at 1000 tokens per second (a record read from the manifest track of Section 7.2.5 charges a second bucket of the same shape, so a flood on manifestPort cannot starve the mirror); drop and count a record that finds it empty (nothing before the signature tells a forged record from a genuine one, so a forged record spends the same token, Section 7.2.8). Verify the Ed25519 signature over signed_message; drop on failure, and only on success read first_seq, flags and the digests. If epoch is above the current epoch, or this is the first verified record, make epoch current, record when it became current, and make the former current epoch the previous epoch, with a grace period on each path that ends maxAuthDelayMs + 2 x manifestTimerMs after the first record of the new epoch that arrives on it and is verified, or dropped by the lookup above as the record itself (this record starts it on its own path now; manifestPort, while no such record has yet arrived there, admits the previous epoch until one starts that path's period and then until that period ends, and the manifest track until the earlier-started of the two periods ends, the sender emitting every twin of it before the new epoch's first record, Section 7.2.5; neither path admits it past the previous epoch's deadline, above, which this record sets, so a path on which the new epoch's records are dropped holds the previous epoch open no longer than that), fix the flow's hash_alg from this record if none is fixed yet, and hash every held datagram that has no digest yet; pending entries and held datagrams of the previous epoch are not flushed and live out their expiry. A record of the previous epoch that passes the checks above is processed under that epoch's own floor and verified set and never changes the current epoch. Record (kid, epoch, mseq) as verified, with the time and path of its arrival, its sent and the hash_alg digest of its bytes, and raise the highest_mseq of the path it arrived on. For each (digest, sequence) of the record, in order: if a hold queue holds a datagram with that digest, admit the oldest such datagram, mark the pair as having admitted it, remove it from its queue and record its digest as admitted until now + maxAuthDelayMs plus the mirror's lead (step 2); otherwise insert the pair into the pending table with expiry now + maxAuthDelayMs + 2 x manifestTimerMs (240 ms at the defaults), plus the mirror's lead, or W on a receiver that applies no lead, for a record read from the manifest track (Section 7.2.5), an entry so widened keeping its insertion time. Once every pair of the record is processed, drop from both hold queues each datagram still held whose digest is now recorded as admitted: it is a copy of a datagram this record admitted, delivered on the other path or repeated on the same one, which step 2 would not have held after the admission; its drop is not an expiry and counts toward nothing (Section 7.2.8). If flags bit 0 is set the epoch is closed at this mseq (Section 7.2.3).¶

2. Data datagram (on port). Compute D with the flow's hash_alg (a datagram that arrives before the first record of the flow is verified is held without a digest) and look it up in the pending table, which maps a digest to an ordered list of sequences (carousels repeat byte-identical datagrams). Hit: remove the lowest sequence, admit the datagram, mark the pair of the record that inserted the entry as having admitted it (step 1) and record D as admitted until now + maxAuthDelayMs plus the mirror's lead (Section 7.2.5). Miss: drop the datagram if D is so recorded (a copy of an admitted datagram delivered again, on any path, is never held); otherwise append (D, datagram) to the hold queue of its path, with expiry now + maxAuthDelayMs + W, each queue bounded to (maxAuthDelayMs + W) x bandwidth / 8000 octets, W being the widening of Section 7.2.5 in milliseconds, zero on the multicast path; drop the newest on overflow and drop at expiry, so a MoQ unicast path that fills its queue evicts no multicast datagram. Repair symbols follow the same rule, so an injected symbol is dropped before FEC decode. A receiver MUST NOT feed a FEC instance, a keyframe overlay or the packet_id 0 signaling consumer with a datagram of a protected flow that it has not admitted under step 1 or 2, on whatever carrier it arrived (Section 7.2.9). A FEC instance, a keyframe overlay or the packet_id 0 consumer that has admitted a datagram of a protected flow is a protected consumer, protected under each flow a datagram of which it has admitted (one that a source endpoint and a repair-only endpoint both feed, [MOQ-FEC] Section 6.3.6, under both), and a symbol admitted under any flow of the multicast object is an admitted symbol in every consumer it reaches: a packet of a track that the endpoint of a flow the consumer is protected under lists, reaching it over any path, a MoQ unicast path included, is a datagram of that flow and is admitted by this step (Section 7.2.2). A consumer that has admitted none, because the receiver takes the track over MoQ unicast alone while its multicast join completes (Section 4.1) or after the failover of Section 6, is a MoQ subscriber outside this profile: the MoQ session protects its objects, and it MAY verify them against the records of a manifestTrack (Section 7.2.5); a consumer protected under one flow of the object is such a subscriber for the tracks of a flow it is not yet protected under, as one that a repair-only endpoint feeds is for a source track the receiver takes over MoQ unicast ([MOQ-FEC] Section 6.3.6). On failover a receiver that reads no manifest track discards its protected consumers and continues as such a subscriber; one that does MAY keep them. A receiver holds an endpoint while it is joined to its group, reads its manifestTrack (Section 7.2.5) or receives the broadcast that carries the flow (Section 7.2.9), and a consumer is protected under a flow only while the receiver holds the flow's endpoint: when the receiver ceases to hold one, on the failover above or on dropping a repair layer ([MOQ-FEC] Section 6.3.6), it discards that flow's state as on a streamId change (above) and, since no further record of the flow will arrive, the flow's hold queues with the datagrams they hold, a drop that is no expiry and counts toward nothing; the consumer ceases to be protected under the flow, the symbols it admitted under it staying admitted, and the endpoint's tracks are, for the consumer, unlisted (below) unless another flow it is protected under lists them. At the admission that makes a consumer protected under a flow, the receiver discards every packet of a track that flow's endpoint lists that the consumer still holds and that it did not admit under step 1 or 2, so that none stands, under the deduplication of item 1 of Section 6, for the admitted copy of the same symbol; within a protected consumer that deduplication keeps an admitted symbol over an unadmitted one of the same key. For a consumer, a track that no endpoint of a flow it is protected under lists is an unlisted track, one whose symbols reach the consumer only over a MoQ unicast path ([MOQ-FEC] Section 6.3.6): a track that no endpoint the receiver holds lists, or one that an endpoint the receiver holds lists while the consumer is not yet protected under that endpoint's flow, its join still completing or its records unread, the multicast copy of such a packet being a datagram of that flow held by this step. A symbol of an unlisted track is not a datagram of any flow the consumer is protected under: it MAY enter a FEC instance under that path's own integrity protection, which vouches for the relay and not for the publisher, neither anchoring nor tripping the fail-closed check of [MOQ-FEC] Section 6.3.9 (that section), and the admission that makes the consumer protected under a flow that lists the track ends this for that track, the discard above dropping each such symbol the consumer still holds and a provisional block those symbols delimited returning its source symbols to the undelimited state of [MOQ-FEC] Section 7.4. The rules of this step from here to its end, for blocks, decodes and recovered packets, govern a FEC instance or keyframe overlay only while it is protected under a flow whose endpoint lists its source track. One protected under no such flow, as one that a repair-only endpoint feeds while the receiver takes the source track over MoQ unicast alone ([MOQ-FEC] Section 6.3.6), the track unlisted or the join of the endpoint that lists it still completing, is a MoQ subscriber outside this profile for its blocks: the symbols it admitted enter its decodes as admitted symbols, its other packets are what the MoQ session delivers, and [MOQ-FEC] Sections 7.4, 9 and 11.4 govern its blocks as those of a consumer outside this profile, until the admission that makes it protected under a flow whose endpoint lists the track (a record of that flow, from manifestPort or its manifestTrack, admitting a source packet under step 1 or this step), at which the discard above applies. Within a protected consumer the block extent such a symbol signals is provisional: a block that only such symbols have delimited yields to an admitted repair packet whose (SS_Start, SSB_length) conflicts with it under [MOQ-FEC] Section 7.4, the receiver discarding the provisional block's repair symbols, returning its source symbols to the undelimited state of that section and accepting the admitted packet, so that the first-accepted rule of that section discards an admitted repair packet only for conflict with another admitted one; such a symbol that conflicts with a block an admitted repair packet has delimited is discarded as that section requires. Nor is such a symbol the later signal of [MOQ-FEC] Section 9 or the packet whose receipt anchors a block's ts there, whether or not an admitted repair packet later delimits the block the symbol delimited (that block's ts is the receipt time of the first packet of it, in the order received, that this profile admits), nor does a block only such symbols have delimited take any SS_ID out of a run or stand as the S_prev of the Group range of [MOQ-FEC] Section 7.5: within a protected consumer such a block is held for decoding only, has no ts and no FEC deadline, whatever packets are admitted into or above its range before or after the symbol, and requests no repair, and the SS_IDs in its range that the receiver lacks are, for [MOQ-FEC] Sections 9 and 11.4, runs between the packets the receiver has admitted and the blocks admitted packets have delimited, as if the provisional block were not delimited, each revealed and given its ts only by a packet admitted above it, whether the symbol delimited the block before or after that packet, and classified, requested and cancelled as those sections specify; what the block decodes before such a run's deadline is admitted by its digest, as below, and closes the run or part of it. A relay could otherwise, by one repair packet whose SS_Start lies above what the publisher has sent, give the SS_IDs below it a deadline they reach unrecovered, by one whose range begins at an SS_ID the receiver admitted long ago, delimit a block that takes its ts from that old admission and is past its deadline on arrival, by one whose SSB_length reaches past what the publisher is sending, delimit a block that reaches a deadline before the rest of its range is sent, and force the repair request of [MOQ-FEC] Section 11.4.2 any of those ways, or, by one whose range covers a run that has a ts, take the run's deadline and repair request away, or, by one whose range ends just below a lost SS_ID, narrow the run's Group range to exclude the block that contains it. Under the open-block bound of [MOQ-FEC] Section 9 the receiver discards a block that has no ts before any block that has a ts, whether or not the track derives an FEC deadline, so that the blocks such symbols delimit, however many a relay sends, evict under a memory cap no block of the multicast path; such a discard gives the block no deadline and no class, forces no repair request, drops the block's repair symbols and returns its source symbols to the undelimited state of [MOQ-FEC] Section 7.4. The receiver decodes a block from admitted symbols where they suffice and uses such symbols only for the shortfall. A packet the base instance recovers with such a symbol's help is admitted by its digest like a received datagram, against the pending entries of its window, hashed with the base SS_ID its position in the base block implies (SS_Start + ESI, [MOQ-FEC] Section 8.3) appended for the hash only ([MOQ-FEC] Sections 7.3 and 8.5), and on a miss is held in the MoQ unicast path's hold queue, under that queue's expiry and bound, since only such a symbol, which that path alone delivers, made the decode possible, so that its octets and its expiry count toward nothing of the multicast path. A recovered packet that leaves the queue unadmitted, at expiry or on overflow, is not a symbol the receiver holds for [MOQ-FEC] Section 11.4: a block of which the receiver has not admitted every one of its SSB_length source symbols, received or recovered, is unrecovered for that section and for the release below, at its FEC deadline as at any other time, the receiver keeping the packets it admitted (a decode none of whose recovered packets is admitted recovers nothing, a corrupt symbol among those decoded from corrupting what the decode recovers), and it SHOULD discard the symbols of unlisted tracks that fed a decode that left the block unrecovered and decode again when the symbols it then holds suffice, at most once more per block with such symbols' help: a block that two such decodes have left unrecovered takes no further symbol of an unlisted track into a decode, since a relay could otherwise drive one decode of the block per symbol it sends, while a decode from admitted symbols alone, and the admission of a held packet, remain open to it; a held packet admitted after the deadline recovers the block as a received datagram admitted then would, and the receiver SHOULD cancel a repair FETCH then outstanding for it, as [MOQ-FEC] Section 11.4.2 has it for a repair the next RAP makes moot. A packet recovered from admitted symbols alone, by the base instance or a keyframe overlay, is admitted with them; a packet only the overlay recovers with the help of such a symbol has no base SS_ID to hash with ([MOQ-FEC] Section 7.3) and is not delivered. A receiver that can request unicast repair (Section 6.2) keeps, instead of letting them expire, the pending entries of each open block that has an FEC deadline: those pending at the admission of the first packet, source or repair, that the receiver admits into the block, and those inserted after it (a mirrored record's entries are inserted up to the lead before the datagrams they cover arrive on the multicast path, and under the bound of Section 7.2.5 until the stream generation has measured a lead, so no span reckoned from the lead in force at the admission names them all; the admitted packet is not necessarily the packet whose receipt set the block's ts in [MOQ-FEC] Section 9: a datagram held on a miss is admitted, by step 1, after one that a verified record admitted on arrival, and a symbol of an unlisted track no step admits, nor does one set a ts, so a block only such symbols have delimited has no deadline and keeps no entries as a block, the lost SS_IDs in its range keeping theirs as the runs they are, below), until that deadline (the receiver keeps the admission time with the block). A run of lost SS_IDs that the receiver has not delimited (Section 6.2) is one such block ([MOQ-FEC] Section 11.4) of which it holds no packet, and the receiver learns of the run, and of the block's deadline, only from a packet admitted above it ([MOQ-FEC] Sections 7.4 and 9; step 2), by when the run's entries would have expired; so for each base instance it also keeps the entries pending at the admission of the source packet of highest SS_ID it has admitted, and those inserted after it (keeping that admission time with the instance; a symbol of an unlisted track, which no step admits, is never this anchor however high its SS_ID) until it admits a source packet of the instance above that SS_ID; a source packet admitted below it moves neither that anchor nor the entries so kept (highest, above and below in SS_ID, and the gap below, under the serial number arithmetic of [MOQ-FEC] Section 7.5, so that the anchor follows SS_ID across its wrap to 0). A gap in SS_ID between the two reveals lost SS_IDs, of such a run or of a block that a repair packet alone has delimited ([MOQ-FEC] Section 7.4); each takes the entries so kept as its own from the admission of the source packet of highest SS_ID admitted at or below its lower bounding packet (lower and upper in SS_ID order, [MOQ-FEC] Section 11.4.1; a bounding packet can itself be such a symbol), or of the packet admitted above it where the instance has admitted none below it; otherwise the entries whose expiry has passed by the admission of the packet above are released. The blocks that the admitted repair packets a run's Group range FETCH returns delimit take over the entries so kept; a block that only symbols of an unlisted track the response returns have delimited is provisional as above and takes none, the run keeping its entries, against which the decode of that block admits its recovered packets, until the run is recovered or its requested repair, the FETCH on each layer it needs ([MOQ-FEC] Section 11.4.2), completes without recovering it, fails or is cancelled. They are block state under the bound of [MOQ-FEC] Section 9 and are released when the block is recovered, when its deadline passes with no repair requested, when a requested repair, the FETCH on each layer it needs, completes without recovering the block, fails or is cancelled ([MOQ-FEC] Section 11.4.2), or when the block is discarded under that bound.¶

Replay. Receivers in an explicitly configured DVR or replay mode MAY relax the epoch, floor and freshness checks. Clock. The freshness check needs a receiver clock synchronized to UTC within 5 s. A receiver without one MAY skip that check alone; it then accepts any window of the current epoch at join and has no protection against replay of the epoch's earlier windows until its first verified record sets the floor (Section 7.2.8).¶

Key rotation. A key change is an epoch change (Section 7.2.3). The publisher adds the next kid to the catalog with the firstEpoch at which it will sign, at least one catalog lifetime ahead; signs with it from that epoch; and raises minEpoch. A receiver that holds that catalog accepts the retired kid below the successor's firstEpoch only, so records the retired key signs are admitted on manifestPort until that path's grace period for the new epoch ends, or while that path has started none, but never past the bound of Section 7.2.5 plus maxAuthDelayMs + 2 x manifestTimerMs after the new epoch became current, and on the manifest track only within the earlier-started of the two paths' periods (step 1 of Section 7.2.7); a receiver that verifies no record of the new epoch keeps the epoch before it current, which the retired key still signs, and a receiver whose catalog or pin predates the rotation is exposed to the retired key until it re-fetches or is re-provisioned (Section 7.2.8). A record with an unknown kid triggers at most one catalog re-fetch per 30 s per receiver; until then such records are dropped. Whenever a re-fetch or a re-provisioning changes the key set or a kid's range, the receiver re-applies the range check of Section 7.2.6 to the (kid, epoch) that set each flow's current epoch; where it now fails, the receiver discards that flow's state as it does on a streamId change (above), the digest of every held datagram included, and returns to the join state of step 1, so a record a retired key signed before the re-fetch cannot hold the flow afterwards. Revocation is key removal, effective within one catalog lifetime.¶

Cost. A datagram from another source costs one address comparison; one that spoofs S, or that a relay delivers on a MoQ unicast path, costs one hash, two lookups and, on a miss of both, space in its path's hold queue until expiry, so a copy of an admitted datagram costs one hash and two lookups; an injected record costs at most one verification inside the budget, a replayed one whose (kid, epoch, mseq) is still verified one lookup and one hash whatever its age (the already-verified lookup of step 1 precedes the freshness check), one outside the verified set and outside the freshness tolerance that lookup alone, a miss, before the epoch floor, the replay floor or the freshness check drops it, the second copy of a verified record one lookup and one hash plus, where the first arrived on the manifest track and this is the first copy on manifestPort and raises the mirror's lead, the re-handling of its own pairs and of the pairs kept for the records mirrored while it was in flight, which no later copy of the record repeats and which the lead's rise by multiples of manifestTimerMs (Section 7.2.5) bounds to 5000 / manifestTimerMs raises in a stream generation, 250 at the default, each over at most the records the manifest track's bucket admitted within the raised lead (step 1), and a corrupt symbol of an unlisted track at most two decodes of its block. With one verification per 37 datagrams, a Cortex-A53 without SHA2 instructions spends about 0.26 of a core at 100 Mbit/s and at most 0.43 of a core under a record flood at a budget of 1000/s, or 0.6 of a core on a receiver that also reads the manifest track, whose second bucket admits another 1000/s; a core with SHA2 instructions spends a fraction of that.¶

7.2.8. Threat Model

This profile protects against off-path and on-segment UDP injection, against corrupted or attacker-injected FEC symbols, and against replay: a (record, datagrams) pair cannot be moved to another endpoint, stream generation, broadcast, key or epoch (Section 7.2.4); an earlier epoch is rejected at join by minEpoch (Section 7.2.6) and, on a receiver that pins keys, by the epoch floor kept with the pin, and after the first verified record by the current epoch, the previous epoch admitted on manifestPort until that path's grace period ends, or while that path has started none, and never past the previous epoch's deadline, the bound of Section 7.2.5 plus maxAuthDelayMs + 2 x manifestTimerMs after the current epoch became current, and on the manifest track within the earlier-started of the two paths' periods (Section 7.2.7); and within an epoch a receiver with a UTC-synchronized clock admits no window whose record was emitted more than 7 s + maxAuthDelayMs before receipt, so the verification budget cannot be spent with stale genuine records and the replay floor of Section 7.2.7 takes over after the first verified record. A receiver that skips the freshness check can be fed the current epoch's earlier windows at join, and an injector that keeps its budget spent can hold it there; a unicast receiver that widens its tolerance by W (Section 7.2.5) can likewise be started at a window up to W old, 5 s at most, by the relay that buffers for it. What a relay delivers to a consumer, of the tracks a flow's endpoint lists, before the admission that makes the consumer protected under that flow is discarded at that admission unless admitted by then (Section 7.2.7), so a relay that leads the multicast path during the join cannot leave its own copy of a symbol in place of the admitted one. A relay that leads the multicast path and withholds records from the mirror moves no replay floor and no grace period the multicast copies of those records meet, each path keeping its own, and, leading it by no more than the bound of Section 7.2.5, makes the previous epoch's deadline drop only a copy reordered more than maxAuthDelayMs + 2 x manifestTimerMs behind the new epoch's first record (step 1 of Section 7.2.7), so a healthy multicast path loses no window to what the mirror omits, absent the injector of the availability paragraph below, and a relay that lets the receiver measure a small lead and then leads by more, within the bound of Section 7.2.5, gains nothing either, the copy on manifestPort that raises the lead re-admitting or re-inserting, under the raised lead, ahead of their datagrams, the digests of that record and of the records mirrored while it was in flight, for the pairs that have admitted nothing and have no pending entry, widening the pending entries of those records by the raised lead, and recording again as admitted, under the raised lead, the digests of the pairs that have, so that a copy an injector replays within the retention, which measures nothing, re-admits no datagram and a late multicast copy of a datagram the relay delivered is dropped rather than held (step 1 of Section 7.2.7). Because every endpoint of a sending entity that carries auth is protected (Section 7.2.6), an endpoint without auth cannot share a FEC instance, a keyframe overlay or the signaling sub-flow with a protected one.¶

Catalog rewrite and key substitution are defended only for receivers that hold an out-of-band key pin. The digest algorithm is inside the signed record, so a rewrite can remove auth, substitute keys or lower minEpoch; the pin catches the first two and the per-kid epoch floor kept with it (Section 7.2.7) the third, except at a receiver's first join under a kid, where a lowered minEpoch admits records of an earlier epoch signed with a still-listed kid until a record of the current epoch is verified, and after that as the previous epoch (step 1 of Section 7.2.7), so rotated-out keys SHOULD be removed promptly. A rewrite that raises minEpoch costs a receiver, pinned or not, that session's data and nothing more, since neither carries a catalog value past the session (Section 7.2.7). Rewriting any other member of the endpoint or its auth only makes genuine records fail the signature or ctx check, or resizes the hold queues and pending expiry (bandwidth, maxAuthDelayMs, manifestTimerMs), which a receiver bounds by local policy (Section 7.3).¶

The profile protects integrity, not availability. A forged record passes every check of step 1 of Section 7.2.7 up to the signature, so each one spends a token of the verification budget: an attacker who sustains more than 1000 records per second on the manifest port (about 1.3 Mbit/s of 164-octet records) takes a share of the budget proportional to its rate, and at several times that rate both copies of a window lose their tokens and the flow yields no data. The budget bounds the receiver's CPU, and the lead's rise by multiples of manifestTimerMs bounds the re-handling a raise costs outside it (Cost, Section 7.2.7); it does not raise the cost of this attack, and the record flood is not the cheapest availability attack on every protected flow: a datagram on the data port that matches no pending entry is held on the multicast path until it expires (step 2 of Section 7.2.7), and those expiries are loss for the failover below, so an injector that sustains, with the same access as the record flood, the loss fraction at which the receiver fails over moves it to the unicast fallback for less than the 1000 records per second the record flood needs wherever that fraction of the flow's packet rate is below it, as on every audio flow and most low-rate video; only evicting genuine datagrams, by overflowing the multicast path's hold queue, needs the endpoint's bandwidth (a relay on a MoQ unicast path can fill only its own path's queue, without spoofing, and that path's availability is already its to withhold; a symbol of an unlisted track it delivers gives no block or run a ts or a deadline, whatever admitted packets lie in its range, takes no SS_ID out of a run, and delimits a block that is decoded only, never requested, the SS_IDs it covers that the receiver lacks staying runs that admitted packets alone reveal, and the blocks only such symbols delimit are discarded under the open-block bound of [MOQ-FEC] Section 9 before any block that has a ts, so it forces no repair request, evicts no block of the multicast path and fails no check of [MOQ-FEC] Section 6.3.9 closed, step 2 of Section 7.2.7; a corrupt symbol of an unlisted track it delivers leaves unrecovered only a block the admitted symbols could not recover alone, costs at most two decodes of that block, and what a decode it corrupts recovers is held on, and expires from, that relay's own queue, step 2 of Section 7.2.7). A receiver that reads the manifest track has a second bucket of the same shape, so its ceiling is 2000 verifications per second, half of them spendable by its relay without spoofing anything (Cost, Section 7.2.7). On an SSM endpoint reached natively either flood must spoof S or be on path; on an ASM endpoint any host that can send to the group suffices, and so it does behind an AMT gateway, where a flood need only spoof the relay's address toward the gateway (Section 7.2.7). With that access an injector forges nothing: a genuine record it reads from the manifest track, as any subscriber can, and sends on manifestPort more than maxAuthDelayMs + 2 x manifestTimerMs (240 ms at the defaults) before the multicast path delivers the datagrams it covers is verified there with unwidened pending entries, which expire before those datagrams arrive, so they are held, and the sender's own copy, dropped by the already-verified lookup, admits nothing (step 1 of Section 7.2.7); one record per window is then loss of every window for the failover below, at most 50 a second at the default manifestTimerMs on a flow the timer governs and one per 37 datagrams on a flow above 1850 datagrams a second (Section 7.2.5), less than the data-port injection above needs wherever the failover fraction of the flow's packet rate exceeds that window rate, above 50 a second on the former and above a thirty-seventh of the packet rate on the latter, at a lead of at most 64 windows; at a lead of L windows above that, the omission below costs one record per L - 63 windows. On a receiver that reads the manifest track the outcome turns on arrival order. For a record the receiver's mirror delivers before the injector's copy, that copy, replayed from the mirror ahead of the sender's, is the record's first copy on manifestPort and measures the lead, so the sender's copy and the twin measure nothing and the re-handling that a raising copy affords (step 1 of Section 7.2.7) is not afforded against it. Where no larger interval has been measured in the stream generation this pins the lead at the injector's replay interval, rounded up to a multiple of manifestTimerMs as step 1 rounds it, so the entries of every later record the mirror delivers are widened by that lead alone and are short of their datagrams wherever the mirror delivers the record more than that lead plus maxAuthDelayMs + 2 x manifestTimerMs before the multicast path delivers the datagrams it covers, which the geometry of the attack (the injector's copy preceding those datagrams by more than maxAuthDelayMs + 2 x manifestTimerMs) meets up to the rounding, under manifestTimerMs: they are held and expire as a record the injector's copy brings to manifestPort first does below, the attack succeeding for every such record whose first copy on manifestPort the injector keeps supplying, with no race against the mirror to win. It ends at the first such record whose first copy on manifestPort is the sender's (the injector idle, or its copy lost or arriving after the sender's): that copy measures the interval from the mirror's delivery to its own arrival, which the geometry puts above the pinned lead, raises the lead to it (capped at the bound of Section 7.2.5) and affords the re-handling of step 1 of Section 7.2.7, so that from then the next case applies. A lead the sender's copies measured larger, before the injector began or at such a record, is never lowered (Section 7.2.5) and keeps widening the entries of mirrored records, so their datagrams are admitted on arrival and the attack fails for such a record while the interval from the mirror's delivery of a record to the multicast path's delivery of the datagrams it covers stays within that lead plus maxAuthDelayMs + 2 x manifestTimerMs; an interval that later grows past it is not absorbed, since the sender's copy that would have raised the lead and afforded that re-handling is dropped by the lookup and measures nothing, so those datagrams are held and expire as below. A record the injector's copy brings to manifestPort before the receiver's mirror delivers it is verified there with unwidened entries whatever lead the receiver has measured, and the mirror's later copy, dropped by the already-verified lookup, measures nothing and widens nothing (step 1), so its datagrams are held and expire as on a receiver that reads no manifest track; an injector wins that race on every record where its copy reaches the receiver sooner than the receiver's mirror does, its read of the manifest track and its injection path to the receiver counted together against the mirror's delivery delay. The injector's copy also raises the highest_mseq of manifestPort and starts its grace period early, which drops the sender's copies of a record only where the injector's copies lead the multicast path at the receiver by 64 windows, less the windows by which the record's twin lags it where the record's own copy was lost on the multicast path (two at the RECOMMENDED placement of Section 7.2.5, up to 63 under its bound, which assumes that only the sender's records raise the floor of step 1), and those of a record of the previous epoch once a grace period so started has run. The first needs the injector's copies to lead the multicast path at the receiver by that many windows; the second, to lead it by more than maxAuthDelayMs + 2 x manifestTimerMs (240 ms at the defaults), a lead within the bound of Section 7.2.5 on any flow: the injector's copy of the new epoch's first record starts the period that long before the multicast path delivers that record, which the last twins of the previous epoch immediately precede (Section 7.2.5), so a record of the previous epoch, its own copy or its twin, that arrives on manifestPort within the excess of the lead over the period before that record is dropped. A copy the receiver's own mirror delivers meets the higher floor and the earlier-started period (step 1), so it is dropped as well where the injector's copies lead that mirror by as much, by 64 windows for the first drop and by more than the period for the second; a window expires where every copy of its record is so dropped, the injector having sent none ahead, whether its mirror lost the record, its relay withheld it or it omitted the record itself, and the receiver's mirror delivering none or a late one. The omission is the cheaper attack where the lead allows it: a record of mseq k the injector sends raises highest_mseq to k, so the sender's copies of every record of mseq at most k - 64 whose copies have yet to arrive are dropped, and an injector whose copies lead the multicast path at the receiver by L windows, L above 64, loses every such window, on a receiver that reads no manifest track or whose mirror those copies also lead by at least as much, with one record per L - 63 windows, against the one record per window the replay above costs; where they lead the receiver's mirror by fewer windows, M, the records the mirror delivered before the injector's are verified there, their sender's copies dropped by the already-verified lookup, which precedes the floor in step 1, and their windows admitted as a record whose first copy on manifestPort is the sender's has it above: that copy, dropped as already verified but the record's first on that port, measures the interval from the mirror's delivery to its own arrival and, where that exceeds the lead in force, raises it and affords the re-handling of step 1, the entries that lead widened admitting their datagrams on arrival where it does not; so each record it sends loses only the M - 63 windows the mirror delivers after it, none of them where M is below 64 and one, the cost of the replay, where M is 64, and whichever of the L - 63 the receiver's mirror delivers none of, whose sender's copies alone arrive and are dropped by the higher floor whatever M is, as the expiry above has it. The windows of its own records follow the arrival-order cases above: on a receiver that reads no manifest track or whose mirror the injector's copy precedes, they are lost by that replay where the lead also exceeds the period and admitted, by the unwidened entries of its copies, where it does not, as on a flow the count cap governs (Section 7.2.5) whose rate, above about 9,900 datagrams a second at the defaults, closes 64 windows within maxAuthDelayMs + 2 x manifestTimerMs, so that an injector leading by more than 64 windows but by less than the period harms nothing by replaying and costs a window only by omitting its record; where the receiver's mirror delivered the record first, they are admitted by the entries the measured lead widened, within that lead plus the period. The injector chooses which mirror it reads but makes no mirror deliver earlier, and the statements of this section about a relay assume no such sender on the group. Datagrams that expire from the multicast path's hold queue are loss for the failover of Section 4.1 and Section 6, those that expire from the unicast path's queue are not, a held copy that step 1 drops because a record admitted another copy of the same datagram expires from neither, and, absent such an injector, a relay that leads the multicast path by no more than the bound of Section 7.2.5 produces none, its admitted digests and pending entries outliving the lead the receiver applies, which that bound caps (step 1), the copy on manifestPort that raises that lead, when the relay leads by more than the receiver has measured, re-admitting or re-inserting, under the raised lead, before their datagrams arrive, the digests of that record and of the records mirrored while it was in flight, for the pairs that have admitted nothing and have no pending entry, widening the pending entries of those records by the raised lead, and recording again as admitted, under the raised lead, the digests of the pairs that have, so that the late multicast copies of datagrams the relay delivered are dropped as copies rather than held, and what the relay delivers or withholds on the mirror moving no replay floor and no grace period a multicast copy meets (step 1 of Section 7.2.7); a receiver SHOULD also count records that the manifestPort bucket dropped for want of a token toward that failover, so a sustained record flood ends in the unicast fallback of Section 7.2.5, a MoQ subscription outside this profile unless the receiver verifies it against the records of a manifestTrack (step 2 of Section 7.2.7), rather than in silence. Records the manifest-track bucket dropped count toward nothing of the multicast path: a relay that floods the mirror could otherwise move a receiver with a healthy multicast path onto itself. A receiver that holds the catalog naming the successor key accepts the retired kid only below the successor's firstEpoch (Section 7.2.6), and records of the previous epoch on manifestPort until that path's grace period ends, or while that path has started none, and never past the bound of Section 7.2.5 plus maxAuthDelayMs + 2 x manifestTimerMs after the new epoch became current, and on the manifest track within the earlier-started of the two paths' periods (step 1), so for that receiver a key retired at an epoch boundary signs records admitted on a path for at most maxAuthDelayMs + 2 x manifestTimerMs after the new epoch's first record is verified there, or dropped there as its byte-identical copy, and on any path for at most the bound of Section 7.2.5 plus maxAuthDelayMs + 2 x manifestTimerMs (5.24 s at the defaults) after the new epoch became current, however many of the new epoch's records an attacker drops on manifestPort. An attacker that drops every record of the new epoch on each path a receiver reads, the multicast path alone on a receiver that reads no manifest track, keeps the epoch before the change current at that receiver, and, holding the retired key, signs records that receiver admits until a record of the new epoch reaches it, a catalog removes the retired kid or the receiver is re-provisioned, minEpoch binding only a join. A receiver with an older catalog is exposed to the retired key until it re-fetches, one catalog lifetime plus the 30 s re-fetch interval of Section 7.2.7 at most, and a pinned receiver until it is re-provisioned.¶

Losing both copies of a window leaves at most 37 datagrams unauthenticated, which expire from the hold queues. Latency of authentication is bounded by maxAuthDelayMs on the multicast path and by maxAuthDelayMs + W on a MoQ unicast path, W being the widening of Section 7.2.5. Digest i of a record covers sequence = first_seq + i, so loss and reordering within a flow are detectable ([I-D.ietf-mboned-multicast-security] Section 2.3), and no mode of this profile delivers an unauthenticated datagram (Section 2.4.4 of that document).¶

7.2.9. Broadcast Carriage

Hybrid receivers that also hold the MoQ catalog verify datagrams of the flow from any path, a MoQ unicast path included, against the same records (Section 7.2.2); a symbol of an unlisted track, one that no endpoint of a flow the consumer is protected under lists, is not a datagram of any such flow, and what it helps the base instance recover is admitted by digest (Section 7.2.7). A broadcast carries the flow as an MMTP service ([ATSC-A331] Section 8.1.2.1; [ARIB-B60]): the flow's datagrams are the MMTP packets of one MMTP session, carried as the UDP datagrams the sender emits, each the whole MoQ UDP payload, trailer included, on the endpoint's S, G and port, and the records are the sender's record datagrams on manifestPort of the same S and G, both copies (Section 7.2.5), carried in the same IP multicast of the broadcast. A broadcast that re-addresses either flow, or carries the datagrams in any other form, is not covered: the pseudoheader binds S, G and the ports (Section 7.2.2), and a record verifies as it was signed or not at all. A broadcast-only receiver reads both UDP flows of the broadcast, forms the pseudoheader and signed_message from the endpoint's S, G, port, streamId and manifestPort, and holds those values and the keys by provisioning (Section 7.2.7): the SLS of the service describes the MMTP session ([ATSC-A331] Section 7.2) and nothing of this profile, so manifestPort and the rest come from provisioning alone, and this document specifies no in-band carriage of them. A record so read is a record on manifestPort for step 1 of Section 7.2.7, as on any multicast path.¶

7.2.10. Hash Algorithms

hash_alg is a Suite ID of the IANA Named Information Hash Algorithm Registry ([RFC6920] Section 9.4), a value from 0 to 63; values 64 to 255 are not Suite IDs and MUST NOT be sent. Only a suite whose output is 256 bits is usable, since every digest field is 32 octets; the truncated suites MUST NOT be used. Suite 1, sha-256 [FIPS180-4], is mandatory to implement. A receiver MAY implement other 256-bit suites; it drops a record whose hash_alg it does not implement (Section 7.2.7).¶