Multicast Security and Management Considerations

As part of managing services based on technologies such as multicast, it is important to highlight both security and management considerations.

In the context of multicast security, we assume that VPNs remain fully separated; that is, no reachability exists between the VPNS, unicast, or multicast. One cannot spoof the other VPN, unicast, or multicast. Unicast traffic remains separate, as in RFC 4364. This includes unicast PIM packets that are handled per MVRF.

The following list summarizes the multicast security requirements:

• Each VPN can use multicast independently.

• Source and group can overlap with other VPNs.

• Different PIM modes can be in use.

• There is support for the extranet.

• A spoofed PIM remains within VPN; the control plane information is handled in MVPN context only. Each VPN can use the same multicast groups.

• The MPLS core remains secure. It cannot be attacked from VPNs, unicast, or multicast.

In the context of the PE-CE interface the flooding with PIM control messages and multicast traffic (data plane) with possible flooding of data messages are indications of denial-of-service attacks.

In securing the PE-CE interface, you can consider the following best-practice guidelines:

• Limit the access to defined group addresses (access list [ACL]).

• Prevent IP source address spoofing (unidirectional reverse path forwarding [uRPF]).

• Limit sources to known source addresses if possible (ACL function).

Regarding the Rendezvous point function, you should avoid rendezvous point (RP) on PE and avoid a directly connected source/receiver to mitigate against a higher exposure to a denial-of-service attack against the PE.

RP receives join/prune messages, and a corresponding threat exists that an attacker can send a large volume of (*,G) join/prunes with spoofed addresses.

Furthermore, an RP receives register/register-stop messages with a threat that an attacker could fake register messages.

The solution is to filter ip pim accept-register, if designated routers or rendezvous points (DR) are known; in addition, use the command ip pim register-rate-limit on DRs (if DRs are trusted).

As for management considerations, current developments within the IETF involve exploring a lightweight connectivity check for point-to-multipoint label-switched paths (these can also be applied to point-to-point LSP) that use multicast technology mechanismsfor example, draft-swallow-mpls-mcast-cv-xx.txt.