1 / 20

Protecting Multicast-Enabled Networks

Learn about sender-based and receiver-based vulnerabilities in multicast networks, short-term protection options, long-term solutions, and unique features of multicast technology. Explore ways to secure multicast traffic and mitigate potential attacks.

quynh
Download Presentation

Protecting Multicast-Enabled Networks

An Image/Link below is provided (as is) to download presentation Download Policy: Content on the Website is provided to you AS IS for your information and personal use and may not be sold / licensed / shared on other websites without getting consent from its author. Content is provided to you AS IS for your information and personal use only. Download presentation by click this link. While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server. During download, if you can't get a presentation, the file might be deleted by the publisher.

E N D

Presentation Transcript

  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

More Related