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
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.
In IP multicast there are two classic service models:
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.
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.
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.
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:
The following sections address each of these protocols and the issues that might arise.
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).
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:
Unicast PIM Control Packets
Unicast PIM Control Packets are directed to or from the RP and include:
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:
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 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.
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.
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.
In the following sections we discuss threats for each logical function in the network.
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:
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.
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:
Note: Hosts should never send or receive PIM packets. Hosts that do this are likely attempting an attack.
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).
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:
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:
We will discuss ways of mitigating these sorts of attacks in the next section, Securing a Multicast Network.
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.
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:
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.
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.
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.
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.
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
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.
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:
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:
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:
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:
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.
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.
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.
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:
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
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:
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.
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.
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
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:
Then using 4Mbps per channel we will limit the DSLAM uplink to:
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
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:
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.
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:
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:
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.
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:
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.
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/
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.
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.