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