Secure IP Multicast Deployments

Introduction

This document describes general guidance on best practices to secure an IP multicast network infrastructure.

Prerequisites

Requirements

Cisco recommends that you have knowledge of these topics:

• IP multicast

Components Used

This document is not restricted to specific software and hardware versions.

The information in this document was created from the devices in a specific lab environment. All of the devices used in this document started with a cleared (default) configuration. If your network is live, ensure that you understand the potential impact of any command.

Background Information

This document covers some basic concepts, terminology, and discusses the listed topics:

• Mechanisms to secure a specific platform and the network in general.
• Any Source Multicast (ASM) and Source Specific Multicast (SSM) models.
• Multicast Virtual Private Network (MVPN) security. 
• Group Encrypted Transport (GET) Virtual Private Network (VPN) architecture which provides confidentiality and integrity for multicast data plane or control plane traffic.

Terminology

In IP multicast there are two classic service models:

1. Any Source Multicast (ASM)

2. Source Specific Multicast (SSM)

In ASM, the receiver joins a group G via an Internet Group Membership Protocol (IGMP) or Multicast Listener Discovery (MLD) membership report to indicate the group. This report requests traffic sent by any source to the group G, and hence the name “any source.” By contrast, in SSM, the receiver joins a specific channel defined by a source S, which sends to a group G. Each of these service models is described in detail below.

Any Source Multicast

The ASM model is characterised by two classes of protocol: “dense mode flood-and-prune” and “sparse mode explicit join”:

i) Dense Mode Flood-and-Prune Protocols (DVMRP / MOSPF / PIM-DM)

In dense mode protocols, all routers in the network are aware of all trees, their sources and receivers. Protocols such as Distance Vector Multicast Routing Protocol (DVMRP) and Protocol Independent Multicast (PIM) dense mode flood “active source” information across the whole network and build trees via the creation of “Prune State” in parts of the topology where traffic for a specific tree is unwanted. They are also called flood-and-prune protocols. In Multicast Open Shortest Path First (MOSPF), information about receivers is flooded throughout the network to support the build out of trees.

Dense mode protocols are undesirable because every tree built in some part of the network can always cause resource utilization (with convergence impact) on all routers in the network (or within the administrative scope, if configured). These protocols are not discussed further in the remainder of this article.

ii) Sparse Mode Explicit Join Protocols (PIM-SM/PIM-BiDir)

With sparse mode explicit join protocols, devices do not create a group-specific state in the network unless a receiver has sent an explicit IGMP/MLD membership report (or “join”) for a group. This variant of ASM is known to scale well and is the multicast paradigm of focus.

This is the basis for PIM-Sparse Mode, which most multicast deployments have used to this point. This is also the basis for Bidirectional PIM (PIM-BiDir),  which is increasingly deployed for MANY (sources) to MANY (receivers) applications.

These protocols are called sparse mode because they efficiently support IP multicast delivery trees with a “sparse” receiver population and create a control plane state only on routers in the path between sources and receivers, and in PIM-SM/BiDir, the Rendezvous Point (RP). They never create state in other parts of the network. State in a router is only built explicitly when it receives a join from a downstream router or receiver, hence the name “explicit join protocols”.

Both PIM-SM and PIM-BiDir employ “SHARED TREES”, which allow traffic from any source to be forwarded to a receiver. The multicast state on a shared tree is referred to as (*,G) state, where the * is a wild card for ANY SOURCE. Additionally, PIM-SM supports the creation of state that relates to traffic from a specific source. These are known as SOURCE TREES, and the associated state is referred to as (S,G) state.

Source-Specific Multicast

SSM is the model used when the receiver (or some proxy) sends (S,G) “joins” to indicate that it wants to receive traffic sent by source S to group G. This is possible with IGMPv3/MLDv2 “INCLUDE” mode membership reports. This model referred to as the Source-Specific Multicast (SSM) model. SSM mandates the use of an explicit-join protocol between routers. The standard protocol for this is PIM-SSM, which is simply the subset of PIM-SM used to create (S,G) trees. There are no shared trees (*,G) state in SSM.

Multicast receivers can thus “join” an ASM group G, or “join” (or more accurately “subscribe” to) an SSM (S,G) channel. To avoid repetition of the term “ASM group or SSM channel”,  the term (multicast) flow is used, which implies that the flow could be an ASM group or an SSM channel.

Relevant Multicast Protocols / Packet Types

To secure a multicast network it is important to understand the packet types commonly encountered and how to protect against them. There are three main protocols with which to be concerned:

1. IGMP / MLD

2. PIM

3. MSDP

In the next section, each of these protocols are discussed and the issues that can arise with each, respectively.

IGMP / MLD Packets

IGMP / MLD is the protocol used by multicast receivers to signal to a router that they want to receive content for a particular multicast group. Internet Group Membership Protocol (IGMP) is the protocol used in IPv4, and Multicast Listener Discovery (MLD) is the protocol used in IPv6.

There are two versions of IGMP that are commonly deployed, IGMPv2 and IGMPv3. There are also two versions of MLD that are commonly deployed, MLDv1 and MLDv2.

IGMPv2 and MLDv1 are functionally equivalent, and IGMPv3 and MLDv2 are functionally equivalent.

These protocols are specified in these links:

IGMPv2: RFC 2236

MLDv1: RFC 3590

IGMPv3 and MLDv2: RFC 4604

IGMPv2 and IGMPv3 is not only a protocol but also an IPv4 IP protocol (specifically, protocol number 2). It is not only used as described in these RFCs to report multicast group membership, but also by other IPv4 multicast protocols such as DVMRP, PIM version 1, mtrace and mrinfo. This is important to remember when you attempt to filter IGMP (via Cisco IOS® ACLs, for example). In IPv6, MLD is not an IPv6 protocol; instead ICMPv6 is used to carry MLD packets. PIM version 2 is the same protocol type in IPv4 and IPv6 (protocol number 103).

PIM Control Packets

In this section, multicast and unicast PIM control packets are discussed. Auto-RP as well as Bootstrap Router (BSR), which are ways to elect Rendezvous Points and control Group-to-RP assignments in PIM-SM networks, are discussed.

Multicast PIM Control Packets

Multicast PIM Control Packets include:

• PIM Hello - The PIM Hello packet is a link-local scope IP multicast packet sent to a router attached to the same network to establish PIM neighbors.
• PIM Join/Prune - PIM Join/Prunes are link-local scope IP multicast packets sent to create / remove multicast state and are only sent to PIM neighbors. They are multicast within the LAN to facilitate assert, report suppression, and other PIM protocol details, but they are always directed to a specific neighbor.
• PIM DF-elect - PIM Designated Forwarder is the Bi-Dir PIM router responsible for (*,G) JOINS sent to the RP on behalf of attached receivers or downstream PIM neighbours. For cases where a PIM router detects another router that sends (*,G) JOINS on the same segment for the same group G, there is an election to determine the router with the best path to the RP.
• PIM Assert - PIM Asserts are link-local IP multicast packets sent when a PIM router attached to a network segment that actively forwards packets for a particular (S,G) out of a particular interface begins RECEIVING packets for that same (S,G) on the same interface on which are forwarded. This event indicates the presence of another router that thinks it is the Single Forwarder (SF) for this (S,G). The Assert mechanism elects a unique SF for that (S,G). The PIM SF router is elected to forward packets for a particular (S,G) stream. PIM allows for different routers to perform the role of the SF on behalf of different (S,G)s, ideally there is only one SF per (S,G). Do not confuse the SF with the Designated Router. The PIM Designated Router is the router responsible for JOIN / PRUNES or SOURCE REGISTERS that are sent to the RP in a PIM-SM network.
• PIM Bootstrap - PIM Bootstrap messages are sent in a PIMv2 network to facilitate the dynamic election of a Rendezvous Point for a particular group G.

Unicast PIM Control Packets

Unicast PIM Control Packets are directed to or from the RP and include:

• Source Register Packet - PIM Source Register Packets are sent to register a new multicast source with a Rendezvous Point. As soon as a Source starts to send multicast packets, the Designated Router that is attached to the source network sends a unicast register stream to the RP to indicate that there is an active source present for a multicast group for which the RP is responsible.
  Source Register packets are sent as a unicast encapsulation of the original multicast stream.
  PIM register messages are process-level switched and are sent only until the RP sends a register stop message. The performance impact of these packets is proportional to the rate of the source (per (S,G) flow).
• Register Stop Packet - PIM Register Stop Packets are sent from the Rendezvous Point to the PIM DR that sent the Register message. Register Stop messages are sent as soon as the RP starts to receive multicast packets natively from the source.
• BSR Candidate-Rendezvous Point Advertisement Packet - PIM BSR C-RP-Advertisement Packets are sent to the BSR to advertise a candidate RP once the BSR is elected.

Fig 1: PIM Unicast Packets 

Fig1_PIM_unicast

Attacks that exploit such packets can originate from anywhere, as these packets are unicast.

Basic Threats Against a Router

There are a number of fundamental threats against a router that are independent of whether the router supports multicast and whether the attack involves multicast traffic or protocols.

Denial of service (DoS) attacks are the most important generic attack vectors in a network. In principle, every network element can be targeted with a DoS attack, which can overload the element with potential subsequent loss or degradation of service for legitimate users. It is of paramount importance to follow the basic network security recommendations that apply to unicast.

It is noteworthy that multicast attacks are not always intentional, but often accidental. For instance, the Witty worm, first observed in March 2004, is one example of a worm that spread through random attacks on IP addresses. As a consequence of complete randomization of the address space, multicast IP destinations were also affected by the worm. In many organizations, a number of first-hop routers collapsed because the worm sent packets to many different multicast destination addresses. The routers, however, were not scoped for such a multicast traffic load with the associated state creation, and effectively experienced resource exhaustion. This illustrates the need to secure multicast traffic, even if multicast is not used in an enterprise.

Generic threats against routers include:

• Packet floods of any type; for example, against hardware paths such as slow (punt) paths, and software paths such as management or control plane ports, which includes Secure Shell (SSH), Telnet, Border Gateway Protocol (BGP), OSPF, Network Time Protocol (NTP), and so on
• Intrusions into the router, with subsequent exploitation of features on the router; weak Telnet or SSH passwords and weak Simple Network Management Protocol (SNMP) community strings are a common problem in modern networks.
• Operational issues such as misconfigurations or insider attacks can endanger the security of the entire network and its traffic.
  
  

When multicast is enabled on a router, it must be secured in addition to unicast. Usage of IP multicast does not change the fundamental threat model; however, it enables additional protocols (PIM, IGMP, MLD, MSDP) that could be subject to attacks, which need to be secured specifically. When unicast traffic is used in these protocols, the threat model is identical to other protocols run by the router.

It is important to note that multicast traffic cannot be used in the same way as unicast traffic to attack a router because multicast traffic is fundamentally “receiver driven” and cannot be targeted at a remote destination. An attack target needs to be explicitly “joined” to the multicast stream. In most cases (Auto-RP is the main exception), routers only listen to and receive “link local” multicast traffic. Link local traffic is never forwarded. Therefore, attacks on a router with multicast packets can only originate from directly attached attackers.

Threats From the Source Side

Multicast sources, whether PCs or video servers are sometimes not under the same administrative control as the network. Therefore, the sender is mostly treated as untrusted, from the network operator’s point of view. Given the powerful capabilities of PCs and servers, and their complex security settings, which are often incomplete, the senders pose a substantial threat against any network, which includes multicast. These threats include:

• Layer 2 attacks: There are a wide range of attack forms on layer 2 to carry out various types of attacks. These apply to unicast as well as multicast. Since these attack forms are not specific to multicast, they are not discussed in more detail in this document. For more information, see the Cisco Press book “LAN Switch Security”, ISBN-10: 1-58705-467-1.
• Attacks with multicast traffic: As described previously, it is difficult to conduct attacks with multicast traffic since the first-hop router does not forward  multicast traffic unless there is a listener for the group. However, the first hop can be attacked in various ways with multicast packets:
• Network saturation attacks: An attacker can flood a segment with multicast packets, over utilization of the available bandwidth, which can lead to a DoS condition.
• Multicast state attacks: The first-hop router is flooded with multicast packets, which can create too much state, and a consequent DoS attack condition.
• A sender could attempt to become the PIM DR, through PIM hellos that are sent. In such cases no traffic would forward to or from the LAN.
• PIM DF election packets for a BiDir-PIM DF could be spoofed. In such cases no traffic would forward to or from the LAN.
• A sender could spoof AutoRP RP-discovery or BSR bootstrap messages. This would effectively announce a fake RP, and bring down or disrupt a PIM-SM/BiDir service.
• A sender could source unicast attacks, such as PIM source register/register-stop messages, or could send BSR announce packets and announce a fake BSR.
• A sender can send to any valid multicast group, unless this is filtered. If a source address is spoofed and not prevented at the edge, the sender can use the source IP address of a legitimate sender, and override content in parts of the network.
• Multicast attacks against control plane protocols: A number of protocols not associated with multicast, such as OSPF and Dynamic Host Configuration Protocol (DHCP), use multicast packets, which can be used to attack these protocols
• Masquerading: There are a number of attack forms where a sender can pretend to be another sender. Spoofed source IP addresses are one such attack form.
• Theft of service: Unless senders are controlled, it is possible to use the multicast service illegitimately from the sender side.

Note: Hosts normally do not send or receive PIM packets. Host that do this can likely attempt an attack.

Threats From the Receiver Side

The receiver is also typically a platform with significant CPU power and bandwidth, and allows for a number of attack forms. These are mostly identical to the threats on the sender side. Layer 2 attacks remain an important attack vector. Fake receivers and theft of service are also possible on the receiver side, except that the attack vector is typically IGMP (or layer-2 attacks, as mentioned).

Threats Against a Rendezvous Point and BSR

PIM-SM RPs and PIM-BSRs are critical points in a multicast network, and are therefore valuable targets for an attacker. When neither is the first-hop router, only unicast attack forms, which includes PIM unicast, can be targeted directly against those elements. The threats against RPs and BSRs include:

• All generic attack forms, as described in the section “Basic Threats Against a Router”.
• PIM unicast attacks, potentially with spoofed source IP addresses, allow for DoS attacks, though PIM register or register-stop messages that are sent by a malicious device.

Multicast and Unicast Security (compared)

State Considerations / Filters

Consider the topology in Figure 3, which shows a source, three receivers (A, B, C), a switch (S1), and two routers (R1 and R2). The blue line represents a unicast stream and the red line represents a multicast stream. All three receivers are members of the multicast flow.

Fig 3: Replication in Routers and Switches

Fig3_replication_RS

To inhibit traffic flow from a specific source to a specific receiver:

• For the unicast stream, install a filter anywhere on the path from sender to receiver.
• For the multicast stream, however, administrators need to be more specific about where to install filters: at the receiver side filter after the last replication point before the receiver; at the source side filter before the first replication point after the source.

Attacks From Multicast Sources

This section applies to both the ASM and SSM service models, where traffic is forwarded based on the receipt of receiver-side explicit joins.

For unicast streams there is no implicit receiver protection. A unicast source can send traffic to a destination, even if this destination has not asked for the traffic. Therefore, defense mechanisms such as firewalls are typically used to protect end points. Multicast, on the other hand, has some implicit protection built into the protocols. Traffic ideally only reaches a receiver that has joined the flow in question.

With ASM, sources can launch traffic insertion or DoS attacks through multicast traffic transmission to any of the groups supported by an active RP. This traffic ideally does not reach a receiver, but can reach the first-hop router in the path at minimum, as well as the RP, which allows for limited attacks. If a malicious source, however, knows a group to which a target receiver is interested in, and if there are no appropriate filters in place, it can send traffic to that group. This traffic is  received as long as receivers listen to the group.

With SSM, attacks by unwanted sources are only possible on the first-hop router where the traffic stops if no receiver has joined that (S,G) channel. This does not lead to any state attack on the first-hop router because it discards all SSM traffic for which no explicit join state exists from receivers. In this model it is not sufficient for a malicious source to know which group a target is interested in to because “joins” are source-specific. Here, IP source addresses that are spoofed plus potential routing attacks would be required to succeed.

State Attacks

Even without receivers present in a network, PIM-SM creates (S,G) and (*,G) state on the first-hop router closest to the source and also on the Rendezvous Point. Thus there exists the possibility of a state attack on the network at the source first-hop router and on the PIM-SM RP.

If a malicious source starts to send traffic to multiple groups, then for each of the groups that are detected, the routers in the network create state at the source and the RP, provided the groups in question are permitted by the RP configuration.

Therefore, PIM-SM is subject to state and traffic attacks by sources. The attack can be aggravated if the source is changes its source IP address randomly within the correct prefix, or in other words, only the host bits of the address are spoofed.

Fig 4: ASM RP attacks

Fig4_ASM_RP_Attacks

As with PIM-SSM, PIM-BiDir state-creation attacks from sources are impossible. Traffic in PIM-BiDir is forwarded on state created by joins from receivers as well as on state forwarded traffic to the RP, such that it can reach receivers behind the RP, since the joins only go to the RP. State-to-forward traffic to the RP is called (*,G/M) state and is created by RP configuration (static, Auto-RP, BSR). It does not change in the presence of sources. Therefore, attackers can send multicast traffic to a PIM-BiDir RP, but unlike PIM-SM, a PIM-BiDir RP is not an “active” entity, and instead just forwards or discards traffic for PIM-BiDir groups.

Note: On some Cisco IOS platforms (*,G/M) state is not be supported. In such cases sources can attack the router by multicast traffic transmission to multiple PIM-BiDir groups, which causes (*,G) state creation. For example the Catalyst 6500 switch does support (*,G/M) states).

Receiver-Initiated Attacks

Attacks can originate from multicast receivers. Any receiver that sends an IGMP/MLD reports typically create state on the first-hop router. There is no equivalent mechanism in unicast.

Fig 5: Receiver-Side Explicit Join-Based Traffic Forwarding

Fig5_Receiver_Explicit_Join

Receiver attacks can be of three types:

1. A multicast receiver can attempt to join a flow for which they are not authorized and attempt to receive content they are unauthorized to receive.
2. A multicast receiver can potentially overload available network bandwidth through interest in many groups or channels. This sort of attack becomes a shared bandwidth attack against other potential receivers of content.
3. A multicast receiver can attempt to launch an attack against routers or switches. A large number of IGMP reports can be generated, which can create a large amount of multicast tree state and potentially overload router capacity. This in turn can result in an increase in multicast convergence times, or in a DoS on the router.
   
   

Various ways to mitigate these sorts of attacks in the next section, Security within a Multicast Network.

Security within a Multicast Network

Network Element Security

Security is not a point feature, but an intrinsic part of every network design. As such, security must be considered at every point in the network. It is of paramount importance that each and every network element is appropriately secured. One possible attack scenario, applicable to any technology, is a router subverted by an intruder. Once an intruder has control of a router, the attacker can run a number of different attack scenarios. Each network element must therefore be appropriately secured against any form of basic attack, as well as against specific multicast attacks.

Local Packet Transport Service (LPTS)

On Cisco IOS XR, Local Packet Transport Service (LPTS) serves as a policer of traffic to the control plane of the router, similar to CoPP on Cisco IOS. Additionally, receive traffic, which includes unicast and multicast traffic, can be filtered and rate limited.

Multicast-Specific Security

In a multicast-enabled network, each network element needs to be secured with multicast-specific security features. These are outlined in this section, for generic router protection. Features that are not required on every router, but only in specific locations in the network, and features that require interaction between routers (such as PIM authentication) are discussed in the next section.

ip multicast route-limit <mroute-limit> <warning-threshold>

Fig 6: Mroute Limits

Fig6_Mroute_Limits

Mroute limits allow the setting of a threshold on the number of mroutes that are permitted into the multicast routing table. If a multicast route limit is enabled then no multicast state is created beyond the configured limit. There is also a warning threshold. When the number of mroutes exceeds the warning threshold, syslog warning messages are triggered. At the mroute limit any further packets that would trigger state are discarded.

The ip multicast route-limit command is also available per MVRF.

ip multicast mrinfo-filter 51
		
access-list 51 deny 192.168.1.1
access-list 51 permit any

ip multicast mrinfo-filter 52

access-list 52 deny any

ip multicast group-range <std-acl>  
ipv6 multicast group-range <std-acl>  

ip pim register-rate-limit <count> 		   

ip pim rp-announce-filter

ip multicast boundary <std-acl>

access-list 1 deny 224.0.1.39
access-list 1 deny 224.0.1.40

224.0.1.39 (RP-announce)
224.0.1.40 (RP-discover)

Fig10_Mcast_Boundary

Fig13_Interdomain_Filter

To secure the control plane, harden MSDP via three basic security measures:

1) MSDP SA Filters

It is a “best common practice” to filter the content of MSDP messages via MSDP SA filters. The main idea of this filter is to avoid propagation of multicast state for applications and groups that are not Internet-wide applications and do not need to be forwarded beyond the source domain. Ideally, from a security point of view, the filters only allow known groups (and potentially senders), and deny any unknown senders and/or groups.

It is usually not possible to explicitly list all allowed senders and/or groups. it is recommended to use the default configuration filter for PIM-SM domains with a single RP for every group (no MSDP mesh-group):

!--- Filter MSDP SA-messages. 
         !--- Replicate the following two rules for every external MSDP peer. 
         !
         ip msdp sa-filter in <peer_address> list 111
         ip msdp sa-filter out <peer_address> list 111
         !
         !--- The redistribution rule is independent of peers.
         !
         ip msdp redistribute list 111
         !
         !--- ACL to control SA-messages originated, forwarded. 
         !
         !--- Domain-local applications.
         access-list 111 deny   ip any host 224.0.2.2     ! 
         access-list 111 deny   ip any host 224.0.1.3     ! Rwhod
         access-list 111 deny   ip any host 224.0.1.24    ! Microsoft-ds 
         access-list 111 deny   ip any host 224.0.1.22    ! SVRLOC
         access-list 111 deny   ip any host 224.0.1.2     ! SGI-Dogfight
         access-list 111 deny   ip any host 224.0.1.35    ! SVRLOC-DA
         access-list 111 deny   ip any host 224.0.1.60    ! hp-device-disc
         !--- Auto-RP groups.
         access-list 111 deny   ip any host 224.0.1.39 
         access-list 111 deny   ip any host 224.0.1.40
         !--- Scoped groups.
         access-list 111 deny   ip any 239.0.0.0 0.255.255.255
         !--- Loopback, private addresses (RFC 6761).
         access-list 111 deny   ip 10.0.0.0 0.255.255.255 any
         access-list 111 deny   ip 127.0.0.0 0.255.255.255 any
         access-list 111 deny   ip 172.16.0.0 0.15.255.255 any
         access-list 111 deny   ip 192.168.0.0 0.0.255.255 any
         !--- Default SSM-range. Do not do MSDP in this range.
         access-list 111 deny   ip any 232.0.0.0 0.255.255.255
         access-list 111 permit ip any any
         !

It is recommended to filter as strictly as possible, and in both directions, inbound and outbound.

Please use  for more details on MSDP SA filter recommendations: https://www.cisco.com/c/en/us/support/docs/ip/ip-multicast/13717-49.html

ip msdp sa-limit <peer> <limit> 

Fig14_MSDP_ControlPlane

With the ip msdp sa-limit command you can limit the number of SA states created due to SA messages accepted from an MSDP peer. Some simple rule-of-thumb recommendations include:

• Small limit from stub-neighbor 
• Large limit from transit neighbor (for example maximum #SAs in Internet)
• Transit ISP - configure maximum #SAs your platform can support

3) MSDP MD5 Neighbor Authentication

It is recommended to use of Message-Digest Algorithm (MD5) password authentication on MSDP peers. This uses the TCP MD5 signature option, equivalent to the use described in RFC 6691 to secure BGP.

Fig 15: MSDP MD5 Neighbor Authentication

Fig15_MSDP_MD5Auth

These three MSDP security recommendations pursue different goals:

• Neighbor authentication (with MD5) ensures that only trusted MSDP peers can send messages.
• The SA filters ensure that even a trusted MSDP peer can only send SA announcements that are in line with pre-agreed source/group policy.
• The SA limit further ensures that even with legitimate (S,G) announcements from legitimate peers, the available memory cannot be exhausted.

Sender / Source issues

Many multicast security issues that originate at the sender can be mitigated with appropriate unicast security mechanisms. A number of unicast security mechanisms are recommended best practices here:

• Source address spoof protection ( Unicast Reverse Path Forwarding, uRPF or ACL and IP source guard for the access layer)
• Infrastructure ACLs (deny ip any (to) <core address space>)

Such measures can be used to block directed attacks on the core. This would, for example, also solve issues like attacks that use PIM unicast packets to the RP, which is "inside" the network and would therefore be protected by the infrastructure ACL.

Packet Filter-Based Access Control – Control Sources

In the example shown in Figure 16, the filter is configured on the LAN interface (E0) of the first-hop multicast router (Designated Router). The filter is defined by an Extended Access Control List called “source”. This ACL is applied to the source-facing interface of the Designated Router connected to the source LAN. In fact, because of the nature of multicast traffic, there could need to be a similar filter configured on all LAN-facing interfaces on which sources could become active. Since it is not possible in all cases to know exactly where source activity occurs, it is recommended to apply such filters on all ingress points into the network.

Fig 16: Control Sources

Fig16_Controlling_Sources

ip pim accept-register / ipv6 pim accept-register

Fig17_PIMSM_Control

In a PIM-SM network, an unwanted traffic source can be controlled with this command. When the source traffic hits the first-hop router, the first-hop router (DR) creates (S,G) state and sends a PIM Source Register message to the RP. If the source is not listed in the accept-register filter list (configured on the RP), then the RP rejects the Register and sends back an immediate Register-Stop message to the DR.

In the example shown, a simple ACL has been applied to the RP, which filters only on the source address. It is also possible to filter the source AND the group with the use of an extended ACL on the RP.

There are drawbacks with source filters because with the pim accept-register command on the RP, PIM-SM (S,G) state is still created on the source’s first-hop router. This can result in traffic at receivers local to the source and located between the source and the RP. Furthermore, the pim accept-register command works on the control plane of the RP. This could be used to overload the RP with fake register messages, and possibly cause a DoS condition.

It is recommended to apply the pim accept-register command on the RP in addition to other methods, such as application of simple data plane ACLs on all DRs, on all ingress points into the network. While ingress ACLs on the DR would be sufficient in a perfectly configured and operated network, it is recommended to configure the pim accept-register command on the RP as a secondary security mechanism in case of misconfigurations on the edge routers. Layered security mechanisms with the same goal is called “defense in depth”, and is a common design principle in security.

Receiver Issues – Control IGMP/MLD

Most receiver issues fall in the domain of IGMP/MLD receiver protocol interactions.

Fig 18: Control IGMP

Fig18_Controlling_IGMP

When IGMP or MLD packets are filtered, remember these points:

• IPv4: IGMP is an IPv4 protocol type (IPv4 procotol 2)
• IPv6: MLD is carried in ICMPv6 protocol type packets

The IGMP process is enabled by default as soon as IP Multicast is enabled. IGMP packets also carry these protocols, and therefore all of these protocols are enabled whenever multicast is enabled:

• PIMv1 – PIMv1 was the first version of PIM and is always enabled in Cisco IOS for migration purposes. Current deployments all use PIMv2.
• Mrinfo - Mrinfo is a Unix command that Cisco IOS inherited to display multicast neighbors. Cisco recommends the use of SNMP instead of the mrinfo command.
• DVMRP - DVMRP is a legacy dense mode distance vector protocol with very limited scaling characteristics. Cisco IOS support for DVMRP is retired or already deprecated.
• Mtrace - Mtrace is the multicast equivalent of unicast “traceroute” and is a useful tool

For more information, See IANA's Internet Group Management Protocol (IGMP) Type Numbers

Router> mtrace 172.16.0.0 172.16.0.10 239.254.254.254
		
Type escape sequence to abort.
Mtrace from 172.16.0.0 to 172.16.0.10 via group 239.254.254.254
From source (?) to destination (?)
Querying full reverse path... 
 0  172.16.0.10
-1  172.16.0.8 PIM  thresh^ 0  0 ms 
-2  172.16.0.6 PIM  thresh^ 0  2 ms 
-3  172.16.0.5 PIM  thresh^ 0  894 ms 
-4  172.16.0.3 PIM  thresh^ 0  893 ms 
-5  172.16.0.2 PIM  thresh^ 0  894 ms 
-6  172.16.0.1 PIM  thresh^ 0  893 ms 

Unicast IGMP packets (for IGMP/UDLR) can be filtered, as these are most likely attack packets and not valid IGMP protocol packets. Unicast IGMP packets are supported by Cisco IOS in support of unidirectional links and other exception conditions.

Forged IGMP/MLD query packets can result in a lower IGMP version than expected.

In particular, hosts ideally never send IGMP queries because a query sent with a lower IGMP version can cause all hosts that receive this query to revert to the lower version. In the presence of IGMPv3 / SSM hosts, this can “attack” the SSM streams. In the case of IGMPv2, this can result in longer leave latencies.

If a non-redundant LAN with a single IGMP querier is present, the router needs to drop IGMP queries received.

If a redundant / common passive LAN exists, then a switch capable of IGMP snooping is required. There are 2 specific features that can help in this case:

• Router Guard
• IGMP Minimum Version command

Router Guard

Any switch port can become a multicast router port if the switch receives a multicast router control packet (IGMP general query, PIM Hello, or CGMP Hello) on that port. When a switch port becomes a multicast router port, all multicast traffic is sent to that port. This can be prevented with “Router Guard”. The Router Guard feature does not require IGMP snooping to be enabled.

The Router Guard feature allows a specified port to be designated a multicast host port. The port cannot become a router port, even if multicast router control packets are received.

These packet types are discarded if they are received on a port that has Router Guard enabled:

• IGMP query messages
• IPv4 PIMv2 messages
• IGMP PIM messages (PIMv1)
• IGMP DVMRP messages
• Router-port Group Management Protocol (RGMP) messages
• Cisco Group Management Protocol (CGMP) messages

When these packets are discarded, statistics are updated which indicate that packets are dropped due to Router Guard.

IGMP Minimum Version

It is possible to configure the minimum version of IGMP hosts allowed. For example, you can disallow all IGMPv1 hosts or all IGMPv1 and IGMPv2 hosts. This filter applies only to membership reports.

If the hosts are attached to a common "passive" LAN (for example, a switch that does not support IGMP Snooping, or is not configured for it), there is also nothing a router can do about such false queries other than ignore the “old version” membership reports that are then triggered, and not fall back itself.

Since IGMP queries must be visible to all hosts, it is not possible to use a Hash-based message authentication (HMAC) mechanism with a pre-shared key, such as static key IPSec, to authenticate IGMP queries from “valid routers”. If two or more routers are attached to a common LAN segment, an IGMP querier election is required. In that case, the only filter that could be used is an ip access-group filter based on the source IP address of the other IGMP router that sends queries.

“Normal” multicast IGMP packets must be permitted.

This filter can be used on receiver ports to allow only “good” IGMP packets, and to filter known “bad” ones:

ip access-list extended igmp-control
   <snip>
   deny   igmp any any  pim        ! No PIMv1
   deny   igmp any any  dvmrp      ! No DVMRP packets
   deny   igmp any any  host-query ! Do not use this command with redundant routers. 
                                   ! In that case this packet type is required !								   
   permit igmp any host 224.0.0.22 ! IGMPv3 membership reports
   permit igmp any any  14         ! Mtrace responses
   permit igmp any any  15         ! Mtrace queries 
   permit igmp any 224.0.0.0 10.255.255.255 host-query  ! IGMPv1/v2/v3 queries
   permit igmp any 224.0.0.0 10.255.255.255 host-report ! IGMPv1/v2 reports
   permit igmp any 224.0.0.0 10.255.255.255 7           ! IGMPv2 leave messages
   deny   igmp any any             ! Implicitly deny unicast IGMP here!
   <snip>
   permit ip   any any             ! Permit other packets

interface ethernet 0
   ip access-group igmp-control in

Note: This type of IGMP filter can be used in receive ACLs or CoPP. In both applications, it needs to be combined with filters for other traffic handled, such as routing and management plane protocols. 

Fig 19: Host Receiver-Side Access Control

Fig19_Host_Receiver_Access

ip igmp access-group / ipv6 mld access-group

access-list 1 deny 226.1.0.0 0.0.255.255
access-list 1 permit any log
!
interface ethernet 1/3
 ip igmp access-group 1

ip access-list extended test5
 deny igmp host 10.4.4.4 host 232.2.30.30
 permit igmp any any
!
interface Ethernet0/3
 ip igmp access-group test5

ip igmp limit <n> [ except <ext-acl> ]
ipv6 mld limit <n> [ except <ext-acl> ]

ip access-list extended channel-guides
  permit ip any host 239.255.255.254 ! SDR announcements
  deny   ip any any
  
ip igmp limit 1 except channel-guides

interface ethernet 0
  ip igmp limit 2 except channel-guides

Fig20_PerInterface_IGMP

ip multicast limit [ rpf | out | connected ] <ext-acl> <max>

ip multicast limit cost <ext-acl> <multiplier>

ip multicast limit cost acl-MP2SD-channels   4000 ! from any provider
ip multicast limit cost acl-MP2HD-channels  18000 ! from any provider
ip multicast limit cost acl-MP4SD-channels   1600 ! from any provider
ip multicast limit cost acl-MP4HD-channels   6000 ! from any provider
!
interface Gig0/0
description --- Interface towards DSLAM ---
<snip> 
! CAC
ip multicast limit out 250000 acl-CP1-channels
ip multicast limit out 250000 acl-CP2-channels
ip multicast limit out 250000 acl-CP3-channels

permit ip 10.0.0.0   0.255.255.255   10.0.0.0   0.255.255.255

permit ip any 239.192.0.0 0.0.255.255

Use GET VPN to Authenticate Control Plane Traffic

It is generally a best practice to authenticate control plane traffic, such as routing protocols, to ensure that messages come from a trusted peer. This is comparatively simple for control plane protocols that use unicast, such as BGP. However, many control plane protocols use multicast traffic. Examples are OSPF, RIP, and PIM. See IANA's IPv4 Multicast Address Space Registry for the full list.

Some of these protocols have built-in authentication, like Routing Information Protocol (RIP) or Enhanced Interior Group Routing Protocol (EIGRP), others rely on IPSec to provide this authentication (for example OSPFv3, PIM). For the latter case, GET VPN provides a scalable way to secure these protocols. In most cases, the requirement is protocol message authentication, or in other words, verification that a message was sent by a trusted peer. However, GET VPN also allows encryption of such messages.

To secure (typically authenticate only) such control plane traffic, the traffic needs to be described with an ACL and included in the GET VPN policy. The details depend on the protocol to be secured, where attention needs to be paid to whether the ACL includes traffic that passes only an ingress GET VPN node (that is is encapsulated), or also an egress node.

There are two fundamental ways to secure PIM protocols:

• permit ip any 224.0.0.13 0.0.0.0: This is the “All PIM Routers” multicast group. However, this does not secure unicast PIM messages
• permit pim any any: This secures the PIM protocol, independent of whether multicast or unicast is used

Note: The commands are provided as examples to help explain a concept. For example, it is necessary to exclude certain PIM protocols used to bootstrap PIM, such as BSR or Auto-RP. Noth methods have certain advantages and inconveniences which are dependent on the deployment. Please refer to specific literature on how to secure PIM with GET VPN for details.

Conclusions

Multicast is increasingly common service in networks. The emergence of IPTV services in residential / home broadband networks, and the move towards electronic trading applications in many of the world’s financial markets are just two examples of requirements that make multicast an absolute requirement. Multicast comes with a variety of different configuration, operation and management challenges. One of the key challenges is security.

This document examined a variety of ways in which multicast can be secured:

• First, look at the overall multicast control and data planes, an explanation of how the differences from unicast present new security challenges.
• Next, an examination of the key protocols that are encountered in a multicastnetwork, in particular IGMP, PIM, and MSDP were examined in some detail. In each case, a description of security threats and recommended best practices for mitigation against these threats were provided.
• Additionally, some specific examples of how multicast can be secured in some specific applications, such as broadband edge networks where bandwidth can be limited in comparison to the amount of bandwidth that specific video flows could require.
• Finally, GET VPN architecture was described as a means of integrated multicast with IPSec for delivery of secure VPNs.

With multicast security in mind, remember how it is different to unicast. Multicast transmission is based upon the creation of dynamic state, multicast involves dynamic packet replication, and multicast builds unidirectional trees in response to PIM JOIN / PRUNE messages. Security of this whole environment involves the understanding and deployment of a rich framework of Cisco IOS commands. These commands are largely centered around protection of protocol operations, states (multicast), or policers placed against packets like CoPP. With correct use of these commands it is possible to provide a robust protected service for IP multicast.

In summary, there are multiple approaches that are promoted and described in this paper:

1. Widespread use of SSM – this is the most simple PIM mode that also allows the use of (S,G) forwarding. 
2. If ASM services are needed, ensure a robust service can be provided – use of statically defined RPs provides a more secure control plane than dynamic RP announcements. Auto-RP and BSR are more flexible
3. If PIM-SM is enabled, look at areas of particular vulnerability, like the register tunnel to the RP, and ensure that the DR is always well protected. CoPP is very helpful in these areas.
4. If inter-domain ASM services are needed, consider whether BiDir PIM can be deployed.
5. Use global mroute/igmp state limits – understand the capabilities of your platforms together with the expected maximum amount of state you need under normal circumstances and in the worst case scenario. Configure limits within your platform’s capabilities that allow your network to operate to its maximal limits.
6. Fundamental filters – rACL/CoPP and infrastructure ACLs, which blocks PIM at the access layer

IP Multicast is an exciting and scalable means to deliver a variety of application services. Like unicast, it needs to be secured in a variety of different areas. This paper provides the basic building blocks that can be used to secure an IP multicast network.

Related Information

• Guidelines for Enterprise IP Multicast Address Allocation
• ConfigureIPv4 IGMP Filters
• Group Encrypted Transport VPN