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)

Image: Luby, M. and V. Goyal, "Wave and Equation Based Rate Control Using Multicast Round Trip Time: Extended Report”, p20

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

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
• ught to be regarded as abnormal.”

Why it needs to be a standard

Different domains need to interoperate

ingress: knows bandwidth egress 1: prune decision egress 2: prune decision can’t rely on receiver

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)

Send bandwidth advertisements + optional PIM population count for fair pruning decisions (RFC 6807, experimental) Notice oversubscribed links, prune or block flows.

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