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

2. outline overview vulnerabilities sender-based receiver-based short-term protection options possible long-term solutions 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 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) 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 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] 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 ! 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] 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 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] 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 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 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 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... 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 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 ? 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 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’ 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 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 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