Best Current Practices

1. Best Current Practices

2. Best Current Practices • There's a lot of uncollected experience out there – compilation and documentation of BCPs is badly needed! • There is an Internet2 Network multicast cookbook. In particular, note the links at:http://noc.net.internet2.edu/i2network/multicast-cookbook.html#further

3. Some BCPs forMulticast TCAM Problems

4. Multicast TCAM Problems • First make VLAN ACLs to block ICMP and TCP to 224/4. This will at least catch poorly-written address scanners that are either pinging or trying to opena TCP connection. • On 6500 do "mls ip multicast threshold" to limit the packet rate at which multicast entries get added to the TCAM. This way, slow scans don't take up TCAM slots. • Graph the mroute MIB to see what ASM groups are popular. You'll be floored by how many belong to Norton Ghost. 229.55.150.208 is one of them.

5. Multicast TCAM Problems • Set up multicast boundaries for admin scoped groups like 239.255/16 to be link local unless you really care about them working campus-wide. These include Microsoft SSDP and Apple's discovery protocols. • Block IAPP (Inter Access Point Protocol) if you aren't doing so already. • See http://noc.net.internet2.edu/i2network/multicast-cookbook.html#MSDP_Filter_contentsand http://noc.net.internet2.edu/i2network/multicast-cookbook.html#furtherfor other bogons to block.

6. Some BCPs forMulticast Security

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

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

9. 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 • encapsulates data packet inside PIM register and sends to RP • result = processor cycles on the DR & RP - potential for CPU exhaustion

10. Sender-based Vulnerabilities: ASM • The PIM RP... • receives PIM Register [processor] • creates (S,G) state [memory] • de-encapsulates the data packets [processor] • forwards the packets down the shared tree [processor] • sends PIM join towards source [processor]

11. Sender-Based Vulnerabilities: ASM • If it’s also an MSDP speaker, the RP... • creates MSDP SA state [memory] • sends MSDP SA with encapsulated data to all MSDP peers [processor] • Note: MSDP SAs are flooded to every MSDP speaker on the Internet !

12. Sender-Based Vulnerabilities: ASM • Every MSDP speaker on the Internet... • receives the MSDP SA and deencapsulates the data packet [processor] • creates MSDP SA state and forwarding state [memory] • forwards the data packet down shared tree [processor]

13. Does SSM Solve This Problem? • SSM does not have sender-based vulnerabilities ! • First hop router simply drops packets 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

14. Receiver-Based Vulnerabilities: SSM & ASM • When a host joins a multicast group, it sends an IGMP host report packet to a multicast 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]

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

16. Protection Options: Sender-Based • On first-hop routers, filter multicast packets to unusable groups. See http://www.iana.org/assignments/multicast-addresses • Prevents creation of forwarding state and PIM register processing for unusable groups

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

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

19. Protection Options: Sender-Based • On all MSDP speakers... • filter SAs by source, group, & RP as appropriate (see “unusable” addresses) • Note the "Proposed MSDP filtering changes on Abilene" thread on wg-multicast@internet2.edu • begins with https://mail.internet2.edu/wws/arc/wg-multicast/2006-05/msg00056.html • set limits on total SAs from each peer

20. 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 encapsulation for MSDP?

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

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

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

24. Multicast Security • 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 encapsulation for MSDP. • So would per-source PIM and MSDP limits. • Need more features from vendors to protect multicast-enabled routers & switches. • See also: http://aharp.ittns.northwestern.edu/papers/mcast-template.html (10/2005)

25. Lab 7Preventing DoS from Scanning Hosts Time: Approx. 45 minutes

26. The Future of Multicast

27. SSM Revisited

28. Rationale for SSM • Why go to all the trouble involved in using RPs (tree-switching, MSDP) when the RPT is dropped for the SPT as soon as the first packet flows down the RPT? • The RP is not really forwarding data, just doing source discovery. • Isn’t there an easier way ? • This is the rationale for Source-Specific Multicast (SSM).

29. RP RP RP RP RP r s SSM Makes MSDP Unnecessary Domain E ASM MSDP Peers (irrelevant to SSM) Domain C Receiver learns S AND G out of band; e.g., from a Web page Domain B Domain D Source in 232/8 Domain A

30. RP RP RP RP RP r s SSM Makes MSDP Unnecessary Domain E ASM MSDP Peers (irrelevant to SSM) Domain C Receiver learns S AND G out of band; e.g., from a Web page Domain B Domain D Source in 232/8 Domain A

31. Summary: Advantages of SSM • No RPTs • No register packets • No RP mapping required (no RP required!) • No RP-to-RP source discovery (no MSDP required!) • No RP means no concentration of traffic towards the RP, and no single point to attack • Rogue sources cannot easily spoof traffic • SSM can use entire multicast address space, but 232/8 is reserved for SSM exclusively

32. Bi-Directional Multicast

33. Bi-Directional Multicast • SSM is a subset of PIM to deal with one-to-many broadcasts. • What’s left are few-to-many and many-to-many group communications. • Can PIM be optimized for the many-to-many case? • In many-to-many, every source is also a receiver. • So in standard PIM, trees must be built to the source as well as from the source.

34. Bi-Directional PIM • Standards Track RFC 5015 • Already in commercial use • Example: Cisco Multicast Hoot 'n' Holler • http://www.cisco.com/en/US/netsol/ns340/ns394/ ns165/ns70/networking_solutions_white_paper 09186a00800a8479.shtml • Hoot 'n' Holler connects a large number of push-to-talk terminals, all of which can hear a transmission from any particular source

35. What is Bi-Directional PIM? • In Bi-Dir, communication is always two-way. However, PIM trees are always uni-directional. • Bi-Dir could be achieved several ways: • Modify PIM to allow bi-directional trees • Set up trees to and from every source • However, the actual path taken was to drop SPT. • All traffic must go through an RP • No Register Messages • No (S,G) traffic • (*,G) traffic only

36. The Designated Forwarder (DF) • Bi-Dir PIM does not use either encapsulation of data to the RP or SPT. • There is a specific RP Address (RPA) for any given Bi-Dir group. • RPF always points toward the RPA. • For each link (hop) for a Bi-Dir group, there is a Designated Forwarder (DF). • DFs are elected if need be based on the routing metric toward the RPA. • The DF forwards any multicast data toward the RPA. • The DF also acts as a PIM DR as needed.

37. PIM Bi-Dir Operation • PIM Bi-Dir uses normal PIM-SM mechanisms to pass traffic down the tree, like a PIM-SM group before SPT switch-over. • PIM Bi-Dir uses the DF to pass traffic up the tree toward the RPA. • This is a new routing feature. • DF election rules prevent forwarding loops.

38. PIM Bi-Dir Pros and Cons • Pros • PIM Bi-Dir solves the bursty source problem. • No traffic-based signaling. • No (S,G) state. • Reduces the router load and eases debugging. • Cons • SPT and RPT cannot be mixed. • If PIM Bi-Dir is deployed in a PIM domain, it must be deployed in every router. • Otherwise forwarding loops will result. • The RP is once again a single point of failure. • Its placement and its ability to handle load become important.

39. IPv6 and Multicast

40. IPv6 and Multicast • In some ways IPv6 changes little for multicast, except for the increased address length. • PIM is hardly changed. • IGMP is replaced by Multicast Listener Discovery (MLD) Protocol. • With • IGMPv2 ---> MLDv1 (RFC 2710) and • IGMPv3 ---> MLDv2 (RFC 3810)

41. MTU and Multicast in IPv6 • One thing that has changed is the MTU and the treatment of fragmentation. • MTU = Maximum Transmissible Unit • In IPv6, fragmentation must be performed at the edges. • Packets that are too large for an intermediate hop are dropped. • In unicast, hosts are supposed to performPath MTU (PMTU) discovery.

42. IPv6 MTU • What to do in multicast? • Multicast MTU discovery has been implemented, but it does not scale well. • The source could receive many ICMPv6 “Packet Too Big” messages. • A source with many listeners could “Auto-DoS” itself by sending out too big a packet! • What to do? • Set the Multicast MTU to 1280 (the IPv6 minimum MTU).

43. Inter-domain Multicast in IPv6 • SSM hardly changes for IPv6, except for the changes mandated by the IPv6 address length and header. • ASM is another story: • MSDP will not be supported in IPv6. • So will inter-domain ASM die? • Embedded RP to the rescue.

44. Embedded RP in IPv6 • RFC 3956 • The idea is simple: • In standard IPv6 an address is 128 bits, of which only 64 bits are used for routing. • But a group address gets to use all of the 128 bits except for the multicast prefix (8 bits). • So, there is plenty of room to store a 64-bit unicast address.

45. Embedded RP addresses | 8 | 4 | 4 | 8 | 8 | 64 | 32 | +--------+----+----+--------+----+----------------+----------+ |11111111|flgs|scop|reserved|plen| network prefix | group ID | +--------+----+----+--------+----+----------------+----------+ • The first 8 bits are the prefix. • The flags MUST be 0111 for embedded RP. • Then the last 4 bits of the “reserved” field are used to encode the RP Interface ID (RIID), and there are 32 bits for group addresses (4 billion per RP).

46. Creating the RP addresses | 8 | 4 | 4 | 8 | 8 | 64 | 32 | +--------+----+----+--------+----+----------------+----------+ |11111111|flgs|scop|reserved|plen| network prefix | group ID | +--------+----+----+--------+----+----------------+----------+ • A little complicated: • The first “plen” bits of the network prefix form the first “plen” bits of the address. • The RIID forms the last 4 bits of the address. • The middle bits are all “0”.

47. Embedded RP in Use • Embedded RP means that anyone in another PIM domain who wants to join your group, knows where your RP is. • RP is a single point of failure. • Interdomain joins are now straightforward, and MSDP is not needed. • This was implemented in GÉANT from scratch in a few days!

48. Next Steps

49. "Why don’t we use multicastmore often?" • Extensive discussion of this question on wg-multicast@internet2.edu:https://mail.internet2.edu/wws/arc/wg-multicast/2004-05/thrd2.html • See also the follow-up discussion,subject line "I rest my case"

50. "Why don’t we use multicastmore often?" • One reason seems to be that there is insufficient demand for the high-bandwidth applications that really need multicast in order to scale. • In turn, this demand won't emerge until last-mile broadband is more widespread. • Last-mile broadband won't reach a large number of homes for a while yet, but it's a reality on campuses right now. • This could make campuses the place where large-scale multicast applications (say, hundreds of thousands of users) first take root.