Malicious Overjoining in Multicast Problem and proposed solution - PowerPoint PPT Presentation

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

Multicast Utopia

Requirements Multicast Bulk Rate applications: • MUST tolerate a wide range of Internet path conditions [1] • SHOULD implement congestion control [2] • feedback-based (scales to thousands, e.g. NORM [3]) • receiver-driven (scales to millions, e.g. FLUTE [4]) [1] UDP BCP section 3 (draft tsv rfc5405-bis-19, a work in progress) [2] UDP BCP section 4.1.1 [3] RFC 5740 section-5.5.2 [4] RFC 6726 section 4 (b), requires RFC 5775 section 2.2 (ALC), requires “at minimum” support for RFC 3738 (WEBRC)

Receiver-driven Congestion Control • WEBRC: RFC 3738 (experimental), 2002 • referenced by ALC: RFC 5775 (proposed standard) • RLM (McCanne, Vetterli, Jacobson, 1996) • RLC (Iannaccone, Rizzo, 1999) • PLM (Legout, Biersack, 2000) • FLID-DL (Byers, Horn, Luby, Mitzenmacher, Shaver, 2002) • PSLM (Li, Munro, Kaleshi, 2005)

WEBRC (receiver view) Images: Luby, M. and V. Goyal, "Wave and Equation Based Rate Control Using Multicast Round Trip Time: Extended Report”, p6

WEBRC (sender view) Non-responsive if receiver doesn’t leave. “Note there is no way at the transport layer to prevent a join message propagating to the next-hop router.” - draft-ietf-tsvwg-rfc5405-bis-19, 4.1 Image: Luby, M. and V. Goyal, "Wave and Equation Based Rate Control Using Multicast Round Trip Time: Extended Report”, p20

Multicast with one Compromised Machine 80%+ loss

Non-solutions • Limit the group count for receivers • attacker joins only higher-bandwidth flows • a few compromised machines join disjoint sets of flows • attack capacity is total bandwidth from active senders on the internet • Use feedback-driven congestion control instead • vulnerable to DOS by under-reporting rate • If anyone can receive HD video, you still have the same problem (attacker joins high-bandwidth flows and doesn’t feed back) • can’t scale as well • Bandwidth limit for multicast (or UDP) • this is still a DoS for multicast (though it does keep the network safe)

Maybe solution: Circuit Breaker From draft-ietf-tsvwg-circuit-breaker-15

Maybe solution: Circuit Breaker draft-ietf-tsvwg-circuit-breaker-15, selected quotes: • “Circuit Breakers are recommended for non-congestion- controlled Internet flows and for traffic aggregates” • “a protection mechanism of last resort to avoid persistent excessive congestion impacting other flows that share network capacity” • “Designers of other protocols and tunnel encapsulations also ought to consider the use of these techniques as a last resort to protect traffic that shares the network path being used.” • “The operational conditions that cause a Circuit Breaker to trigger ought to be regarded as abnormal.”

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 “Figure 3 shows one example of how a multicast Circuit Breaker could be implemented at a pair of multicast endpoints (e.g., to implement a Fast-Trip Circuit Breaker, Section 5.1). The ingress endpoint (the sender that sources the multicast traffic) meters the ingress load, generating an ingress measurement (e.g., recording timestamped packet counts), and sends this measurement to the multicast group together with the traffic it has measured.” - draft-ietf-tsvwg-circuit-breaker-15, section 3.2.1 • CBACC tries to implement the given example, with egress in-network

CBACC (draft-jholland-cb-assisted-cc) Notice oversubscribed links, prune or block flows. Send bandwidth advertisements + optional PIM population count for fair pruning decisions (RFC 6807, experimental)

Consensus Questions • Can we agree that overjoining should have a standards-based solution, to better promote safe deployment of multicast over the general internet? • Can we recommend to tsvwg that the example from draft-ietf-tsvwg- circuit-breaker-15 section 3.2.1 be considered for development into a proposed standard, unless or until there is an alternate proposal which directly addresses malicious multicast group joiners?

Key differences toUnicast Oversubscription 1. Unicast well-behaved sender always backs off under persistent connection • therefore any node detecting senders that don’t back off can cut them off as non-compliant • by contrast, well-behaved multicast senders get no feedback from malicious receivers 2. Multicast can prune from transit node 3. Scope • requires enough non-responsive senders to attack each receiving network separately