Protecting Multicast-Enabled Networks

1. Protecting Multicast-Enabled Networks • Matthew Davy • Indiana University

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

3. 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

4. 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)

5. sender-based vulnerabilities{ASM} • when host sends a packet to a 224/4 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

6. 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]

7. 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 !

8. 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]

9. 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

10. 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]

11. 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

12. 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

13. 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

14. 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...

15. 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

16. 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 ?

17. 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

18. 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’

19. 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

20. 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