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

Multicast Utopia I want to run a service in a world like this, serving thousands of video channels to millions of users over the internet high bandwidth to those who can, lower bandwith to others. --- vast efficiency gains theoretically possible for things delivered by multicast to wide audiences live events happen often. some are popular, all could theoretically get more efficient video transmit even for non-linear content, efficient shared transmission is a coordination problem, not inherently unsolvable. Pre-registering for books and games is similar and significant: imagine $3 off for signing up ahead of time for a movie. video at scale is an akamai grand challenge, as defined by our fearless leader: https://arc.applause.com/2015/07/15/tom-leighton-akamai-interview/ linear tv still relevant, despite declines, with year-over-year growth in some circumstances: - http://www.huffingtonpost.com/advertising-week/this-is-not-the-death-of_b_9569538.html - https://www.wired.com/2016/05/nope-tv-business-isnt-dead-yet-far-really/

Elements of trouble sending rate does not respond to receivers that don’t feed back congestion control depends on well-behaved receivers receiver-based: WEBRC [RFC 3738] (building block of ALC [RFC 5775]) feedback-based: NORM [RFC 5740]

Multicast with one Compromised Machine 80%+ loss

Solution: Circuit Breaker From draft-ietf-tsvwg-circuit-breaker-15

Why it needs to be a standard egress 1: prune decision egress 2: prune decision can’t rely on receiver ingress: knows bandwidth Different domains need to interoperate

Circuit Breaker Assisted Congestion Control draft-jholland-cb-assisted-cc: (tries to implement the example circuit-breaker from draft-ietf-tsvwg-circuit-breaker, section 3.2.1) https://tools.ietf.org/html/draft-jholland-cb-assisted-cc-00 - potential problem: inter-domain explicit rate signaling is contraindicated: https://tools.ietf.org/html/rfc6077#section-3.5.2 (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: https://tools.ietf.org/html/rfc5783#section-5 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)