Multicast deployments have additional security considerations that go beyond just a unicast routing environment. Additional security considerations can be requested by several components and processes of multicast systems, which can add complexity to the existing network infrastructure.
When designing IP multicast solutions, the security goals should be defined because multicast traffic has a different nature compared to unicast traffic. The security goals must focus on the differences between unicast and multicast and they include the following aspects:
- State information: Multicast state information is different from unicast state information. In unicast, only the routing table and the routing protocol are dealt with, but this is not the case with multicasting, which involves other constraints.
- Replication process: The replication process can create security vulnerabilities in multicast environments.
- Join process: The security threats in this area include rogue devices and rogue RPs that might be present in multicast environments.
- Unidirectional flows: These add complexity to the network due to the lack of chosen path predictability. Typically, in unicast environments, bidirectional flows are involved, but this is not always the case in multicast networks.
In a multicast environment, it is important to keep the network operating and the multicast traffic flowing, even when experiencing the following:
- DoS (Denial of Service) attacks
- Malfunctioning RPs
- Configuration errors
Many of the multicast security features are related to ensuring that the network resources, as well as the access control mechanisms for the different senders and receivers, are managed properly. Regarding the types of multicast traffic that are allowed on the network, a well-defined solution should be in place because there are many different types of multicast applications, and some of these may not be allowed in the organization. An important consideration regarding IP multicast security is the potential for various types of attack traffic (e.g., from rogue sources to multicast hosts and to networks that do not have receivers, and from rogue receivers).
With unicast traffic, any node can send a packet to another node on the unicast network, and there is no implicit protection of the receivers from the source, which is the reason firewalls and ACLs are used. However, in multicast routing, the source devices send traffic to a multicast group, not to specific devices, and a receiver on a branch in the network must explicitly join the multicast group before traffic is forwarded to that branch. In other words, multicast has built-in protection mechanisms to implicitly protect receivers against packets from unknown sources or potential attackers, such as Reverse Path Forwarding.
With SSM, unknown attacks will not happen because the receivers must join a specific host in a specific multicast group. Any unwanted traffic will reach only the first-hop router closest to the source and then it will be discarded. The attack traffic will not even generate state information on the first-hop router.
With Any Source Multicast (ASM), or PIM-SM and Bidirectional PIM, an end-device will receive traffic only when it joins a group, and an attacker cannot attack a particular host explicitly but it can send attacks against a multicast group, as well as a network. With multicasting, DoS attacks, also referred to as state attacks or control plane attacks, are always a threat. The goal is to increase the amount of multicast state information on the routers above some manageable threshold. However, this can lead to non-responsive services or even crashed devices.
SSM will drop traffic from unknown sources at the first-hop router closest to the source. When considering DoS attacks, the main areas of concern regarding the impact on the multicast state include ASM or Bidirectional PIM implementations.
A multicast network can also be subject to receiver attacks, which come in three categories based on the target of the attacks:
- Content attacks: In this type of attack, the unauthorized rogue receiver tries to gain access to the application content.
- Bandwidth attacks: This attack against other receivers involves the receiver trying to overload the network bandwidth.
- Attacks against routers and switches: In this type of attack, the attacker tries to create more state information than a switch or a router can deal with. For example, a router trying to process multiple Join requests can affect convergence time or other states. This attack can cause the network device to reboot or to reload.
Unicast has two scoped addresses (public and private spaces) that provide a layer of security by hiding internal hosts using NAT and PAT technologies. There can also be overlapping scoped addresses between different companies. On the other hand, multicast has its own scoped addresses as defined by IANA. IPv4 multicast supports the ability to administratively scope definitions within the 239.0.0.0/8 range. One of the most common actions is to configure a router with ACLs that can allow or prevent multicast traffic in an address range from flowing outside of an autonomous system or any user-defined domain.
Using a configuration of Group Encrypted Transport (GET) VPN as an example, it will replicate its keys using multicast technology, so the ACLs should be configured to allow traffic to go from the key server to all of the participants. This should include the networks that are being secured across the cloud, as well as the multicast range, either globally or the specific range that GET VPN uses for its key exchange, replication, and refreshing.
Within an autonomous system or domain, there is a limited scope address range that should be further subdivided so that local multicast boundaries can be defined. This subdivision process is called address scoping and it allows for address reuse between smaller domains.
Multicast access control is the process of using packet-based filtering (with the “ip access-group in/out” command in interface configuration mode) to permit and deny multicast packets. When using ACLs, the appropriate unicast and routing traffic with the multicast destinations must be allowed. This type of filtering should be implemented on different places in the network, including the source and receiver hosts.
The state requirements between unicast and multicast will influence the multicast design scenarios in terms of security and optimization. When designing multicast, it is important to understand the differences between the unicast state and the multicast state.
The unicast state is derived from the IP routing table and this can be populated differently based on the routing protocol used (e.g., EIGRP and OSPF use topology/link-state databases that ultimately lead to the routing table). Most routers run Cisco Express Forwarding (CEF), so the routing table is a representation in real time of the Forwarding Information Base (FIB) of CEF. The state changes only when there is a change in the topology, and this is the only factor that affects the CPU on the router because of CEF and the FIB. In other words, end-user functions will not impact the state of the router or the activity on the router, other than the traffic that moves through the links. One of the benefits of the FIB is that this activity is accomplished very preemptively and without having to use the route processor.
However, with multicast, the state also includes additional sources and receivers for new applications that are being used in the multicast design. Application state change and user activity can affect the CPU because both of these aspects can affect multicast traffic and state information. In a multicast environment, the multicast sources and the applications are additional network design constraints that go beyond routing topology changes. This is a key consideration when designing multicast.
Figure 4.13 – Multicast Router Traffic Flow
Considering Figure 4.13 above, as traffic comes into a multicast router (ingress direction), state information will be linked to ingress lookups on a per-application basis on the multicast server. This causes scalability issues of memory, especially as the number of applications grows. According to the way multicast works, the outbound (egress) state information will deal with the replication of packets to multiple interfaces that support receiver branches and the distribution tree. The state information on the outgoing interfaces will scale up as the number of applications span across the receiver branches. Hardware acceleration can be used to deal with this issue, as it is a key optimization factor for multicast routers.
Another design consideration for unicast and multicast routing is throughput parameters. Unicast routing generally deals with the amount of traffic that is received (ingress packet rate), while multicast routing is much more concerned with the egress packet rate, as well as the ability to replicate the outgoing packets. The egress throughput will be a key factor on both routers and Layer 3 switches that support IGMP snooping.