Protecting Multicast Enabled Networks

Matthew Davy Indiana University

outline

• overview • vulnerabilities • sender-based • receiver-based • short-term protection options • possible long-term solutions

what’s unique about multicast ?

• by simply sending an IP packet, any host can...

• create control plane state in routers & switches • force routers & switches to generate & process protocol packets • flood a large number of hosts with a large traffic stream

why is this a problem ?

• hosts can intentionally or unintentionally generate a DoS attack on multicast enabled routers & switches by overloading the control plane • worms which scan 224/4 are the most common problem • several worms have unintentionally disrupted many multicast enabled networks (ramen, slammer, etc)

sender-based vulnerabilities

• address • the first router (aka the PIM DR)...

• creates a multicast route (s,g) • result = memory allocation on RP/RE (rib) and forwarding hardware (fib) potential for memory exhaustion • encap. data packet inside PIM register and sends to RP • result = processor cycles on the DR & RP - potential for CPU exhaustion

sender-based vulnerabilities {ASM}

• the PIM RP...

• receives PIM Register [processor] • creates (s,g) state [memory] • deencap. the data packets [processor] • forwards the packets down the shared tree [processor] • sends PIM join towards source [processor]

sender-based vulnerabilities {ASM}

• if it’s also an MSDP speaker, the RP...

• creates MSDP SA state [memory] • sends MSDP SA w/encap. data to all MSDP peers [processor] • Note: MSDP SAs are flooded to every MSDP speaker on the Internet !

sender-based vulnerabilities {ASM}

• every MSDP speaker on the Internet...

• receives the MSDP SA and deencap. the data packet [processor] • creates MSDP SA state and forwarding state [memory] • forwards the data packet down shared tree [processor]

does ssm solve this

•

problem ?

SSM does not have sender-based vulnerabilities !

• first hop router simply drops pkts if no forwarding state (hopefully in ASIC) • no PIM Registers = no data packets inside control plane packets • no MSDP = packets can’t reach all MSDP speakers & no data packets inside control plane packets • SSM still has receiver-based vulnerabilities

receiver-based

• •

vulnerabilities

{SSM & ASM} when a host joins a multicast group, it sends an IGMP host report packet to a mcast group • ethernet switches often snoop IGMP packets [memory & processor] the first hop router...

• creates (*,g) and/or (s,g) state if necessary [memory] • sends PIM join towards RP (ASM) or towards source (SSM) [processor]

receiver-based vulnerabilities

{SSM & ASM} • every router in the path...

• receives a PIM join packet [processor] • creates forwarding state as necessary [memory] • unintentional receiver-based attacks are unlikely

protection options

{sender-based} • on first hop routers, filter mcast packets to “unusable” groups • see http://www.iana.org/assignments/multicast addresses • see http://www-fp.mcs.anl.gov/~nickless/draft nickless-ipv4-mcast-unusable-02.txt

• prevents creation of forwarding state and PIM register processing for unusable groups

a bit on “unusable” groups

• ethernet mac overlaps with 224.0.0.0/24 (225.0.0.0/24, 225.128.0.0/24, etc) • should not use, but a few people are • what about “reserved” addresses ?

• • • 224.3.0.64 - 224.251.255.255

225.0.0.0-231.255.255.255

234.0.0.0-238.255.255.255

• might reduce impact of worms significantly by eliminating use of this address space

protection options

{sender-based} • on PIM RP, filter register packets. only allow packets from your source addresses and “usable” group addresses • this prevents unnecessary register processing and forwarding state creation on the RP • redundant if all DRs have same filters, but...

protection options

{sender-based} • on all MSDP speakers...

• filter SAs by source, group, & RP as appropriate (see “unusable” addresses) • only allow your GLOP space going out; block your GLOP space coming in • set limits on total SAs from each peer

protection options

{sender-based} • on all MSDP speakers...

• set per-source SA limits (juniper); cool feature. need per-source PIM Register limits too • set per-instance SA limits • rate-limit all MSDP traffic destined to router • turn off data encap for msdp ?

protection options

{sender-based} • on all multicast routers...

• rate-limit total PIM traffic to the router • rate-limit all 224/4 traffic to the router • block mcast packets to “unusable” groups

protection options {sender-based}

• on all multicast routers...

• only allow udp to 224/4; exceptions for pim, ospf, etc • disable sdr/sap • set forwarding table limits (juniper) • ‘set routing-options multicast forwarding cache’

protection-options

{receiver-based} • on all multicast routers...

• rate-limit PIM and IGMP packets • per interface multicast route limits would be useful • per-port mac limits in switches; not sure if this applies to igmp snooping. if it doesn’t, it should

summary

• SSM solves sender-based vulnerabilities. will ASM cease to be supported for inter domain ?

• blocking reserved groups would help a lot • so would turning off data encap for msdp • so would per-source pim and msdp limits • more features from vendors to protect multicast enabled routers & switches