The Multicast Security Tool Kit

Contents

Background / Introduction
      Introduction and Scope
      Terminology
      Relevant Multicast Protocols / Packet Types
         IGMP / MLD Packets
         PIM Control Packets
         MSDP Packets
      Threats in a Multicast Environment
         Zones of Trust and Trust Boundaries
         Threat Overview
         Basic Threats Against a Router
         Threats from the Sender Side
         Threats from the Receiver Side
         Threats Against a Rendezvous Point and BSR
      Multicast and Unicast Security (compared)
         State Considerations / Filtering
Securing a Multicast Network
      Securing a Network Element
         Basic Security
         Multicast-Specific Security
      Securing the Network
         Disabling Multicast Groups
         Securing PIM
         RP / PIM-SM-related Filtering
         Inter-Domain Filters and MSDP
      Sender / Source Issues
         Packet Filter-Based Access Control – Controlling Sources
         PIM-SM Source Control
      Receiver issues – Controlling IGMP/MLD
      Admission Control
         Global and per interface IGMP limits
         Per-Interface mroute Limits
Multicast and IPSec
      Introduction to GET VPN
      Using GET VPN to Encrypt Multicast Data Plane Traffic
      Using GET VPN to Authenticate Control Plane Traffic
Conclusions
References
Future Work
Acknowledgements



Background / Introduction


Introduction and Scope

This document is intended to provide guidance on some of the best practices for securing an IP multicast network infrastructure. We begin by explaining some basic concepts and terminology used, and then discuss some specific IPmc threats. From there we describe mechanisms for securing a specific platform and the network in general. Both Any Source Multicast (ASM) and Source Specific Multicast (SSM) models are discussed. In addition, some comments on Multicast Virtual Private Network (MVPN) security are provided. We also include a brief discussion on the GET VPN architecture for providing confidentiality and integrity for multicast data plane or control plane traffic.

Future papers will focus on IOS XR and Cisco’s recently released Nexus OS (NX-OS) operating system for the Nexus 7000, as well as provide a more detailed discussion of the issues connected with multicast security in a VPN context.

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 IGMP or MLD membership report indicating only 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 sending 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 DVMRP and PIM dense mode flood “active source” information across the whole network and build trees by creating “Prune State” in parts of the topology where traffic for a specific tree is unwanted. They are also called flood-and-prune protocols. In MOSPF, information about receivers is flooded throughout the network to support the building of trees.

Dense mode protocols are undesirable because every tree built in some part of the network will always cause resource utilization (with convergence impact) on all routers in the network (or within the administrative scope, if configured). We will not be discussing these protocols in the rest of this paper.

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

With sparse mode explicit join protocols we do not create a group-specific forwarding 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 we will mainly be discussing. This is the basis for PIM-Sparse Mode, which most multicast deployments have used to this point. This is also the basis for PIM-BiDir, which will be 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 – creating 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 forwarding state on a shared tree is referred to as (*,G) forwarding state, where the * is a wild card for ANY SOURCE. Additionally, PIM-SM supports the creation of forwarding 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) forwarding 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. We therefore refer to this model 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 having to repeat the term “ASM group or SSM channel”, we will use the term (multicast) flow in the text, implying that the flow could be an ASM group or an SSM channel.

Relevant Multicast Protocols / Packet Types

When securing a multicast network it is important to understand the packet types we might encounter and need to protect against. There are three main protocols with which to be concerned:

  1. IGMP / MLD
  2. PIM
  3. MSDP

The following sections address each of these protocols and the issues that might arise.

IGMP / MLD Packets

IGMP / MLD is the protocol used by IPmc receivers to signal to a router that they are interested in receiving content for a particular IPmc 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 at the following links:

It should be noted that with the above listed versions IGMP is not only a protocol but also an IPv4 IP 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 attempting 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 we will discuss multicast and unicast PIM control packets. We will also look at Auto-RP and BSR, which are ways of electing Rendezvous Points and controlling Group-to-RP assignments in PIM-SM networks.

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 neighborship.
  • PIM Join/Prune - PIM Join/Prunes are link-local scope IP multicast packets sent to create / remove multicast forwarding 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 BiDir PIM router responsible for sending (*,G) JOINS to the RP on behalf of attached receivers or downstream PIM neighbours. For cases where a PIM router detects another router sending (*,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 is actively forwarding 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 they are forwarding. This event indicates the presence of another router that thinks it is the Single Forwarder for this (S,G). The Assert mechanism elects a unique SF for that (S,G). PIM Single Forwarder router is elected to forward packets for a particular (S,G) stream. PIM allows for different routers to perform the role of the Single Forwarder on behalf of different (S,G)s, but there should only be one SF per (S,G). The SF should not be confused with the Designated Router. PIM Designated Router is the router responsible for sending JOIN / PRUNES or SOURCE REGISTERS 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 IPmc packets, the Designated Router that is attached to the source network will send 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 sending the Register message. Register Stop messages are sent as soon as the RP starts to receive IPmc 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 

Attacks exploiting such packets can originate from anywhere, as these packets are unicast. For information on how to secure PIM, refer to section 2.2.2.

Auto-RP packets

Auto-RP is a Cisco-developed protocol that serves the same purpose as PIMv2 BSR. Auto-RP was developed before BSR, and only supports IPv4. BSR supports IPv4 and IPv6. The Mapping Agent in Auto-RP serves the same function as the bootstrap router in BSR. In BSR, messages from the C-RP are unicast to the bootstrap router. In Auto-RP, messages are sent via multicast to the Mapping Agent, allowing easier boundary filtering, as described later. Auto-RP is described in detail at the following link: http://www.cisco.com/c/en/us/td/docs/ios/solutions_docs/ip_multicast/White_papers/rps.html

In IOS, the forwarding of AutoRP/BSR packets is always enabled, and currently not configurable. This can present a particular security exposure in the case of Auto-RP.

Fig 2: Auto-RP packets

Note that Auto-RP, even though it is a mechanism for PIM-SM RP announcement and discovery, does not use PIM packets (IP protocol 103); instead it uses UDP port 496 packets with multicast addresses. There are two packet types used by Auto-RP:

  • C-RP-Announce packets: these packets are Multicast to all Mapping Agents using an IANA reserved “well known” address (224.0.1.39). They are sent by a C-RP to announce the RP address and group range for which that RP is willing to act as the RP.
  • C-RP Discovery packets: these packets are multicast to all PIM routers using an IANA reserved “well known” address (224.0.1.40). They are sent by the Auto-RP Mapping Agent to announce the specific C-RP that is elected as the RP for a particular group range.

Each of these packet types are intended to be flooded through the network.

In IOS, both 224.0.1.39 and 224.0.1.40 are forwarded in PIM Dense Mode to avoid a problem of knowing the RP for a group when that group is used to distribute RP information. This is the only recommended use of PIM Dense Mode.

In IOS XR, Auto-RP messages are “RPF-flooded” hop by hop from neighbor to neighbor. Therefore there is no need to create a PIM DM mroute state to support Auto-RP in IOS XR. In fact, IOS XR does not support PIM-DM at all.

MSDP Packets

MSDP is the IPv4 protocol that allows a source in one domain to be announced to a receiver in another domain via their respective rendezvous points. MSDP is specified in RFC 3618 (http://www.ietf.org/rfc/rfc3618.txt).

MSDP works by forwarding information about active sources between PIM domains. If a source becomes active in one domain then MSDP ensures that all peer domains learn about this new source in a timely manner, allowing receivers in other domains to rapidly make contact with this new source if it happens to be sending to a group in which they have an interest. MSDP is needed for ASM / PIM-SM multicast communications, and runs over a UNICAST TCP connection configured between Rendezvous Points in the respective domains.

Threats in a Multicast Environment

Zones of Trust and Trust Boundaries

This section of the document is organized by functional entities in the network. The threat model discussed is shaped around those entities. For example, we explain how a router in a multicast network should be secured (from a multicast point of view), independent of where the router is deployed. Similarly, there are considerations on how to deploy network-wide security measures, or measures on a designated router, rendezvous point, etc.

The threats described here also follow this logic, and are organized by logical function in the network. 

Threat Overview

On an abstract level, any multicast deployment can be subject to a number of threats on various aspects of security. The key aspects of security are confidentiality, integrity and availability.

  • Threats against confidentiality: In most applications, multicast traffic is not encrypted, and is therefore open to eavesdropping on any line or network element in the path. In the section on GET VPN we describe a way to encrypt multicast traffic to prevent such attacks.
  • Threats against traffic integrity: Without application-level security or network-based security, such as GET VPN, multicast traffic is open to being modified in transit. This is particularly important for control plane traffic using multicast, such as OSPF, PIM, and many other protocols.
  • Threats against network integrity: Without the security mechanisms described in this paper, unauthorized senders, receivers, or compromised network elements can access the multicast network (masquerading), send and receive traffic without authorization (theft of service), or overload network resources.
  • Threats against availability: There are a number of denial of service attack possibilities that can make resources unavailable to legitimate users.

In the following sections we discuss threats for each logical function in the network.

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 may 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 by attacking random 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 IP 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, including SSH, Telnet, BGP, OSPF, NTP, etc.
  • Intrusions into the router, with subsequent exploitation of features on the router; weak Telnet or SSH passwords and weak SNMP community strings are a common problem in today’s network.
  • 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. Enabling IP multicast does not change the fundamental threat model above; however, it enables additional protocols (PIM, IGMP, MLD, MSDP) that may 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 IP 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 attacking multicast stream. In most cases (Auto-RP being the main exception), routers only listen to and receive “link local” IP multicast traffic. Link local traffic is never forwarded. Therefore, attacks on a router with IP multicast packets can only originate from directly attached attackers.

Threats From the Sender Side

IP multicast senders, whether PCs or video servers are sometimes not under the same administrative control as the network. Therefore, the sender is mostly treated as un-trusted, 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, including multicast. These threats include:

  • Layer 2 attacks: There are a wide range of attack forms on layer 2 to carry out eavesdropping, masquerading, or DoS 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 will not forward IP 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-utilizing the available bandwidth, creating a DoS condition.
    • Multicast state attacks: Flooding the first-hop router with multicast packets, creating too much state, and a consequent DoS attack condition.
    • A sender could attempt to become the PIM DR, sending PIM hellos. 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 source address spoofing is 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 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. Source IP spoofing is 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 should never send or receive PIM packets. Hosts that do this are likely attempting 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. Masquerading 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, including PIM unicast, can be targeted directly against those elements. The threats against RPs and BSRs include:

  • All generic attack forms, as described above in the section “basic threats against any multicast router”.
  • PIM unicast attacks, potentially with source IP spoofing, allow for DoS attacks, by sending PIM register or register-stop messages, for example.

Multicast and Unicast Security (compared)

State Considerations / Filtering

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

To inhibit traffic flowing from a specific source to a specific receiver, for the unicast stream we can install a filter anywhere on the path from sender to receiver. For the multicast stream, however, we need to be more specific about where we can install filters: at the receiver side we should filter after the last replication point before the receiver; at the source side we should filter before the first replication point after the source.

Attacks From Multicast Sources

The following applies to both the ASM and SSM service models, where traffic forwarding is 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 should usually only reach a receiver that has joined the flow in question.

With ASM, sources can launch traffic insertion or DoS attacks by sending to any of the groups supported by an active RP. Such traffic may not reach a receiver, but it will reach at least the first-hop router in the path, as well as the RP, allowing for limited attacks. If an attacking source, however, knows a group to which a target receiver is listening, and if there are no appropriate filters in place, it can send traffic to that group. This traffic will be received as long as it is listening to the group.

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

State Attacks

Even without receivers present in a network, PIM-SM will create (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 will 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 spoofing its source IP address randomly within the correct prefix, or in other words, spoofing only the host bits of the address randomly.

Fig 4: 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 and, in addition, on state forwarding 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 will instead just forward or discard traffic for PIM-BiDir groups.

Note that on some IOS platforms (*,G/M) state may not be supported. In such cases sources can attack the router by sending to multiple PIM-BiDir groups, causing (*,G) state creation. The Catalyst-6500 does support (*,G/M) states).

Receiver-Initiated Attacks

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

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

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 by joining too 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.

We will discuss ways of mitigating these sorts of attacks in the next section, Securing a Multicast Network.

Securing a Multicast Network


Securing a Network Element

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, including eavesdropping, spoofing, and active protocol attacks. Each network element must therefore be appropriately secured against any form of basic attack, as well as against specific multicast attacks.

Basic Security

Before taking specific measures to secure routers and other network elements, such as switches, against specific multicast attack forms, basic security must be deployed. This applies to routers, switches, and any other element on the path. For routers, the recommended steps for fundamental security are as follows:

Secure router remote access; disable unneeded servers; configure basic access lists; enable logging; secure management access; enable Authentication Authorization and Accounting; configure traffic filtering; enable routing security; perform router maintenance and testing.

Receive Access Control Lists (rACL) (only 7500 and 12000)

Receive access control lists filter traffic destined to the control plane of a router. As such, the destination does not necessarily need to be specified, since transit traffic will never be filtered by rACLs. The command syntax, which is only applicable to the 7500 and 12000, is as follows:

ip receive access-list <ext-acl>

This is a global filter that is applied to all “received” packets, or in other words, packets sent to any address “owned” by the router. This includes all configured unicast addresses of the router, as well as the mcast groups to which the router is listening. To see what constitutes “receive” addresses on a router, use the command show ip cef | include receive. This filter can be useful to restrict the following:

  • Unicast packets addressed to one of the router interface addresses
  • IP broadcast packets
  • Packets for joined IP multicast traffic
  • Packets for Link Local scope groups

Note that rACL is mostly superseded by CoPP. Please refer to the following section on CoPP for some cautionary remarks regarding rACL and CoPP configuration.

Control Plane Policing (CoPP)

Control plane policing is the evolution of rACLs, and available on most platforms. The principle is the same: only traffic destined to the router will be policed by CoPP. The syntax of the command is:

control-plane
     service-policy input <policy-name>

The service policy uses the same syntax as any quality of service policy, with policy-maps and class-maps. Therefore, it extends the functionality of rACLs (permit/deny) with rate-limiters for certain traffic towards the control plane. 

Note: Care must be taken when configuring rACLs and CoPP in a live network. Since both features filter all traffic to the control plane, all required control and management plane protocols must be explicitly permitted. The list of required protocols is therefore large, and it is easy to overlook less obvious protocols such as NTP or TACACS. As such, all rACL and CoPP configurations should always be tested in a lab before deployment. Furthermore, initial deployments should start with a “permit” policy only. This allows checking with ACL hit counters for any unexpected hits.

In a multicast environment, the required multicast protocols (PIM, MSDP, IGMP, etc) must be permitted in rACL/CoPP for multicast to function properly. Note also that the first packet in a multicast stream with PIM-SM being used is also a control plane packet, even though strictly speaking it is data plane traffic. This is due to the fact that with the first packet multicast state needs to be created, which is a control plane function. Therefore it is important to permit relevant multicast groups in rACL/CoPP. In CoPP they can be rate limited. Also note that there are a number of platform-specific exceptions, especially on the high-end platforms. It is therefore important to read the relevant documentation and test any planned configuration before deployment.

Please refer to the links in the reference section for more information.

Local Packet Transport Service (LPTS)

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

See more about generic router security at the online training in the references.

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.

Mroute Limits

The mroute limit command limits the amount of multicast routes globally on a router, and helps to prevent DoS attacks by flooding the multicast routing table.

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

Fig 6: 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 it will trigger syslog warning messages. At the mroute limit any further state triggering packets are discarded. The ip multicast route-limit command is also available per MVRF.

Disabling SAP Listen: no ip sap listen

The sap listen command causes a router to receive SAP/SDP messages. SAP/SDP is a legacy protocol that dates from the days of the MBONE. These messages indicate directory information about multicast content that might be available in the future or at present. This can be a source of a DoS against router CPU and memory resources, and therefore disabling this feature is generally recommended.

Controlling access to mrinfo information - the "ip multicast mrinfo-filter" command

The mrinfo command (available on Cisco IOS and also on some versions of Microsoft Windows and Linux) use diagnostic and troubleshooting messages to query a multicast router for information. The ip multicast mrinfo-filter global configuration command can be used to limit access to this information to a subset of sources, or disable it altogether. The following example denies queries sourced from 192.168.1.1, while allowing queries from any other source:

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

The following example denies mrinfo requests from any source:

ip multicast mrinfo-filter 52

access-list 52 deny any

Note that, as expected for any ACL, a deny means the packet will be filtered, while a permit means the packet will be allowed.

If the mrinfo command is being used for troubleshooting or diagnostic purposes, it is highly recommended to configure the ip multicast mrinfo-filter command with an appropriate ACL to allow queries only from a subset of source addresses. The information provided by the mrinfo command can also be retrieved through SNMP. Completely filtering mrinfo requests (block any source from querying the device) is highly recommended.

Securing the Network

In this section we will discuss securing PIM multicast and unicast control packets, from a network perspective. We will also look at Auto-RP and BSR packets.

Disabling Multicast Groups

The following commands can be used to disable all operations for groups denied by the ACL:

ip multicast group-range <std-acl>  (future)
ipv6 multicast group-range <std-acl>  (12.4T)

If packets appear for any of the groups denied by the ACL, they are dropped in all control protocols, which includes PIM, IGMP, MLD, MSDP, and are also dropped on the data plane. Therefore, no IGMP/MLD cache entries, PIM, MRIB/MFIB state are ever created for these group ranges and all data packets are immediately dropped.

These commands are entered globally. Note that at this time there is only support for the IPv6 version of the command. The IPv4 version will be available in a future code release.

The recommendation is to deploy this command on all routers in the network, when and where available, so that all multicast traffic originating outside the network is controlled. Note that these commands affect the data plane and control plane. Where available, this command provides more extensive coverage than standard ACLs, and should be preferred.

Securing PIM

PIM Neighbor Control

A PIM router must receive PIM Hellos to establish PIM Neighborship. PIM Neighborship is also the basis for Designated Router (DR) election, and DR failover and accepting / sending PIM Join/Prune/Assert messages.

Fig 7: PIM Neighbor Control

To inhibit unwanted neighbors use the ip pim neighbor-filter command illustrated in Figure 7 above. This command filters from all non-allowed neighbors PIM packets, including Hellos, Join/Prune packets, and BSR packets. Note that hosts on the segment can spoof the source IP address to pretend to be the PIM neighbor. Layer 2 security mechanisms (namely IP source guard) are required to prevent source address spoofing on a segment (see references) or use a VLAN ACL in the access switch to prevent hosts from sending protocol 103 packets. The keyword “log-input” can be used in ACLs to log offending packets.

The PIM Join/Prune packet is sent to a PIM neighbor to add or remove that neighbor from a particular (S,G) or (*,G) forwarding path. PIM multicast packets are link local multicast packets sent with TTL=1. All of these packets are multicast to the well known All-PIM-Routers address: 224.0.0.13 . This means that all such attacks must originate on the same subnet as the router being attacked. Attacks can include forged Hello, Join/Prune, and Assert packets.

Note that forging the TTL value in PIM multicast packets to a higher value than 1 does not create problems, since the All-PIM-Routers address is always received and treated locally on a router. It is never directly forwarded by normal and legitimate routers.

To protect the RP against a potential flood of PIM-SM register messages, the DR should rate limit those messages. The following command does this:

ip pim register-rate-limit <count>

Fig 8: PIM-SM Register Tunnel Control

PIM unicast packets can be used to attack the RP. Therefore, the RP should be protected by infrastructure ACLs against such attacks. Note again that senders and receivers never need to send PIM packets, so the PIM protocol (IP protocol 103) can usually be filtered at the subscriber edge.

The following additional security measures should be configured with Auto-RP where possible:

Auto-RP Control - RP Announce Filter

ip pim rp-announce-filter

This should be configured on the Mapping Agent to control which routers are accepted as Candidate RPs for which group ranges / group-mode.

Fig 9: Auto-RP – RP Announce Filter

Auto-RP Control - Constrain Auto-RP Messages

Use the multicast boundary command to constrain AutoRP packets to a particular PIM domain:

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

Fig 10: Multicast Boundary Command

BSR Control - Constrain BSR Messages

Use the ip pim bsr-border command to filter BSR messages at the border of a PIM domain. Note that no ACL is necessary since BSR messages are hop-by-hop forwarded with link local multicast.

Fig 11: BSR Border

RP / PIM-SM-related Filtering

In the final section of this chapter we will discuss filtering relating to PIM-SM and RP control plane messages. We will consider Auto-RP, BSR and MSDP messages

Auto-RP Filtering

The following shows an example of Auto-RP working together with address scoping. Two different ways of bounding a region are shown. The two ACLs are equivalent from an Auto-RP perspective.

Fig 12: Auto-RP Filtering / Scoping

The idea of the interface boundary filters for Auto-RP is to ensure that the auto-rp announcements only reach the regions they are supporting. Regional, Company and Internet-wide scopes are defined, and in each case there exist corresponding RPs and Auto-RP advertisements. We only want the Regional RPs to be known to the Regional routers, the Company RPs to be known to the Regional and Company routers, and we want any Internet RPs to be globally available. Further levels of scoping are possible.

As shown in the picture, there are two fundamentally different ways to filter Auto-RP packets: The Internet boundary explicitly calls out the auto-rp control groups (224.0.1.39 224.0.1.40), resulting in all Auto-RP packets being filtered. This method should be used at the edge of an administrative domain, where no Auto-RP packets should pass through. The Region boundary uses the filter-auto-rp keyword to instead create “semantic filtering” of Auto-RP messages. Instead of directly filtering Auto-RP packets, this command will cause an examination of the rp-to-group-range announcements within Auto-RP packets. When an announcement is explicitly denied by the ACL, it will be removed from the Auto-RP packet before the packet is forwarded. In the example, this will allow the enterprise-wide RPs to be known within the regions, while the region-wide RPs will be filtered at the boundary from the region to the rest of the enterprise.

Inter-Domain Filters and MSDP

In this example, ISP1 is acting as a PIM-SM transit provider. They are only supporting MSDP peering with neighbors and they are only accepting (S,G), but no (*,G) traffic on the border routers.

In inter-domain (usually between Autonomous Systems) there are two basic security measures to be taken:

  1. Securing the data plane, using the multicast boundary command. This ensures that multicast traffic is only accepted for defined groups (and potentially sources).
  2. Securing the inter-domain control plane traffic (MSDP). This consists of a number of separate security measures: MSDP content control, state limitation, and neighbor authentication.

We show a typical configuration from one of ISP1’s border routers showing an example interface filter.

To secure the data plane at the domain boundary we are inhibiting (*,G) joins by filtering “host 0.0.0.0” and administratively scoped addresses via the multicast boundary command:

Fig 13: Interdomain (*,G) filter

To secure the control plane, we 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 propagating 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 should 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. Cisco therefore recommends using the following 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 1918).
         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 see the following for more details on MSDP SA filter recommendations: http://www.cisco.com/en/US/tech/tk828/technologies_tech_note09186a0080093fda.shtml

2) MSDP State Limitation

When MSDP is enabled between ASs it is recommended to limit the amount of state that will be built in the router due to “Source-Active” (SA) messages received from neighbors. The relevant command needed is as follows:

ip msdp sa-limit <peer> <limit>

Fig 14: MSDP Control Plane

With this command we 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 (customer)
  • Large limit from transit customer (eg maximum #SAs in Internet)
  • Transit ISP - configure maximum #SAs your platform can support

3) MSDP MD5 Neighbor Authentication

We support and recommend the use of MD5 password authentication on MSDP peers. This uses the TCP MD5 signature option, equivalent to the use described in RFC 2385 for securing BGP.

Fig 15: MSDP MD5 Neighbor Authentication

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 originating at the sender can be mitigated with appropriate unicast security mechanisms. A number of unicast security mechanisms are recommended best practices here:

  • Source address spoofing protection (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 using 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 – Controlling 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 IPmc traffic, there may need to be a similar filter configured on all LAN-facing interfaces on which sources may potentially become active. Since it is not possible in all cases to know exactly where source activity may occur, it is recommended to apply such filters on all ingress points into the network.

Fig 16: Controlling Sources

The effect of applying this filter is to filter traffic from a specific source or range of source addresses to a specific group or range of group addresses. This filter will act before PIM creates any mroutes and so helps limit state.

This is a standard data plane ACL. This is implemented in ASIC on high-end platforms, and no performance penalty should be incurred. Data plane ACLs are recommended and preferred over control plane filtering for directly connected sources because they minimize any control plane impact of unwanted traffic. It is also very effective to limit the destination (IP multicast group addresses) to which packets can be sent. Being a router command, it cannot overcome spoofing of source-IP addresses (see earlier part of this section). Therefore, it is recommended to either provide additional L2 mechanisms or a consistent policy for all devices that can connect to a particular LAN/VLAN.

Note that the “log” keyword in an ACL is very useful to trace policy violations; however, logging consumes CPU resources, and should be handled with care. Also, on hardware-based platforms, ACL log messages are produced by a CPU, and therefore the CPU impact should be considered.

PIM-SM Source Control

One of the actual advantages of the ASM / PIM-SM architecture from a security standpoint is the fact that the Rendezvous Point gives a single point of control for all sources in the network for any group range. This can be leveraged with a device called the accept-register filter. The command for this filter is as follows:

ip pim accept-register / ipv6 pim accept-register

Fig 17: PIM-SM Source 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 this method of source filtering 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 reaching 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 therefore recommended to apply the pim accept-register command on the RP in addition to other edge filtering methods, such as applying simple data plane ACLs on all DRs, on all ingress points into the network, as described in section 2.3.1. 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. Applying several security mechanisms with the same goal is called “defense in depth”, and is a common design principle in security.

Receiver Issues – Controlling IGMP/MLD

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

Fig 18: Controlling IGMP

When filtering IGMP or MLD packets, the following should be considered:

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 IPmc is enabled. IGMP packets also carry the following protocols, and therefore all of the following protocols are enabled whenever IPmc is enabled:

  • PIMv1 – PIMv1 was the first version of PIM and is always enabled in IOS for migration purposes. Current deployments all use PIMv2.
  • Mrinfo - Mrinfo is a Unix command that 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. IOS support for DVMRP is being retired.
  • Mtrace - Mtrace is the multicast equivalent of unicast “traceroute” and is a useful tool.

For more information, see the following: http://www.iana.org/assignments/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) should always 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 being assumed.

In particular, hosts should 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 is prevented from becoming a router port, even if multicast router control packets are received.

The following 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
  • RGMP messages
  • CGMP messages

When these packets are discarded, statistics are updated indicating that packets are being dropped due to Router Guard.

IGMP Minimum Version

It is possible to configure the minimum version of IGMP hosts allowed. For example, you may want to disallow all IGMPv1 hosts or all IGMPv1 and IGMPv2 hosts. This filtering 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 HMAC mechanism using 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 querying router.

“Normal” multicast IGMP packets must be permitted.

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

ip access-list extended igmp-control
   …
   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 15.255.255.255 host-query  ! IGMPv1/v2/v3 queries
   permit igmp any 224.0.0.0 15.255.255.255 host-report ! IGMPv1/v2 reports
   permit igmp any 224.0.0.0 15.255.255.255 7           ! IGMPv2 leave messages
   deny   igmp any any             ! Implicitly deny unicast IGMP here!
   …
   permit ip   any any             ! Permit other packets

interface ethernet 0
   ip access-group igmp-control in

Note that this type of IGMP filtering can and should be used in receive ACLs or control plane policing. 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

To filter traffic to a receiver we do not filter data plane traffic, but rather the control plane protocol IGMP. Since IGMP is a necessary pre-requisite to receive multicast traffic, no data plane filters are required.

In particular, we might want to restrict which multicast flows receivers can join (attached to the interface that the command is configured on). In this case, the following command should be used:

ip igmp access-group / ipv6 mld access-group

For more information, see the following: https://www.cisco.com/c/en/us/td/docs/ios-xml/ios/ipmulti/command/imc-xe-3se-5700-cr-book/imc-xe-3se-3850-cr-book_chapter_010.html

For ASM groups, this command will effectively only filter based on the destination address. The source IP address in the ACL is then ignored. For SSM groups using IGMPv3 / MLDv2, it will filter on source and destination IP.

The following example filters a given group for all IGMP speakers:

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

The following example filters specific IGMP speakers (hence, specific multicast receivers) for a given group:

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

Again, note that for ASM groups, the source is ignored.

Admission Control

We discussed access control in the previous section. Access control delivers a yes/no answer for certain flows, independently of the state of the network. Admission control by contrast limits the number of resources that a sender / receiver can use, assuming they passed the access control mechanisms. Various devices are available to help with admission control in a multicast environment.

Global and Per Interface IGMP Limits

At the receiver-side router, there is the possibility to limit the number of IGMP groups joined both globally and per interface. The commands are as follows:

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

It is recommended that this limit always be configured per interface and also globally. In each case, the limit refers to counts of entries in the IGMP cache.

The following two examples show how this command can be used to help limit the number of groups at the edge of a residential broadband network.

Example 1 - Restrict received groups to only the SDR announcements plus one received channel

SDR (Session Directory) acts as a channel guide to some IPmc receivers. See the following for more details: http://tools.ietf.org/html/draft-ietf-mmusic-sdp-01

A common requirement is to restrict receivers to receive the SD group plus one channel. The following configuration can be used:

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

The access list in this example specifies the channel guide only; the global ip igmp limit command limits each IGMP source to a single (1) channel, excluding the channel guide, which can always be received. The interface command overrides the global command and allows two (2) channels to be received, in addition to the channel guide, on this interface.

Example 2 - Admission Control on Aggregation-DSLAM Link

This command can also be used to provide a form of bandwidth admission control. For example, if it were necessary to distribute 300 SDTV channels, which are 4Mbps each, and there is a 1Gbps link to the DSLAM, we might take a policy decision to limit the TV bandwidth to 500Mbps and leave the rest for Internet and other uses. In that case, we would limit the IGMP states to 500Mbps/4Mbps = 125 IGMP states.

The following configuration can be used in this case:

Fig 20 Use of Per-Interface IGMP Limits; Admission Control on Agg-DSLAM Link

Per-Interface mroute Limits

Enabling per-interface mroute state limits is a more generic form of admission control. It not only limits IGMP and PIM state on an outgoing interface, but also provides a way of limiting state on incoming interfaces.

The command to use in such cases is as follows:

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

State can be separately limited on input and output interfaces. Directly attached source state can also be limited with the use of the “connected” key word. The following examples illustrate the use of this command:

Example 1 – Egress Admission Control on Agg-DSLAM Link

In this example, we have 300 SD TV channels. We assume that each SD channel needs 4Mbps. Again we assume that we allow no more than 500Mbps for video traffic. We also assume that we need to support Basic, Extended, and Premium bundles. If we decide to allocate bandwidth as follows:

  • 60% / 300Mbps Basic
  • 20% / 100Mbps Extended
  • 20% / 100Mbps Premium

Then using 4Mbps per channel we will limit the DSLAM uplink to:

  • Basic 75 states
  • Extended 25 states
  • Premium 25 states

We configure the limit on the outbound interface facing the DSLAM from the PEAgg:

Fig 21: Use of Per-Interface mroute Limits; Admission Control on Agg-DSLAM Link

Example 2 – Ingress Admission Control on Agg-DSLAM Link

Instead of using the “out” limit on the upstream device’s outbound interface, it is possible to use “rpf” limits on the downstream device’s RPF interface. This effectively has the same result as the previous example, and could be useful if the downstream device is not an IOS device.

Fig 22: Use of Per-Interface mroute Limits; Input Admission Control

Example 3 - Bandwidth-Based limits

We can make a further subdivision of access bandwidth between multiple content providers and offer each content provider a fair share of the bandwidth on the uplink to the DSLAM. In that case we can use the following:

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

With this command, it is possible to attribute a “cost” (using the value specified in “multiplier”) to any states that match the extended ACL in the ip multicast limit.

This command is a global command and multiple simultaneous costs can be configured.

In this example, it is necessary to support three different content providers with fair access to each into the network. Additionally, in this example it is a requirement to support streams of the following types:

MPEG2 SDTV: 4Mbps 
MPEG2 HDTV: 18Mbps 
MPEG4 SDTV: 1.6Mbps 
MPEG4 HDTV: 6Mbps

In such a case we could then allocate bandwidth costs to each stream type and share the remaining 750Mbps between the three content providers with the following configuration:

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

Fig 23: Cost Factor for Per-Interface Mroute State Limits


Multicast and IPSec


Introduction to GET VPN

As with unicast, multicast traffic also sometimes needs to be secured to provide confidentiality or integrity protection. There are two major areas where such services may be required:

  • Encrypting multicast streams (for example in banking applications that stream confidential data to a large set of receivers using multicast) - this is data plane security.
  • Encrypting control plane protocols that use multicast, OSPF or PIM, for example - this is control plane security.

IPSec as a protocol [RFCs 4301, 4302, 4303, 4306] is specifically limited to unicast traffic (by RFC). There, a “security association” (SA) is established between two unicast peers. In order to apply IPSec to multicast traffic, one option is to encapsulate multicast traffic within a GRE tunnel and then to apply IPSec to the GRE tunnel, which is unicast. A newer approach uses a single security association established between all members of the group. The Group Domain of Interpretation (GDOI) [RFC 3547] defines how this is achieved.

Based on GDOI, Cisco developed a technology called Group Encryption Transport (GET) VPN. This technology uses “Tunnel Mode with Address Preservation,” as defined in the document “draft-ietf-msec-ipsec-extensions”. In GET VPN, first a group security association is established between all members of the group. Subsequently the traffic is protected, either with ESP (encapsulating security payload) or AH (authentication header), using tunnel mode with address preservation.

In summary, GET VPN encapsulates a multicast packet using the address information of the original header, and then protects the inner packet according to the group policy, using an ESP, for example.

The advantage of GET VPN is that routing and forwarding are not affected at all by the security encapsulation mechanisms. The routed IP header addresses remain the same as the original IP header. This makes it easy to secure multicast traffic because routing and forwarding is the same as without GET VPN.

The policy that is applied to the GET VPN nodes is centrally defined on a Group Key Server and distributed to all group nodes. Therefore, all group nodes have the same policy, and the same security settings applied to group traffic. Similar to standard IPSec, the crypto policy defines what type of traffic needs to be protected in which way. This allows GET VPN to be used for various purposes.


Using GET VPN to Encrypt Multicast Data Plane Traffic

The network-wide crypto policy is set on the group key server, and distributed to the GET VPN endpoints. The policy contains the IPSec policy (IPSec mode - here: tunnel mode with header preservation), and security algorithms to be used (e.g. AES). It also contains a policy describing which traffic should be secured, as defined by an ACL.

GET VPN can be used for multicast as well as unicast traffic. A policy for securing unicast traffic could be defined by an ACL in the following manner:

permit ip 10.0.0.0   0.255.255.255   10.0.0.0   0.255.255.255

This would encrypt all traffic with a source IP from 10/8 and a destination IP 10/8. All other traffic, for example, traffic from 10/8 to another address, would be ignored by GET VPN.

The application of GET VPN for multicast traffic is technically the same. For example, the following can be used to secure traffic from any source to respective multicast groups:

permit ip any 239.192.0.0   0.0.255.255

This policy matches all sources (“any”) and all multicast groups starting with 239.192. Traffic to other multicast groups will not be secured.

Note that while this appears relatively simple, great attention must be paid to the construction of the crypto ACL. Management traffic, or traffic that originates outside the GET VPN domain but terminates inside (i.e. traffic that passes only one crypto endpoint), must be excluded from the GDOI policy. Common mistakes include:

  • permit ip any 224.0.0.0 0.255.255.255: This also encrypts OSPF traffic and other control plane traffic, which might be destined at a peer router, for example.
  • Not excluding management traffic from the crypto policy, which terminates inside the network. This includes GDOI traffic itself.

Using GET VPN to Authenticate Control Plane Traffic

It is generally a best practice to authenticate control plane traffic, such as routing, to ensure that messages are coming 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. For the full list see the following: http://www.iana.org/assignments/multicast-addresses

Some of these protocols have built-in authentication (e.g. RIP, OSPFv2, EIGRP), others rely on IPSec to provide this authentication (e.g. 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 (i.e. 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 will not secure unicast PIM messages
  • permit pim any any: This will secure the PIM protocol, independent of whether multicast or unicast is used

Note that the above commands explain a concept and are not be used literally. For example, it is necessary to exclude certain PIM protocols used to bootstrap PIM, such as BSR or Auto-RP. Also, depending on the deployment, both methods have certain advantages and inconveniences. Please refer to specific literature on how to secure PIM with GET VPN for details.

Conclusions

IP multicast is becoming an increasingly common service in internetworks. 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 are making IP multicast an absolute requirement. Multicast comes with a variety of different configuration, operation and management challenges. One of the key challenges is security.

In this paper we have examined a variety of ways in which IPmc can be secured. We began by looking at the overall multicast control and data planes, and explained how the differences from unicast present new security challenges. We then examined the key protocols that are encountered in an IP multicast network, in particular IGMP, PIM, and MSDP were examined in some detail. In each case a description of security threats and recommended best practices for mitigating these threats were provided. We then described some specific examples of how multicast can be secured in some specific applications, such as broadband edge networks where bandwidth may be relatively limited in comparison to the amount of bandwidth that specific video flows may require. Finally, the GET VPN architecture was described as a means of integrating IPmc with IPSec for delivering secure VPNs.

In securing IPmc, it should always be remembered how it is different to unicast. Multicast forwarding is based upon the creation of dynamic forwarding state, multicast involves dynamic packet replication, and multicast builds unidirectional trees in response to PIM JOIN / PRUNE messages. Maintaining the security of this whole environment involves the understanding and deployment of a rich framework of IOS commands. These commands are largely centered around controlling protocol operations, states (multicast), or policing packets (MQC, CoPP). With correct use of these commands it is possible to provide a robust protected service/sla for IPmc.

In summary, the following are the approaches that we have 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. Where SSM can be used it should be
  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 might 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 filtering – rACL/CoPP and infrastructure ACLs, including blocking PIM at the access layer

IPmc is an exciting and scalable means of delivering 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.

References

Securing IP Multicast Services in Triple-Play and Mobile Networks
//www.cisco.com/en/US/prod/collateral/iosswrel/ps6537/ps6552/prod_white_paper0900aecd80557fd4.html

Guidelines for Enterprise IP Multicast Address Allocation
//www.cisco.com/en/US/tech/tk828/technologies_white_paper09186a00802d4643.shtml

Multicast Source Discovery Protocol SA Filter Recommendations
//www.cisco.com/en/US/tech/tk828/technologies_tech_note09186a0080093fda.shtml

Configuring IPv4 IGMP Filtering and Router Guard
//www.cisco.com/en/US/docs/switches/lan/catalyst6500/ios/12.2SX/configuration/guide/igmpfilt.html

“LAN Switch Security”, ISBN-10: 1-58705-467-1
//www.ciscopress.com/bookstore/product.asp?isbn=1587054671

Group Encrypted Transport VPN
//www.cisco.com/go/getvpn/

Control Plane Policing Implementation Best Practices
//www.cisco.com/c/en/us/about/security-center/copp-best-practices.html

Network foundation protection (generic router security guidelines and features)
http://www.cisco.com/go/nfp/

Future Work

A number of areas have not been explicitly discussed in this paper. These include MVPN and Label Switched Multicast, firewalls and address translation. We have deliberately not focused on SP or enterprise-specific issues in this paper, and preferred to keep things at a general level from an application and topology standpoint. We have also not discussed IPmc security in an IPv6 environment. We have not looked at new tools available in IOS XR for platforms like the CRS-1 or Nexus OS for the Nexus 7000. All of these areas will be covered in future papers addressing the topic of IPmc security.

Acknowledgements

This document was written by Steve Simlo and Michael Behringer.

The following people have all made significant contributions to this document:

Toerless Eckert
Scott Wainner
Greg Schudel
Andy Kesssler
Eric Vyncke

 

This document is part of the Cisco Security portal. Cisco provides the official information contained on the Cisco Security portal in English only.

This document is provided on an “as is” basis and does not imply any kind of guarantee or warranty, including the warranties of merchantability or fitness for a particular use. Your use of the information in the document or materials linked from the document is at your own risk. Cisco reserves the right to change or update this document without notice at any time.

Back to Top