40.

1 Deploying IP Multicast Security

Introduction 

A financial brokerage has installed the client version of a proprietary trading platform
software from a stock exchange on a separate network within its premises. The brokerage has
used a WAN connection and has enabled a multicast connection between its network and the
stock exchange network so that the client software can connect with the server.

The brokerage wants to open services to a mobile audience of day traders. The auditors for
the brokerage have expressed concerns about enabling multicast on the network and feel it
should be locked down and secured as much as possible.

The network engineers of the brokerage know about multicast but are not very aware of
multicast security.

Your colleague Nikita has been assigned to this customer and has asked you to give her a
quick refresher on all the topics of multicast security. She has some last-minute questions
before she heads to the customer premises. You need to answer her questions so that she
becomes comfortable with managing the IP multicast security needs of the customer.

Choose an option:

 Review one or more topics:

o Multicast Security Challenges
o Problems in the Multicast Network
o Multicast Network Security
o Network Element Security
o Security at the Network Edge
o Securing Auto-RP and BSR
o Internal Multicast Security
o Sender Control
o Receiver Control
o Admission Control
o MSDP Security
 There is no Challenge for this section.
40.2 Deploying IP Multicast Security

Multicast Security Challenges 

Many security challenges must be addressed in IP multicast deployments. Some of them are
generic and apply to any network- or IP-based communications. Others are specific to
multicast implementations. When they identify the security challenges, security
administrators should consider the system as a whole. They should look for potential
vulnerabilities at various layers of the OSI model and in all of the implemented IP multicast
mechanisms. The most common security challenges are listed here.

 Compromise of the infrastructure:

1. Router break-in
2. Tampered IP routing
3. DDoS against network resources
 Compromise of multicast signaling:

1. PIM
2. MP-BGP
3. MSDP
4. Auto-RP
5. BSR
6. IGMP/MLD
40.3 Deploying IP Multicast Security

Problems in the Multicast Network 

When a multicast server is misconfigured or an attack originates from a malicious host,

serious network issues can result.

 A server misconfiguration can cause serious network issues.

 Simple protection can prevent this.

These issues occur because the routers that support large multicast routing tables may run out
of memory.
40.4 Deploying IP Multicast Security

Multicast Network Security 

To secure a multicast network, you must pay attention to three important areas.

 Securing a network element

 Securing the network at the edge

 PIM and internal security

In many cases, multiple protection methods can be deployed to protect a single vulnerability
of an IP multicast solution. Having many measures increases overall security through the
defense-in-depth concept, in which the protection methods complement and reinforce one
another. The protection mechanisms have various approaches and can focus on the
infrastructure, the VPN, or the admission control capabilities.

These methods are infrastructure-based:

 Router hardening: This mechanism includes enhanced password security, unused

services disablement, and control plane protection.

 Access control to the network: This mechanism includes ACLs and uRPF.
  QoS: The QoS mechanism involves congestion avoidance.

VPN-based services aim at providing privacy, integrity, and authenticity to the multicast
signaling and traffic streams, especially for sensitive data.

Admission control focuses on controlling the receivers that are allowed to join multicast
groups and source registration attempts. It also includes filtering techniques that, for example,
prevent DoS attacks that are based on spoofing RP addresses. An example of such a filter is
the ip pim rp-announce-filter rp-list ACL [group-list ACL] command, which is
configured on mapping agents in the Auto-RP implementation.
40.5 Deploying IP Multicast Security

Network Element Security 

Security is not a point feature. It is 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 network element is appropriately secured.

One possible attack scenario, applicable to any technology, is the subversion of a router by an
intruder. When intruders have control of a router, they can run several 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.

 General router security:

 1. Physical security

2. Strong passwords

3. Secure protocols

4. AAA

 Protecting the control plane:

1. rACL

2. CoPP

 Controlling multicast state on each device:

1. Global multicast routing table

2. Virtual routing table

3. Disable historic protocols (no ip sap listen command; ip multicast

mrinfo-filter command)

Before taking specific measures to secure routers and other network elements, such as
switches, against specific multicast attack forms, you must deploy basic security. These
cautionary measures apply to routers, switches, and any other element on the path.

For routers, these steps are recommended for fundamental security:

 Secure router remote access.

 Disable unneeded servers.

 Configure basic access lists.

 Enable logging.

 Secure management access.

 Enable AAA.

 Configure traffic filtering.

 Enable routing security.

 Perform router maintenance and testing.

rACLs filter traffic that is destined to the control plane of a router. This global filter is applied
to all received packets or, in other words, to all packets that are sent to any address that is
owned by the router. This group includes all configured unicast addresses of the router, and
the multicast groups to which the router is listening. This filter can be useful to restrict these
packets:

 Unicast packets that are addressed to one of the router interface addresses

 IP broadcast packets

 Packets for joined IP multicast traffic

 Packets for link-local scope groups

CoPP is the evolution of rACLs. CoPP will police only traffic that is destined to the router.

Care must be taken when you configure rACLs and CoPP in a live network. Because 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. It is
easy to overlook less obvious protocols such as NTP or TACACS. As such, all rACL and
CoPP configurations should be tested in a lab before deployment. Furthermore, initial
deployments should start with a permit policy only. This precaution allows you to check with
ACL hit counters for any unexpected hits.

In a multicast environment, the required multicast protocols (PIM, MSDP, IGMP, and so on)
must be permitted in rACL and CoPP configurations in order for the multicast environment to
function properly. The first packet in a multicast stream where PIM-SM is being used is also
a control plane packet, even though, strictly speaking, it is data plane traffic. It is used as a
control plane packet because, as the first packet, it creates the multicast state, which is a
control plane function. Therefore, it is important to permit relevant multicast groups in rACL
and CoPP. In CoPP, these groups can be rate limited.

The SAP is a traditional protocol that dates from the days of the multicast backbone. Its
messages indicate directory information about multicast content that might be available now
or in the future. Because these messages can cause a DoS against router CPU and memory
resources, it is recommended that you disable this feature.

mrinfo is an existing protocol that provides information that now is better retrieved via
SNMP. Completely filtering mrinfo is recommended.
40.6 Deploying IP Multicast Security
Security at the Network Edge 

This example presents a scenario where a multicast-enabled network needs to be secured at

the edge.

router(config)# ip|ipv6 multicast group-range ACL

 Limits all multicast operations at the data plane.

router(config)# ip multicast boundary ACL [filter-autorp]

 Permits only groups you define in the ACL.

 Applies ACL also to Auto-RP announcements.

Best practices:

 ACL should contain allowed (S, G) or (*, G) groups.

 ACL should deny groups not in use.

With the ACL, you can disable all operations for multicast groups. If packets appear for any
of the denied groups, they are dropped in all control protocols. These protocols include PIM,
IGMP, MLD, and MSDP. The packets are also dropped on the data plane. Therefore, no
IGMP or MLD cache entries, PIM, MRIB, or MFIB states are created for these group ranges.
All data packets are immediately dropped.

The recommendation is to deploy both commands on all routers in the network, when and
where available, so that all multicast traffic that originates outside the network is controlled.
These commands affect the data plane and the control plane.

In an interdomain environment, secure the data plane by using the multicast boundary
command. The multicast boundary ensures that multicast traffic is accepted only for defined
groups and potential sources.
40.7 Deploying IP Multicast Security

Securing Auto-RP and BSR 

Developed by Cisco, Auto-RP is a protocol that serves the same purpose as the PIMv2 BSR
mechanism. Auto-RP was developed before BSR, and it supports only IPv4. BSR supports
IPv4 and IPv6. The mapping agent in the Auto-RP approach serves the same function as the
bootstrap router in the BSR approach. In BSR, messages from the candidate RP are unicast to
the bootstrap router. In Auto-RP, messages are sent via multicast to the mapping agent,
enabling easier boundary filtering.

The figure shows two attackers introducing malicious candidate-RP-announce packets and
candidate-RP-discovery packets. The figure also shows where Auto-RP must be blocked to
filter out malicious candidate-RP-announce packets and candidate-RP-discovery packets.

In Cisco IOS Software, the forwarding of Auto-RP and BSR packets is always enabled and
currently not configurable. This default can present a particular security exposure in the case
of Auto-RP.
Auto-RP, even though it is a mechanism for PIM-SM RP announcement and discovery, does
not use PIM packets. Auto-RP instead uses UDP packets with multicast addresses. The Auto-
RP uses two packet types:

 Candidate-RP-announce packets: These packets are multicast to all mapping agents

by using an IANA-reserved well-known address (224.0.1.39).

 Candidate-RP-discovery packets: These packets are multicast to all PIM routers by

using an IANA-reserved well-known address (224.0.1.40).

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

Both 224.0.1.39 and 224.0.1.40 are forwarded in PIM-DM to avoid having to know the RP
for a group when that group is used to distribute RP information. This usage is the only
recommended use of PIM-DM.

In Cisco IOS XR Software, Auto-RP messages flood the RPF information for an RP hop by
hop from neighbor to neighbor. Therefore, there is no need to create a PIM-DM mroute state
to support Auto-RP in Cisco IOS XR Software. In fact, Cisco IOS XR Software does not
support PIM-DM at all.

The figure shows where BSR must be blocked to filter out malicious BSR messages. No
access list is necessary because BSR messages are forwarded hop by hop via link-local
multicast.
40.8 Deploying IP Multicast Security

Internal Multicast Security 

To establish PIM neighbors, a PIM router must receive PIM hellos. PIM neighbors are
pivotal in the election of DRs, in the DR failover process, and in the sending and accepting of
PIM join, prune, and assert messages.

 PIM is used only internally.

 PIM can often be blocked at the edge.

router(config)# ip pim register-rate-limit

 Rate-limiting PIM register messages are sent from the first-hop router to the RP.

router(config)# ip|ipv6 pim accept-register list ACL

 Filtering of the PIM register messages on the RP.

router(config-if)# ip pim neighbor filter ACL

 Interface-based PIM neighbor filtering.

40.9 Deploying IP Multicast Security

Sender Control 

IP multicast senders, whether PCs or video servers, are sometimes not under the same
administrative control as the network. Therefore, from the view of the network operator, the
sender is mostly treated as untrusted. 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 can take many forms:

 Layer 2 attacks: There are a wide range of attack forms on Layer 2 to carry out
eavesdropping, masquerading, or DoS attacks. These threats apply to unicast and
multicast networks.

 Attacks with multicast traffic: As described previously, it is difficult to conduct

attacks with multicast traffic because 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:

1. An attacker can flood a segment with multicast packets, overutilizing the

available bandwidth and creating a DoS condition. This threat is known as a
network saturation attack.

2. An intruder can flood the first-hop router with multicast packets, creating too
much state and, so, a DoS attack condition. This threat is known as a multicast
state attack.

3. A sender could attempt to become the PIM DR, sending PIM hellos. In such
cases, no traffic would forward to or from the LAN.

4. Election packets for a BIDIR-PIM DF could be spoofed. In such cases, no

traffic would forward to or from the LAN.

5. A sender could spoof Auto-RP discovery or BSR bootstrap messages.

Spoofing would effectively announce a fake RP, and bring down or disrupt a
PIM-SM or bidirectional service.

6. A sender could source unicast attacks, such as PIM source register or register-
stop messages. Or it could send BSR-announce packets and announce a fake
BSR.

7. A sender can send to any valid multicast group, unless this activity 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.

8. Intruders can also perform multicast attacks against control plane protocols.
Several protocols that are not associated with multicast, such as OSPF and
DHCP, use multicast packets. These packets can be used to attack these
protocols.

 Masquerading: There are several 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, attackers can use the multicast
service illegitimately from the sender side.

Hosts should never send or receive PIM packets. If they do, they are likely attempting an
attack.
The figure shows the different features that are used when you protect a multicast-enabled
network from malicious sources.

 Use the ip multicast boundary command to configure an administratively scoped

boundary on an interface to filter multicast group addresses in the range that is
defined by the access list argument.

 Use the ip pim register-rate-limit command to limit the number of register

messages that the DR will allow for each (S, G) entry. Enabling this command will
limit the load on the DR and the RP at the expense of dropping those register
messages that exceed the set limit. Receivers may experience data packet loss within
the first second in which register messages are sent from bursty sources.

 Use the ip pim accept-register command to prevent unauthorized sources from

registering with the RP. If an unauthorized source sends a register message to the RP,
the RP will immediately send back a register-stop message.

 Use the ip msdp sa-filter command to filter SA messages to or from the specified
MSDP peer.
40.10 Deploying IP Multicast Security

Receiver Control 

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

Receiver attacks can take three forms:

 A multicast receiver can attempt to join a flow without authorization and try to
receive content it is not permitted to receive.

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

 A multicast receiver can attempt to launch an attack against routers or switches. Many
IGMP reports can be generated, which can create a large amount of multicast tree
 state and potentially overload router capacity. This overload can result in an increase
in multicast convergence time or in a DoS on the router.

 Without IGMP/MLD, cannot request streams:

1. No data plane security required.

2. Focus on IGMP/MLD.

 Host does not need multicast: Block IGMP/MLD.

1. IPv4: IGMP is an IPv4 protocol type.

2. IPv6: MLD carried in ICMPv6 protocol type packets.

 Filter specific IGMP types.

 Control IGMP on switch:

1. Router guard: Define host port explicitly.

2. IGMP snooping: Enforce a minimum version of IGMP.

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

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

 IPv4: IGMP is an IPv4 protocol type.

 IPv6: MLD is carried in ICMPv6 protocol-type packets.

The IGMP process is enabled by default as soon as IP is enabled. IGMP packets also carry
the following protocols, which means that all these protocols are enabled whenever IP is
enabled:

 PIMv1: The first version of PIM, PIMv1 is always enabled in Cisco IOS Software for
migration purposes. Current deployments all use PIMv2.

 mrinfo: Cisco IOS Software inherited this UNIX command to display multicast
neighbors. Cisco recommends the use of SNMP instead of the mrinfo command.

 DVMRP: A traditional dense mode distance vector protocol, DVMRP has very
limited scaling characteristics. Cisco IOS Software support for DVMRP is being
retired.

 mtrace: This protocol is the multicast equivalent of unicast traceroute and is a useful
tool.
Unicast IGMP packets should always be filtered, because these are most likely attack packets
and not valid IGMP protocol packets. Unicast IGMP packets accommodate unidirectional
links and other exception conditions.

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 and SSM hosts, this reversion can attack the SSM streams. In the case
of IGMPv2, this condition can result in longer leave latencies.

If a nonredundant LAN with a single IGMP query is present, the router needs to drop IGMP
queries that are received.

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

 Router guard

 IGMP minimum version command

40.11 Deploying IP Multicast Security

Admission Control 

Access control delivers a yes or no answer for certain flows, independently of the state of the
network. Admission control, by contrast, limits the number of resources that senders or
receivers can use, assuming that they passed the access control mechanisms. Various devices
are available to help with admission control in a multicast environment.
  Controls receivers:

1. How many streams?

2. How much bandwidth can be requested?

 Three main possibilities:

1. IGMP/MLD state limits (global and per interface).

2. Per-interface mroute limit.

3. Bandwidth limits.

At the receiver-side router, there is the possibility to limit the number of IGMP groups joined
both globally and per interface.

There are three main possibilities for admission control:

 IGMP/MLD state limits (global and per interface): It is recommended that the
IGMP/MLD limit is always configured per interface and also globally. In each case,
the limit refers to counts of entries in the IGMP cache.
  Per-interface mroute limit: Enabling per-interface mroute state limits is a more
generic form of admission control. It not only limits the IGMP and PIM state on an
outgoing interface, but also provides a way of limiting the state on incoming
interfaces.

 Bandwidth limits: You can make a further subdivision of access bandwidth between
multiple content providers.

40.12 Deploying IP Multicast Security

MSDP Security 

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.

MSDP works by forwarding information about active sources between PIM domains. If a
source becomes active in one domain, MSDP ensures that all peer domains learn about this
new source. This notification allows receivers in other domains to rapidly make contact with
this new source if it happens to be sending to a group.

Interdomain filters and MSDP: When an ISP acts as a PIM-SM transit provider, it is
supporting only MSDP peering with neighbors. Also, it only accepts (S, G)—not (*, G)—
traffic on the border routers. In an interdomain environment, two basic security measures can
be taken:

 Securing the data plane, using the multicast boundary command. This action
ensures that multicast traffic is only accepted for defined groups (and potentially
sources).

 Securing the MSDP interdomain control plane traffic. This activity consists of several
separate security measures, including MSDP content control, state limitation, and
neighbor authentication.

Comparison with BGP

BGP MSDP

Peer authentication MD5 MD5

Limit state, globally maximum-prefix ip multicast route-

 Comparison with BGP

BGP MSDP
limit

neighbor peer maximum-

Limit state, per neighbor ip msdp sa-limit peer n
prefix n

ip msdp sa-filter [in|

Prefix filtering Prefix filter lists out]

Check first autonomous system

enforce-first-AS —
(AS)

Check AS path AS path filter —

Limit attack horizon TTL security —