1. Malicious Overjoining in Multicast
Problem and proposed solution
draft-jholland-cb-assisted-cc
Jake Holland, Akamai Technologies

2. Multicast with one Compromised Machine
The problem is that nothing stops receivers from joining any flow. By joining (well-behaved) senders’ non-responsive multicast channels, you can DoS receiver-side links.
Attack capacity is max groups per receiver*count of compromised machines*highest bandwidths of reachable flows on the internet.
By contrast with unicast, one cannot infer that failure of any flow to back off under persistent congestion is a non-bcp41-compliant sender, only that there exists at least one non-compliant receiver downstream.
We believe this problem will prevent us from scaling up a multicast video delivery service, unless there is a solution that can preserve the safety of the receiving networks.
80%+ loss

3. Circuit Breaker Assisted Congestion Control
Main point: draft is intended as an attempt to implement the multicast circuit-breaker example from , with the egress in-network (not the endpoint receiver). Ultimately, a solution which is interoperable between domains seems necessary to safely deploy multicast.
- potential problem: inter-domain explicit rate signaling is contraindicated: (does this require giving up on inter-domain multicast?)
IRTF advice does not seem to rule out the concept of interdomain cooperative signaling, with ECN as a prominent example:
Neither of those is normative.
- on-path attacks discussed in the draft. (maybe more problematic is shared ipx links, which count as on-path in this context?)
- note also: this assumes it’s better to cut off a flow entirely than to partially pass many flows degraded. This may not be true for everything.
Notice oversubscribed
links, prune or block
flows.
Send bandwidth advertisements
+ optional PIM population count for fair pruning decisions (RFC 6807, experimental)